OSM Release Info

Extended Object Script Module


script.osm, release 1.2.0, 4/07/2003


If you have come here without knowledge, I pray you – do not turn around!  I can’t guarantee that my scripts will resolve each issue that arises during your long trek through this editor’s jungles, but I can promise you that virtually any problem you tackle will be simplified by their use.  Looking Glass’s toolset is extremely specific; I have done no more than to generalize that toolset, using Dark’s very fabric.  I sincerely hope my work unsheathes more of Dark for your use.


I, Vadim Kokielov, take all legal responsibility for the distribution of this file, waiving responsibility for damage caused by the file if it does not come from a valid source.  The valid source may be TTLG or my web site.  Please do not redistribute this package or this file.  Instead, link to it.  This ensures that all files come from authorized sources and that you are not blamed for planting a virus.


Versioning:  Occasionally I will update the public release with new scripts, and assign it new version numbers.  Specify the minimum requirement of your mission.  This will tell users if they need an updated version of the script release.



Triston Attridge – Valuable reverse engineering colleague and nerdy programmer buddy from the U.K.  We love ya, Totality!

Marc Leblanc – Mahk provided moral support while I was working on this project.  He also provided the motivation

Michael Ryan – Michael provided a list of scripts straight from the Shock 2 dev team.  I could then compare it to mine and see if I needed to add any more.

Dan Todd – Need I say more?

Wes Morrison – Mr. Morrison expressed interest in my scripts and helped me design some of them.  Most notable is TrapTeleportDelta – his brainchild.

The1Blade – Nerdy buddy #2, this one made of flesh.  I do wish that he had more emotion.

Avalon – A miraculously transformed man.  He generously agreed to host my scripting forum.

Tom Harris – Supplier of skill (a vital part of the script demo mission), provider of knowledge, purveyor of wisdom, all of a half of Mark Twain’s wit, and an official benchmark for good engineers…Find him floating about as “telliamed”.

Norbert Bendl – Wit and wisdom see no end!

Preno – RandomRelay, version 1.2, exists purely under his auspices.

Ben Hur – Ben Hur suggested TrapPhantom, without which you would still be digging in “Trail of Blood.”

Schwaa  – The colors option in IntrinsicPlaque and IntrinsicCover, Schwaa’s idea, is a tendril of a great collection of true art.  I recommend him if you are ever in need of a painting or a custom object.


Consult the demo mission for examples.


The convention is as follows:  Any script not explicitly marked otherwise should be assumed to work on any Dark version.  If a script is untested on a version of Thief, the fact shall be noted, but no scripts have been tested on System Shock 2.


All traps and triggers are generally analogous in their nature to Looking Glass’s traps and triggers, but many require ScriptParams links instead of ControlDevice links.


Clerical matters

In this release, the DLL file used by script.osm has been renamed Darkhooks.dlx.  It is functionally equivalent to Darkhooks.dll, however, and if you compare the files, you will notice that they are well nigh identical.  I changed the name in response to numerous requests, most of which arose after DarkLoader failed to extract the DLL file in script distributions.


My position on distributing script files with mission ZIP files hasn’t changed, but it requires clarification.  I disapprove of such distributions. They are conducive to the proliferation of security risks, and they create associations between particular versions of the release and individual missions – a situation I’d wanted to avoid.  Moreover, they make me an indirect distributor; if, for unexplainable reasons, Eidosdecided to get on my case, removing the scripts from circulation would take much more effort when they’re spread throughout.


I will release the source code to trusted developers.  Please write to me at GAYLESAVER@YAHOO.COM to discuss the subject.



I have learned my lesson.  In the course of my first venture, I discovered that the users of a product cannot submit to the trivialities and technicalities that dwell in the mind of its inventor.  That lesson has been rubbed in several times.  Therefore, in order to protect the public from my incoherence of thought, I’ve updated the documentation.  Of course, this documentation is not to be considered a substitute for Tom Harris’s work, without which I would not have found the resolve to complete this script release.  Nevertheless, I most certainly hope that the outreach of his writing will keep me in line now and in the future.  Peruse these explanations carefully, and you, too, shall wield the magic wand.


Design Note Properties

