Thief 2 Fixed Scripts

[Jax64]

The Thief 2 Fixed Scripts are a distribution of the original Thief 2 script modules with many defects corrected and some new features added. Replacements for all first-party script modules are included and can be used as drop-in replacements for the original modules. They can be used with both the original missions and all fan missions that make use of the original modules and ought to be fully compatible with them. This collection can be used by both players seeking a more polished experience with respect to scripted events as well as mission authors looking for expanded possibilities for implementing novel effects.

Downloads:

NewT2OSM.zip (Thief 2)

NewT1OSM.zip (Thief Gold) - WIP
NewT1OSMCompat.zip (Thief Gold OM Compatibility Layer)

Improvements:

A detailed list of most of the included changes can be found below. However, other than the many bugs fixed and improved multiplayer support, likely the most important features are the inclusion of all of the previously unavailable generic Thief 1 and Thief Gold scripts and the availability of the generic modules in Thief 1 as well. This effectively serves to unify the scripting capabilities of both Thief 1 and Thief 2.

=========================
== Implemented Changes ==
=========================

(all modules)

-Now supports the multiplayer game client executable.

(convict.osm)

-Now also offered as a Thief 1 module with an equivalent feature set to the
    Thief 2 module.

VictoryCheck and VictoryChecker:
-Multiple goal notifications will no longer play at the exact same time
    resulting in very loud notification sounds.
-Introduced a small (1ms) delay in goal notification display so that they will
    not appear prior to reading a book or other readable. The delay can be
    increased with the "GoalPopupDelay" configuration variable.
-The "New Objective" notification now respects the "Goal Notification"
    option in the game options menu.
-Notifications will no longer play if the script is on a starting point marker.
    This prevents notifications from being shown and heard twice as they are in
    the original convict module.
-Introduced optional new objective notifications. Define "FailedGoal",
    "RemovedGoal", "CancelledGoal", "ReversedGoal". You can also customize the
    color of the message and played schema with configuration variables. For
    example, "FailedGoalSchema noluck" will play the "noluck" schema when an
    objective is failed and "DoneGoalColor 32768" will show completed objective
    notifications in green.
-Now also handles showing secret notifications with the same configuration
    options as other notification types. This effectively obsoletes the
    SecretSounds script.
-Added "NoTakeGoalCheat", "NoLootGoalCheat", and "NoGoToGoalCheat" cheat
    configuration variables alongside the existing "NoKillGoalCheat".
-All cheat configuration variables can be defined to cancel the respective goal
    type or set to 2 to make them optional instead.
-The "goal_satisfied_x" quest variables are now set even when a final goal is
    irreversible. This fixes the behavior of such goals in several missions.

(gen.osm)

-Now also offered as a Thief 1 module with an equivalent feature set to the
    Thief 2 module.

Elemental, FireElement, FireShadowEcology, FireShadowFlee, SlayHush, WatchMe,
SecureDoor, Burplauncher, WindowShade, ControlWindowShade, CollapseFloor,
FireElemSparx, ModelByCount, HotPlate, HotPlateControl, NoTweqElevator,
TrapCreate, TrapInverter, and TrapOnFilter:
-Added previously Thief 1-only scripts. Both the Thief 1 and Thief 2 script
    distributions now include them.

GoalNotify:
-New script that encompasses the notification portion of VictoryCheck so that it
    can be available without convict if desired. (This also allows notifications
    to work in original T1 missions that cannot use convict.)

ZombieRegen:
-Type-specific zombie parts can now be specified with a "ScriptParams" link from
    the zombie concrete or archetype to the parts metaproperty. The link data
    should be "ZombieParts".
-Type-specific zombie weaknesses can now be specified with a "ScriptParams" link
    from the zombie concrete or archetype to the weakness concrete or archetype.
    The link data should be "ZombieWeakness"
-Zombies will no longer chatter after becoming dormant.

CameraAlert and CameraAlert2:
-The "Update" timer is now fired correctly at two-second intervals.

CorpseFrobHack:
-The "Auto-search bodies" option will no longer erroneously pick up
    non-frobbable objects on bodies.

Corpsed:
-The body model will no longer disappear if a save is loaded while carrying a
    body.

Blackjack and Sword:
-The mouse sensitivity is no longer reduced if the player has begun using a
    weapon and put it away before attacking.

Crystal:
-The object substituted upon being contained can now be configured with a
    "ScriptParams" link to the desired object. The link data should be
    "ArrowType".

Arrow:
-Arrows will have their render scale reset after being contained by an avatar.
    This prevents it from appearing the incorrect size when using the bow.
-Added option to make currently nocked arrows ignore all stimuli. To make use of
    this, populate a metaproperty named "M-IgnoreStimuli".

TrigFlicker
-No longer kills an unrelated timer under certain conditions. This resolves the
    infinite speed potion bug that can occur in some missions.