Real Dark properties are off limits, so I introduced cheap substitutes, called “Design Note” properties.  A Design Note property is true to its name; it resides in the Design Notes of objects.  Necessarily banded together on each level (the parser currently doesn’t search up the hierarchy), these poor excuses for proper user-adjusted variables are specified in one of two formats: a number or a string.  When a value is a string of characters, you type its name, followed by the equals (assignment) sign and the string in quotation marks; when it is a number, you omit the quotes.  To lump several of the values together, you place a semicolon after each right side of the equals sign.  For example:


Here, N is a numerical value and pie is a string value.


Each script asks for certain values.  Please read the documentation of these scripts carefully.

Script Messages

This document mentions script messages a few times.  It is my duty to explain what a script message is and why it is crucial to the fabric of the game engine.


The Dark Object System, unlike many other similar constructions for other games, specifies only a foundation for a game.  There is no specialization and there are no specific tools.  Each game is left to implement its own functionality.  In Dark, this sort of functionality is implemented using scripts.


In perspective, this means that the interactions between objects are the responsibility of the scripts on those objects.  Three practical modes of object communication exist within the Dark games.  Objects may request services of the game – a keystone connection without which scripts are powerless.  Objects also speak to each other, defining the relationships that drive the simulation.  Most importantly, however, the game regularly notifies the objects of events within the simulation.


As a script user, you are most concerned with the latter sort of communication.  The trapping of script messages will allow you to trace any event in the game, whether to identify a fault in your construction or to trigger an event of your own.  For each scenario there is a script in this package:  Spy will catch script messages and display them, TrapSMTrans will trigger a device with TurnOn (see below) when a particular message is trapped, and TrapScrMsgRelay will allow you to send messages of your own.


TurnOn and TurnOff are special script messages, generated when a trigger activates and usually sent down that trigger’s ControlDevicelinks.  This means that any objects to which the trigger is linked will receive a TurnOn or TurnOff message.


There has been, on the part of several skilled script users, a request to implement a script that triggers against script data.  While it is possible – and relatively simple – to write such a script, writing it properly is far more complicated, and I do not wish to leave perilous security and functionality gaps in any of my work.  I will, however, seek to create a comprehensive type database for Thief, after which it ought to be easy to adjust any quantitative property or sub-property relatively easily using traps and triggers.


Before I leave the subject, allow me to describe the implementation of script messages in Dark.  Think of such a script message as a short radio communication from an invisible observer.  Each of your objects receives this communication – a string of characters that usually forms an English word or a group thereof – when an event occurs.  You may also send such communications yourself when necessary, but beware:  if you try to imitate the game, you’ll crash it; the game’s messages contain hidden information that my scripts cannot generate.


Trap Control Flags and The Player as an Argument

I will pleasantly surprise you:  all traps in this release abide DromEd’s trap control flags.  Unfortunately, it is impossible to utilize what does not exist, and users of those releases of the editor that do not support the aforementioned property require an alternate input method.  In this instance, I have developed a means of specifying trap control flags for Thief 1 using the Design Note property, which, if it exists, takes precedence over the intrinsic Thief 2 property.  Specify


where [flags] is a set of two-character groups that may include any of the sequences below, corresponding as follows to standard flags:

!+  “no on”

!-  “no off”

<> “invert”



The following scripts are traps:




TimedStimulator (when dev=1)








Naturally, not all the flags make sense for all the scripts (consider “Once” with “Validator”).


If you wish to specify the player as a device to any of the traps above (or to TrigAIAwareShift) that have outgoing links (ControlDevice orScriptParams), link to the starting point.


In addition, there is a dummy script, called TrapFundament, which implements no functionality, but behaves like a trap.  For the moment, this means that placing it on any object will redirect links between the object and the starting point to the player.


Script Gamesys

The script_t2.gam file (to be released shortly – use scriptdemo.gam from the script demo mission for the time being) should be used as a base for Thief 2 missions that use these scripts.  It contains the entire 1.18 Dark.gam and a series of objects that implement all of the scripts, often with sensible defaults.  The new archetypes are as follows:


Object Archetypes

MPTrap – TrapMetaProp


SMTrap – TrapScrMsgRelay


SpecBoundsTrigger – TrigOBBSpec, under TrapTrig


ZapperMechPriest; InvisibleArrow – a Mechanist that implements the Zapper settings as described below










IntrinsicPlaque and IntrinsicAutoPlaque under Plaque









M-Spy, for the Spy script.

M-Forwarder, for Forwarder

M-GenTrigger, for TrapSMTrans

M-LoudInv, for InvSchema

M-SippableBottle, for Sippable







Act/React Stimuli

ScriptStim, for several Act/React scripts.


NOTE:  PhysModelCorrect is found both on the Physical archetype and on the bounds triggers.



Over the past months, several methods have been developed to accomplish common tasks using scripts.  I cite all of them here, some directly from TTLG’s “The Editor’s Guild” forum.

Auto-Frob signs

In the past, Jocke suggested the following solution:

“If you want auto-frob signs, like in Calendras Cistern, all you need is one object. The sign itself.

First create your sign and add the scripts StdBook, TrigWorldFocus and TrapStim.
Add Engine Features>FrobInfo and set world to Script and FocusScript.
Add the Book>Text.
Add a ControlDevice link from the sign to itself.
Add a receptron for ScriptStim, Intensity 1, action: Frob object; Me.

There you go, auto-read signs without any extra objects…”

Release 1.2, however, contains the script IntrinsicCover.  Like IntrinsicPlaque, it allows you to specify text in Design Note.  Unlike the former, this script reacts to “world focus” messages; the text appears when the player highlights your plaque in the world.  If internationalization is not a concern, it will suit the task.


Metaproperties at Various Difficulty Levels

If you wish to add different metaproperties at different levels of difficulty to different objects, consider creating a set of TrigSims and linking them to TrapMetaProps.  For each TrigSim, specify the Difficulty- Destroy property for any levels on which you do not wish to have your metaproperties added, and the game will take care of the rest.





The demo mission in this distribution contains, as books, documentation for the scripts in each room.  The big book contains Tom’s documentation and the piece of paper contains mine.


The following scripts are available in this distribution.


SparTournament – A private script that demonstrates invulnerable creatures.  To use it, simply add it to any creature (or Garrett). Since it is specific, I will not describe its effects in detail.


Spy –  This script allows you to track which script messages an object receives.  The last message received is displayed on screen with its parameters (or “data”, as they are formally named), but you can find the others in the monolog.  If the message is a stimulus (sent via the “Send to scripts” effect), the script will record the intensity and source.


TrapMetaProp – This trap will change (add or remove) metaproperties upon receiving a “TurnOn” or “TurnOff” message.  Link this trap, using a ScriptParams link, with any object whose metaproperties you wish to change.  Then, link it directly with the metaproperties you wish to change – also using a ScriptParams link.  The data of the links specify which metapropeties are added or removed:


A@N – On TurnOn, add metaproperty labeled “SN” to this object.  On TurnOff, remove it.

R@N – On TurnOn, remove metaproperty labeled “SN” to this object.  On TurnOff, add it.

SN – Label for metaproperty.

N can be any collection of symbols (S1, S2, SA, SAB, etc. are all acceptable).

As an example, to add M-StarSprangled to an object called QatarAirBase:

1)  Create TrapMetaProp.

2)  Create M-StarSprangled.

3)  Link the TrapMetaProp to M-StarSprangled using ScriptParams.

4)  Link the TrapMetaProp to QatarAirBase.

5)  Set the data of the first link to “A@1”.

6)  Set the data of the second link to “S1”.

7)  Link to the TrapMetaProp with ControlDevice from some trigger.

8)  In-game, activate the trigger.  A TurnOn message will be sent to the trap, and the property will be added.  If the trigger is a lever, flipping it back will send a TurnOff message, and the metaproperty will be removed.  The benefit of this trap lies in the easy accessibility of its operations.  Using it, you can seamlessly integrate the addition and removal of metaproperties into any trigger-trap chain.


TrapScrMsgRelay – This script will trap a TurnOn or TurnOff message and send any any other script message you specify to any object you specify.  If you enter Design Note data, you can identify a special flag parameter, passed with the message, to contain a numerical value reflecting the nature of the message received (0 for “TurnOff” and 1 for “TurnOn”).  This parameter, required by some recipient scripts, is placed using the status_index Design Note property.   By default, this value is assumed to be 1 for backward compatibility.