TrapNonFinalComplete:
-Now respects the current difficulty when determining which goals have been
    completed.

TrapTeleporter:
-"AICurrentPatrol" links can now be retained if the "TeleportNoBreakPatrol"
    configuration variable is defined.

TrapAddMetaProp:
-Added a generic version of this script to this module that can handle multiple
    "ScriptParams"-linked metaproperties. It derives from StdTrap and can, thus,
    either add or remove metaproperties. The original script without these
    additional features can still be found in miss16.osm.

TrapDelayer:
-Added script to this module. It derives from StdTrap so that standard trap
    flags can be used.

TrapPatrol:
-Will now set the script object to patrol if there are no outgoing
    "ControlDevice" links.

TrapSetQVar:
-Added support for setting multiple quest variables at once. Separate different
    arguments in the field with semicolons.

TrigRoomDelivery:
-Works as originally intended instead of sending "TurnOn" in every room.

TrigRoomDeposit:
-No longer erroneously sends "TurnOn" when dropping the relevant item outside
    the destination room while the player is simultaneously inside the
    destination room.

TrigQVar:
-Added support for triggering from multiple possible quest variables. Separate
    different arguments in the field with semicolons. The trigger is fired if
    any of the specified arguments match.

StdDoor:
-Schemas are halted when the door receives the "DoorHalt" message or begins
    opening or closing.
-No longer kills an unrelated timer under certain conditions.

StdElevator:
-The "Starting" and "Stopping" messages are correctly relayed to other elevator
   scripts even when the elevator itself does not move.

StdKey:
-"PlayerToolFrob" is now sent to the object being frobbed prior to trying to
    use the key instead of after trying to use the key.

Extinguishable:
-The tweq system is now used to extinguish torches rather than simply setting
    the model. This reduces the obvious movement of torches when doused.

SecretSounds:
-Notifications will no longer play if the script is on a starting point marker.
-Now implemented as a special case of GoalNotify.

Victrola:
-Can now be toggled on and off by frobbing the target object multiple times.
-The joint tweq animations will now play properly.

(miss1.osm, miss2.osm, and miss3.osm)
-The training tips can now be disabled with the "NoTrainingTips" configuration
    variable.

(archer.osm)

-Now also offered as a Thief 1 module with an equivalent feature set to the
    Thief 2 module.

(miss14.osm)

PlayerTally:
-Now differentiates between rope arrows and vine arrows.

(miss15.osm)

Loadup:
-Now differentiates between rope arrows and vine arrows.

(miss16.osm)

FusingMachine:
-No longer takes an item out of the player's inventory if it is placed in the
    slot and picked up again.

Installing:

This package can installed by either using the Dark Engine Mod Manager to install directly from the archive or by manually extracting its contents to an enabled mod directory. An installation running NewDark 1.27 or newer is required. No additional configuration is necessary, though it is possible to do so using the configuration variables noted in the changelog. Installing the package in this fashion will have the new modules be prioritized over those in the game's main installation directory, but not over modules included with FMs.

Notes on Thief 1/Gold:

The generic (non-mission-specific) modules are also offered for use with Thief 1 or Thief Gold. These, as before, can be used as replacements for the original versions of these modules. They are based on the Thief 2 versions of the relevant modules and, as such, have an identical feature set to them. Any mission authors who wish to use them in a mission will very likely have to make changes to their game systems. See the gamesys dbmod included with the Thief 1 distribution for those that are most important. However, while an effort was made to resolve some of the most prevalent compatibility issues exhibited with Thief 1, there are almost certain to be issues when used with some Thief missions, particularly those that exploit specific behavior of the original Thief 1 modules. As such, it may be best to consider Thief 1/Gold support to be in a beta-like state for now. Should you notice any such issues, feel free to report them here so that they can be resolved.

Almost all of the original missions do not employ the generic script modules. As such, by default, they will not use those that are included in this distribution. An additional small companion mod that will load the generic modules for all original missions so that one can play with their changes can be found in the downloads section.

Reporting Issues:

If you have any suggestions for additional improvements or notice any issues that should be addressed, please leave a post here with a description of the problem and, if applicable, a saved game. This distribution is to be continually updated, so reasonable changes and improvements are likely to be included.

I would like to extend a special thanks to Glypher, in particular, for helping in this endeavor by testing and suggesting many of the included improvements.

Changelog:

19-11-24:
-Fixed an issue with Container when it is duplicated on an object.

10-11-24:
-Victrolas are now toggleable and will animate with the configured joints tweq
    while playing.

3-11-24:
-Translating doors should now have their schemas halted when obstructed like
    rotating doors.

24-7-24:
-Fixed an issue that prevented TrapSetQVar from properly setting quest variables
    on only some machines.