You ought to pass script data to any script that asks for it.  Currently, Validate and AIItemGiver are the only custom scripts that accept user script messages, but some private scripts may accept them as well.  Any message that can be sent using this trap can also be sent using the pseudoscript action “Send Script Message,” as long as both data1 and data2 are strings and you don’t need to use data3.  An interesting use for the script is to streamline all TurnOff/TurnOn messages into one category – for example, to always send a TurnOn or to always send a TurnOff.  See the demo mission for another example with the Validate message.


You can specify script data 1, 2, or 3 via Design Note as long as it is not the status parameter.  The first character of the string value specifies what sort of data you deliver; some messages expect strings.  For example:


will send 20 as an integer number within data1, whereas


will send it as a string.

Specify “i” for the data to be treated as an integer, “f” for it to be treated as a decimal number, or “s” to send the string untainted.  See the receiving script’s documentation for information on data types.


To use the script, link to the object that carries it with a ControlDevice link and add ScriptParams links for any objects you want to pass the transformed message to.  The data indicates the message name you want to pass on (for example, “Validate”).  If the message name is longer than fifteen characters (the data size limit for ScriptParams links), specify an object name that begins with “#” instead.  Then, create the object and type the actual name of the message in the Design Note parameter.  If you wanted to catch FireStimStimulus, you could create a ScriptParams link between the trap and the device, set its data to ”#FStim”, and create an object named “#FStim” with Design Note property value “FireStimStimulus.”


AIItemGiver – Put this on an AI to enable the AI to hand things over during a conversation.  This script won’t combine objects correctly. Its use is analogous to removing, then adding a Contains link.  To use it, “Send Script Message” from within a conversation with data1=DestObj and data2=TransObj.  The script will take TransObj from its owner’s inventory and put it into DestObj’s inventory.  You can also use a script message relay trap:  link the trap to the AI and set its design note to

data1=”sTransObj”; data2=”sDestObj”; status_index=3

Above, TransObj and DestObj are numbers or names, but they are always strings.


Forwarder – The Forwarder script catches messages and passes them on.  This is of limited applicability, but it can be useful in rare instances.  Link the owner of the script with the destination of the message using a ScriptParams link, and type in the message name inside. This won’t prevent the owner from handling the message, but it will send the message on to the objects you specify.  It can be useful as a filter: you can set it to forward a specific script message, but not any others.  Use the method described under the TrapScrMsgRelayheading above for long message names.


The new Forwarder passes message structures undisturbed, which means that it may work better with engine messages, allotting a great deal of control into the hands of its user; this happens because the new recipient really does think the message was sent to it, so any script that handles the message will be able to handle it correctly.  Nevertheless, be aware that this polymorphism may have unpredictable consequences – sometimes, script behavior is supplemented by engine code, and if the engine is unaware of the state change of an object, the script will be orphaned at best and confused at worst.


TrapSMTrans – This isn’t really a trap, but a generic trigger; the suffix “Trans” expands to “Translator”.  It’s very useful if you can handle Spy.  It sends TurnOn messages whenever it catches a message that you specify.  In this, it is the opposite of TrapScrMsgRelay.  Put it on any object.  For example, you could find out when the player frobbed any object in the world (similar to StdButton) by putting this script on the object and linking from the object with ScriptParams.  In the data you would specify “FrobWorldEnd” (‘end’ meaning after the player releases the frob key), and the destination would be a trap – for example, a trap that opened up a door or created an enemy.  If the message name is longer than sixteen characters, the maximum allotted to a ScriptParams link’s data (as is the case with “WeaponStimStimulus,” for example), use a tag:  create an object whose name starts with a pound sign, set its design note to the name of the message you wish to reference, and specify the object’s name, reusable for any such indirection, in the link data.  Like Forwader andTrapScrMsgRelay, TrapSMTrans supports message names longer than fifteen characters by aliasing.  A subsequent release will compile a database of message structures and parameters, but I have no intention of unfurling such a release until I have a chance to properly document all of them.


TrigOBBSpec – This trigger reacts when a child of a certain archetype (Guard, Garrett, etc.) enters its bounds.  You link to the archetype with “ScriptParams” and specify “arc” in the data.  Whether you link to the controlled devices or traps using another ScriptParams link with the data set to “cd” or use standard ControlDevice links, the script will send a TurnOn message down the links when the object or its child enters the trigger bounds; the former approach is recommended for old TrigOBBSpecs located under the TrigOBB object in the hierarchy, and the later approach for the new standalone boundstriggers.  When the object leaves, TurnOff will be sent.