-Prevent duplicate ropes from appearing with DeployRope and DeployVine
-Fixed the Container script so that objects appear to close when locked.

[RippedPhreak]

Hi Jax, firstly thank you for your efforts!

With regards to this section: "StdDoor: Schemas are halted when the door receives the "DoorHalt" message or begins opening or closing."

This does not seem to work, or perhaps I misunderstood what you meant here. I have a portcullis that closes to trap the player in an area, but it can be blocked by placing a heavy boulder in front of the portcullis. It always annoyed me that the metal door-closing schema would play forever until the rubble was removed - which allows the door to finish closing. I saw your post today and thought "great!"

However the schema still keeps going. I renamed your gen.osm to "newgen.osm," then performed a script_drop command for gen and load_script newgen. Saved the mission and re-opened it. Same behavior.

[marbleman]

This is awesome. Will it be integrated into T/2Fix?

[Twist]

Wow. Bravo!

[Jax64]

With regards to this section: "StdDoor: Schemas are halted when the door receives the "DoorHalt" message or begins opening or closing."

This does not seem to work, or perhaps I misunderstood what you meant here. I have a portcullis that closes to trap the player in an area, but it can be blocked by placing a heavy boulder in front of the portcullis. It always annoyed me that the metal door-closing schema would play forever until the rubble was removed - which allows the door to finish closing. I saw your post today and thought "great!"

However the schema still keeps going. I renamed your gen.osm to "newgen.osm," then performed a script_drop command for gen and load_script newgen. Saved the mission and re-opened it. Same behavior.

Hi, thanks for the report! You understand that particular note correctly. The script is working, but the issue here is that translating doors like portcullises never actually receive the "DoorHalt" message when obstructed. This behavior is unique to sliding doors and could be considered an oversight in the handling of door physics. Unfortunately, door physics behavior is outside of the purview of the scripting subsystem, so there is not really much that can be done generically in the scripts to alleviate this. It would be possible to handle this particular case by doing something more contrived, like halting the schema when a collision occurs, though this would likely not work well with all doors.

This is awesome. Will it be integrated into T/2Fix?

Yes, the plan is to eventually have this integrated into T2Fix, as it would probably be a good fit for inclusion. The Thief 1/Gold distribution is very likely not ready yet due to some variation in how the different versions of the scripts work. Hopefully, it will soon get to a state where most of these are resolved, however.

[voodoo47]

let me know when, I'll pop it into TFix.

[Taffingtaffer]

Hey Jax, I have a question regarding script usage as a player and a possible report.

You recommend to use these as a mod wtih DMM (so as a mod_path in cam_mod.ini), but T2Fix Common Scripts and such are loaded inside a OSM folder as a uber_mod_path. Could there be any possible consequences when loading them in a uber_mod_path? And would the specific OM scripts conflict with FMs that share the same number? (i.e miss15)