Standalone specific boundstriggers require the addition of several properties found on standard boundstriggers – specifically, Physics\Model\Dimensions, …\Attributes, …\Controls, and …\Type.  To be certain, copy TrigOBB’s properties entry-by-entry and then replace the TrigOBB script with TrigOBBSpec.  A sample multibrush, DefSpecBounds.vbr, has been provided, but it relies on a SpecBoundsarchetype.  Find a copy thereof with the demo mission.


Be aware of a flaw in bounds triggers.  Only one object at a time must be permitted into the bounds.  Subsequent objects trigger no messages, even if they are unrelated to the archetype.


TrapStim – TrapStim initiates an Act/React stimulus on an object, after TurnOn, with an intensity you specify using the Design Note property “strength”. Specify the stimulus name in Design Note as well, using the “stim” property, and describe who is to be stimulated usingControlDevice links.  The script defaults to Release 1.1 values:  stim=”ScriptStimulus”;intensity=1.00.  Its raison d’etre is nothing more than the need to initiate Act/React effects using such things as buttons or triggers.


TimedStimulator – This script acts like a FlickerTrigger for Act/React.  It sends stimuli (ScriptStims by default) down every N seconds. You can still specify the time interval by linking the object to itself with a ScriptParams link, but I don’t advise such suicidal undertakings. Instead, use the “interval=n” (time between stimulations, one second by default) and, optionally, “stage=x” (starting intensity, 0 by default ) Design Note property.  Please note that if the ScriptParams link is present, the game will ignore your Design Note parameter regardless of whether the data format of that link is correct.


The script begins to stimulate an object as soon as it is added at the intervals specified, unless you specify the Design Note property “device=1”.  If you specify so, then the script can be controlled using TurnOn and TurnOff messages.  The stimulus is set as for TrapStim: add the “stim” Design Note property.  If you know enough about Act/React, you could achieve some fairly intriguing effects using this script.


InvSchema – This script plays a sound when the player (or someone else) frobs an object in his inventory.  It was originally intended for use with Sippable (below).  To make use of it, simply link the object you want to make the sound (a bottle, for instance) to the sound you want it to make with a SoundDescription link.  Make sure that this doesn’t conflict with DescribeSounds or any other script that shipped with Dark.  When the player picks up the object and frobs it in inventory (make sure that FrobInfo sends the inv frob to a script), he will hear the sound you specified.


Sippable – Sippable allows its user to create objects with a fixed number of uses.  I amended Sippable to extend its services to any bottle. Simply specify the number  of times the player can frob the object as“sips=n” in the Design Note.  Of course, the old methods continue to work.


This script will automatically change the object’s name, unless it is not verbatim (i.e. it refers to a string in a .str file instead of specifying a name in quotations after a colon).


Zapper – This is a fun little script.  Put it on any ranged attacker – preferably a Mechanist or Hammer priest – and take away his usual weapon (which won’t necessarily be easy[1]).  Now, whenever the priest tries to attack, he will immediately cause a magic zap in his target, without firing off any rounds!  Unfortunately, this is (yet) somewhat of a hack – if the target is not Garrett, the script may not work properly.  Use the Design Note statement “no_zap_sound=1” to turn off zap sounds.


TrigSim – The simulation trigger sends TurnOns down its control device links when the simulation begins.  This version of the trigger will delay message processing until the simulation starts, so all objects ought to be ready when the trigger fires.


LinkTemplate – Sending a TurnOn message to a LinkTemplate causes links with data to be moved from the template to another object. Sending a TurnOff message will move links from another object to the trap.  Add a DesignNote property and specify the parameters as follows:

object=”player”; flavor=”contains”

In this example, all Contains links from the template object to any other object will be moved on TurnOn, causing them to instead be from the player to the other objects.  If you change the design note to


the same thing will happen to contains links to the template from any other object.

If you want to handle TurnOff, too, you’re probably better off writing

Object=”player”; flavor=”contains”;dest=”PSword”

Where the dest setting determines the name of the destination object you’re interested in.  That way, when you copy back the links onTurnOff (i.e. taking the sword away from the player), only the sword is taken away, and not all Contains links.


If you do not specify the flavor, the trap will copy links of all flavors except ~ControlDevice on the objects in question, so long as they fit the other specifications.  See Tom’s demo mission tour document, when it becomes available, for details.


Validator – The validator script is the first easy method for storing state information in Dark.  Quest variables are limited in their capacity to store state information, because they cannot be used to make branching structures.  Validators expect two kinds of messages:  standardTurnOn/TurnOff and Validate.  Validate messages are special messages that you send using TrapScrMsgRelay, wherein the first data parameter contains an integer representing a state value.  Let’s say you want to set up a system whereby if you flip a switch, then pressing a button opens a vault door; otherwise, it raises an alarm (as in the demo mission).  You create a validator and a script message relay with “status_index=1”, connect the switch to the script message relay so that the relay sends its status (whether it received a TurnOn or aTurnOff message) in the first parameter, and link the script message relay to the validator with a ScriptParams link of data “Validate”.  You then link the validator to the vault door with a ScriptParams link, and set the data to “1”.  You link it to the alarm and set the data to “0”. Link the button to the validator with a standard ControlDevice.  If you run the simulation, you will discover that unless the switch is flipped,frobbing the button will raise an alarm.  This happens because TrapScrMsgRelay will send a 0 in data1 when you turn the switch off and 1 when you turn the switch on if status_index=1.


The Validator passes along TurnOff messages in the same way it does TurnOn messages.


If you add


in the Design Note, the validator will auto-increment by an amount n (positive or negative).  This is useful if you need a chain of events to happen in sequence as the player triggers the validator.  If you want the chain to repeat, set


and when the nth index is reached, it will roll over to 0.  The script no longer requires links to exist for all states, however; if there is no link, there will be no message, so you can introduce counters with arbitrary gaps without wasting objects.


Imagine the possibilities!


RandomRelay – An old RandomRelay is provided for backwards compatibility.


RandomRelay1x2[2] – Random relay traps can be weighted or unweighted.


Unweighted random relays, default to the script, are useful for causing random events and behave as random relay traps had done before, choosing each link in the set equally often.  Link the metatrap to any number of traps using ControlDevices.  Whenever you send a TurnOnor TurnOff message, one of those traps will receive the message.  You can no longer specify reusable=”true” in the Design Note; use the trap control flag “Once” to simulate its effect.  If no more ControlDevice links exist, the trap does nothing.


Weighted random relays, introduced in release 1.2 and enabled by the Design Note parameter proportions=1, support weighting probabilities.  Instead of using ControlDevice links, you link to your devices using ScriptParams, and then specify relative multiplicative weights in the data.  This means that a device with relative weight “4” is going to be chosen twice as often as a device with relative weight “2” and four times as often as a device with relative weight “1”.  If you use this trap, you may opt to make it “rechargeable” (“rechargeable=1”); if so, it will reverse the sign on the data in its ScriptParams links to prevent them from being counted, but it will restore the signs to their place when the last link triggers, precisely as Preno suggested.  Since the weighted algorithm is slow, it is not recommended to fire weighted RandomRelays rapidly in sequence.


Please see the demo mission; within, you will find a demonstration of a rechargeable random relay trap.


TrapTeleportDelta – This is a special teleport trap that moves objects relative to other objects on all three axes simultaneously.  The so-called  “delta object” is placed to serve as an anchor.  The destination object – the trap itself – is placed as the second anchor.  The vector displacement of the subject from the delta anchor before the teleportation is equal to its displacement from the trap.  Link the trap with the anchor object via a ScriptParams, and set the data to “dm”.  Link to the subject using ControlDevice.  A TurnOn will cause the teleportation. Make sure the subject (especially the player) doesn’t end up in solid space!  This script is best when you are using teleportation between two identical areas as a way of breaking up your space or of effecting “impossible” changes on the environment.  Thanks to Wes Morrison for the idea.


IntrinsicPlaque and IntrinsicCover – Written for the script demo mission, IntrinsicPlaque lets you create a plaque that does not require any book file to be read when frobbed.  Its cousin, IntrinsicCover, does the same in response to world focus, thus providing an automatic means for “look-signs”.  To use the first, put it on any plaque or book without art, and set the Design Note to the text; the second may be put on any particular debris that doesn’t require its Design Note for other purposes – and even then you may use the alternate “text” Design Note property to mix the data for this script with the data for other scripts.