As for the report, I experience a R6031 crash on CoSaS 2 (https://www.ttlg.com/forums/showthread.php?t=122490) when using these scripts, whether they're in a uber or mod_path. Moving convict.osm out from the bunch solves the crash.

[Jax64]

About installation, using either mod path should be suitable here. DMM sets only the lower-priority mod_path variable (though could perhaps support configuring ubermods as well in the future) since most mods generally do not need absolute priority over other resources, notably FMs. Script modules can be an exception as far as mods go since it is often useful for them to have the highest priority, provided that they are up-to-date. T2Fix does this since many FMs include very old and sometimes faulty script modules. Having the up-to-date versions preempt them when possible during the loading stage prevents many issues with the old modules from manifesting.

That said, there are possible consequences to installing the fixed scripts as an ubermod, although they are probably unlikely. It is possible that some FMs that include modified or renamed versions of the first-party script modules will fail to work properly, as the fixed scripts would have priority over them. It's worth noting that this can occur regardless of the relevant mission's number, as a mission can use arbitrarily named script modules. In general, however, this should not be a problem provided that the FM is actually using any of the unmodified, first-party modules. I would imagine this to be the case for the vast majority of the FM catalog.

Also, thanks for the report. I am actually aware of that issue, though it is more a problem with the cosscript module included with the mission rather than specifically with the fixed scripts. In particular, this script module uniquely attempts to use convict as a surrogate during its startup process. However, this fails due to the fixed scripts using a different toolchain and C runtime. This issue will also occur if you install the older multiplayer OSMs included with NewDark 1.27.

Fortunately, this issue can be worked around fairly easily by just providing a renamed original copy of convict specifically for cosscript and modifying the latter to use it instead. Dropping the contents of this archive into your Mission X installation directory should resolve the issue. This should also work for other missions that use the module, such as Gathering at the Inn.

[ZylonBane]

The script is working, but the issue here is that translating doors like portcullises never actually receive the "DoorHalt" message when obstructed.

Seems like it would be fairly easy to, when a translating door is closing, start a timer to two or three times a second check the door state. If it's eDoorStatus.kDoorHalt, kill its schema.

[Jax64]

That approach would not be feasible since the door itself will never enter the halted state. That is, translating doors neither receive the "DoorHalt" message nor are they placed in the halted state when obstructed. After all, it would be odd if only one of these was done without the other, discounting the oddness of this as it stands. They will remain in their respective opening or closing states either indefinitely or until whatever is blocking them is removed.

It would be possible, and fairly easy, to check instead the door's velocity or whether it has collided with something to determine if it is in this pseudo-halted situation. That said, such behavior may not always be desirable since the door could start moving again should its obstruction be removed.

[morgan]

Wow this is great thanks very much for this.

Am i doing something wrong when installing with dmm.exe it install alright but i get a message in Status Colum saying Active but with a Yellow exclamation mark next to it and in the Type Colum i get Unrecognized but the game runs fine

[ZylonBane]

It would be possible, and fairly easy, to check instead the door's velocity or whether it has collided with something to determine if it is in this pseudo-halted situation. That said, such behavior may not always be desirable since the door could start moving again should its obstruction be removed.

Given the choice between...
1. Door sound playing forever when it shouldn't.
2. Door sound briefly not playing when it should.

...I'd definitely go for the first. Maybe throw in some hysteresis by not killing sound until it's been blocked for a second or two.

[Jax64]

I'm inclined to agree; the latter would be more jarring than the former. After running a few tests, it seems that it ought to be viable to address this by reacting to collisions and checking the door velocity. The links in the first post should now include this change.

Am i doing something wrong when installing with dmm.exe it install alright but i get a message in Status Colum saying Active but with a Yellow exclamation mark next to it and in the Type Colum i get Unrecognized but the game runs fine

No, you are not doing anything wrong. DMM currently does not mark OSM-only mods as recognized, as mods that include them would typically need a dbmod or some other mechanism to use their facilities. The fixed scripts are a special case since they simply replace the original modules. Fortunately, that indicator is just cosmetic; the game will still load the scripts properly, so everything should work.

[voodoo47]

you should be able to pop in an empty cfg to make the warning go away, cfg mods are recognized iirc. you also probably aren't using the latest build of the mod manager exe.

[Mayor]

Hey, I think I've encountered a small bug.

After lockpicking, chests don't open their lid anymore. You get the sound and the content, but the lid stays closed. So it is pretty minor, still I got quite confused first time when it had happened.

Here is the save right before lockpicked but not yet opened chest.

[Jax64]

Hi, thanks for the report. I can confirm the issue with that save; I've updated the downloads to resolve it.

The problem here is actually not strictly with the script itself, which is working as it should. Rather, it occurs because the Container script, which governs the behavior of most of the game's container-like objects, appears two times in that footlocker's script hierarchy. As such, it is actually opening and immediately closing imperceptibly since each script instance will attempt to toggle its opened state.

There are a variety of scripts that will exhibit issues when they appear more than once on an object. The conventional wisdom is to just avoid doing this, though I would like to eventually work to resolve such instances in the scripts themselves as well.

[voodoo47]

careful with that - generally, you shouldn't take mapping errors into account, those are indeed to be fixed by map dmls ideally. so if the fixed script exposes those, then that's actually a good thing (they can then be fixed properly).

[Mayor]

Thanks a lot for a quick fix! Can confirm the chest is working properly rn.

Just in case this is considered an unexpected mapping error, and is something the T2Fix team is interested in, I've originally encountered it in "Shipping... and Receiving" while playing GOG version of Thief 2, with latest T2Fix installed and CarryBody, Thief2 Fixed, and NewT2SFX enabled in mod manager in addition to script fixes.

[Jax64]

No problem. I'm glad it's working now. This is technically a map issue, so I'll get that addressed in T2Fix as well.

careful with that - generally, you shouldn't take mapping errors into account, those are indeed to be fixed by map dmls ideally. so if the fixed script exposes those, then that's actually a good thing (they can then be fixed properly).

I agree on principle; there are very few cases where one would really intend to add a script multiple times and tools to detect that would be helpful for resolving the problem on the designer's end. I don't intend to try to address any mission issues here. That said, while there is no obligation for the scripts to handle this particular issue, I also think resilience in spite of it could still be worth pursuing, especially given how common it is.

[voodoo47]

I don't think there is a scenario where script duplication would be desirable (though I think I remember one where the mapper exploited it to implement frob extinguishable candles long before I've used NVscript to do it properly), so from that point of view, the fixed script taking care of it sounds reasonable. the problem is by doing that, bad mapper behavior is encouraged, "I don't have to check for script duplication on my concretes, the fixed script will do that for me", and that probably isn't the best practice.