To insert a carriage-return/linefeed pair (also known as a line break), use a double-pipe symbol (||).  On most keyboards, the character is found above the backslash.


In this version of the script, you may also specify the text’s color using “clr_red=”, “clr_green=”, and “clr_blue=n”, where n is a value from 0 to 255 (with the latter value default) – calibrate the values using a standard Windows color selection box.  If you do so, please place the text into a Design Note string property called “text”.  If this property is an empty string (doesn’t exist), the entire Design Note is displayed (for backward compatibility).


TrapHP – This trap will adjust the hit points on an object.  The Design Note property “object” specifies the precise object name, and the property “hitcount” is a number that describes how many hit points to add; if it is negative, then hit points will be subtracted.


TrapPhantom  – Prompted by Ben Hur, I created the TrapPhantom script.  Place it on an object whose alpha you want to gradually change, create the alpha property explicitly, and initialize it.  Then, set the “alpha_min” Design Note property to your initial value and “alpha_max” to whatever value you want to reach.  Now, send a TurnOn message from somewhere.  The phantom will fade in and then pass a TurnOn along its ControlDevice links.  Sending a TurnOff to it will reverse the process.  You specify the increment in alpha per second, the decimal “rate” value. For example, 0.5 will mean that, during one second, alpha will rise from 0 to 0.5 or 0.5 to 1. The correction is due to Bumbleson.


You must set the Alpha property properly because it may have “0” as its value even if the object in question looks entirely solid.  This happens when the property is nonexistent and thus acquires the default value for an object, which may not reflect the default setting.  If you wish for the trap to work, please initialize the property explicitly.


PhysModelCorrect – This script is relatively unspectacular; it is static.  However, it hides a panacea.  Such power it wields that I suggest you place it on the Physical archetype.  At the beginning of the game, it will adjust any OBB model to fit a resized object.  Please be aware that this script requires the Physics\Model property to exist on an object to work, and that, since the script operates on relative values, the physics model must wrap around the shape at the beginning for the scaling to be correct.


You may send a “PMResize” script message manually to resize the model again, as if from the start.  You may need to send this message to any regular BoundsTriggers that use the script (TrigOBBSpecs do it automatically) – they have been known to reset the model size after the script has already acted.


TrigAIAwareShift – This script tracks an AI’s awareness of another AI or the player and sends on/off signals to a trap when that awareness changes.  An AI in this context is anything that initializes the AI subsystem – generally, any object with an active AI behavior set (in the AI property).  Link the AI on which the script is operating to the target object with a ScriptParams link, data “afn” where n is an arbitrary string of characters; then, create another ScriptParams link to a trigger and set its data to “avn” or “aan” for visual or auditory response, respectively, where n is the same arbitrary string as you specified for the first link.  For example, linking a guard to the starting point with “afplayer” in the data and then to a light with “avplayer” in the data will result in the light triggering when the guard sees the player.


Please note that the AI and the object must be on different teams for the system to function properly.


TrapCamShift – TrapCamShift enables a static (immobile), Scouting Orb camera attachment to the object on which it resides.  Trigger it using a TurnOn message.


TrapFundament – This script is based on common trap functionality, but it does nothing significant.  Currently, its only function is to move any ControlDevice and ScriptParams links on its object from the starting point to the player on game start.

[1] Here’s how you do it in Thief 2.  Under Projectile, add a new arrow type.  Set “Render Type” to “Not Rendered”.  Edit the “Schema Class Tags” property and set it to “ArrowType MagicMissile”, which will make your setup believable.  Now, add a new Mech Priest archetype under the Mechanist category (make sure it’s not under Mech_Priest, because if you put it under Mech_Priest, it will inherit the projectile of its parent).  Add the following properties:  “RangedCombat”, with whatever settings you wish;   “AI”, “Human Spellcaster”;  “Schema Class Tags”, “CreatureType Servant”;  “Model Name”, “MecPrs01”;  “Script”, “Zapper”;  and link the archetype with the invisible arrow using AIProjectile.  Now, every heir of that archetype will be a zapper.  The procedure for Thief 1 is very similar.

[2] Please ensure that you use the string “1×2” after the script name if you want to take advantage of the new features.  This is required because “reusable=x” cannot be conveniently made compatible with the trap control flags that supplant it.

About this entry