ShockEd: The Grimoire: An Index of Traps - DeusDarkus

I admire your dedication.
--
This document is intended a reference document to all the various types of traps available, and a cookbook of sorts for interesting trap constructions that you can use in your level. It does not attempt to explain any of the more fundamental underlying concepts behind these systems - please refer to the object school documents for that level of information. Part 1 is a reference guide to all of the low level traps, and Part 2 is a listing of common trap constructions. Part 3 covers some useful tips & tricks for trap construction.

Part 1 - Taxonomy of Traps

All the low-level traps that are supported in the game are presented here, alphabetized by the name of the script. For those that have .GAM file entries, the name of the object in the hierarchy is listed in parenthesis afterwards. All of these can be found under the Traps category. The given script behavior can be put on any object by specifying the script’s name.

Unless otherwise specified, "sending out" a message means to broadcast it along all SwitchLinks going out of the object.

TriggerCollide (Collide Trigger)

Effect: Sends out a TurnOn message whenever the physics model on the trap is hit. Unlike most traps and triggers, this is usually put on some arbitrary object in the world, rather than being a separate distinct object. The base trap does not come with any interesting physics model, though of course one can be set on it.
TurnOn: Not used.
TurnOff: Not used.

TrapCutscene (DataTraps a CutsceneTrap)

See TrapEmail.

TrapEXP ( EXP Trap)

Effect: Gives the player a number of experience points set by the "Exp" property.
TurnOn: Gives the experience points.
TurnOff: No effect.

TrapDelay (Delay Trigger)

Effect: Used to introduce a time delay factor into a trap-trigger effect stream. Set the delay time with the Script a DelayTime property.
TurnOn: Sends out a TurnOn message X seconds later.
TurnOff: Sends out a TurnOff message X seconds later.

TriggerDestroy (Destroy Trigger) (2.19)

Effect: Sends out a TurnOn message when the object it is placed on is destroyed.
TurnOn: No effect.
TurnOff: No effect.

TrapDestroyer (Destroy Trap)

Effect: Destroys every object that it has a SwitchLink to.
TurnOn: Causes the destruction.
TurnOff: Not used.

TriggerEcology (Ecology)

Effect: Monitors the quantity of a set of objects on the level, and sends out messages when it wants to increase the quantity involved. Every N seconds (set by the "period" field), counts the number of objects in the world with a Script a EcoType property value matching the EcoType set on the trap. If that is below the minimum count, the trap will send out a TurnOn message. If the number is below the maximum value, but above the minimum, then there is a 1 in N chance (set by the "random" field) that it will send out a message. If the count is equal to or above the maximum value, it is guaranteed to not send out a message.

If this trigger receives a "Alarm" message, then it goes into "alert" mode, and if it receives a "Reset" message, it will return to normal. When in alarm mode, the trigger returns to normal mode after N seconds (set by the recovery field), and will send out Reset messages accordingly. The minimum count, maximum count, randomness, and recovery can be set individually for each mode, normal and alerted. All of those values, as well as the checking period, are set in the Script a Ecology property.

This trigger is intended in two different constructions. The first, is a level-wide general reinforcements system. This should never go into alarm mode, and should be tuned to provide a slow stream of critters so that the level is never totally empty. The period should be long, so that the changes are gradual. The other mode is for an "alarm response" system. This is a more complex construction, covered in detail in the cookbook part of the grimoire. Essentially, it wants to be completely inactive in normal mode, and be going off almost constantly when in alarm mode.

Note: The "hacked" mode has been removed, moved out to other systems, primarily the security computer.

TurnOn: Not used.
TurnOff: Not used.

TrapEmail (DataTraps > EmailTrap)

Effect: Add an email to the player’s PDA, and immediately play it, but do not bring up the PDA. Which email is set through the Logs > Deck N properties. Only the email sub-section of the property is used, and only one email bit can be meaningfully set on the property. No effect if the player already has the email.
TurnOn: Plays and adds the specified email. Sends out a TurnOn message if the player did not have the email before the trap executes.
TurnOff: Not used.

TrapGravity (Gravity Trap)

Effect: Controls gravity on an object. Good for making things fall or be nonphysical. Should usually be used by adding this script to the otherwise normal object in the world.
TurnOn: Sets gravity on the trap object to 100%.
TurnOff: Sets gravity on the trap object to 0%.
Notes: It is important to remember that this will only work if the object in question is a sphere model, not an OBB! Ballistic AIs might work as well, that is less clear. If you are setting up a sequence using this trap, you might want to override the physics on an object that usually has an OBB, so that it can fall. Also note that the object must not be Location Controlled (look at its Physics properties) in order to move when gravity is restored to it.

TrapInverter (Inverter)

Effect: Reverses the polarity of a TurnOn / TurnOff message.
TurnOn: Sends out a TurnOff message.
TurnOff: Sends out a TurnOn message.

TrapLog (DataTraps a LogTrap)

See TrapEmail.

TrapMedia (DataTraps a MediaTrap)

See TrapEmail.

TrapMessage (Message Trap)

Effect: Sends a message to the status line. The text of the message is controlled by the “Use Message" property, interpreted as a translatable string. Note that this script can be put on a trap that is already doing other stuff, to save yourself an object.
TurnOn: Generates the message.
TurnOff: Not used.

TrapMetapropByList (Trap Metaprop List)

Effect: Adds or removes a metaproperty from a set of objects, using object list syntax. The metaproperty to be added is defined by the Script > Metaprop Type property, while the object list used is set by the Script > Objlist Arg property. See objlist syntax reference at the end of this document.
TurnOn: Adds the specified metaproperty to all objects in the list.
TurnOff: Removes the specified metaproperty from all objects in the list.

TriggerMulti (Multi Trigger)

Effect: This is a trigger that only goes off when it has received a TurnOn message from every object that is SwitchLinked to it. After each object triggers it, the link between the triggering object and the Multi Trigger is destroyed.
TurnOn: Increments the counter by one, and destroys the link from the incoming object. When the counter is equal to the required number of hits, then the trigger will send out a TurnOn.
TurnOff: Not used.

TrapNewTripwire (New Tripwire) (2.32)

Effect: This is a trap which is activated by objects entering its physical space. Exactly how it operates is controlled by flags set in the Script > Trap Control Flags property. Here is a quick table of flags reference:
Enter: Sends out a TurnOn message when a physics object enters the space of the tripwire.
Exit: Sends out a TurnOff message when a physics object exits the space of the tripwire.
Mono: Tracking information is sent to the monochrome when the tripwire is operating.
Once: The tripwire will only ever send out one message (TurnOn or TurnOff), destroying itself after sending that one message.
Invert: Reverses any message coming out of the tripwire, so for example, entering the tripwire will send out a TurnOff instead of a TurnOn.
Player: Only activates on the presence of the player object, not any old physics object.
TurnOn: Not used.
TurnOff: Not used.
(Other flags to be implemented on request: Player activation, Limited (like once, but with a countdown))

TrapOffFilter (OffFilter)

Effect: Filters out all messages other than TrapOff messages.
TurnOn: Not used.
TurnOff: Sends out a TurnOff message.

TrapOnFilter (OnFilter)

Effect: Filters out all messages other than TrapOn messages.
TurnOn: Sends out a TurnOn message.
TurnOff: Not used.

TrapQuestbit (QB Trigger)

Effect: Checks a specified set of questbits, and sends out a TurnOn message along each if that questbit in non-zero, or a TurnOff if it is zero. This check is made every N seconds (specified by the Script a QBTimer property), and when the level is first loaded. Each Questbit link coming off of the trap is checked, and specified which questbit is to be checked in the data of the link.
TurnOn: Forces a questbit check.
TurnOff: No effect.

TrapQuestbitSimple (Simple QB Trigger)

Effect: Checks a specific questbit upon level entry, or when activated. Then sends out switchlinks along all of it’s connections in standard fashion, giving out a TurnOn message along each switchlink. The object then destroys itself once it has successfully fired. To specify the questbit & value that it is looking at, use the QB Name and QB Val properties, as are used in the QB Filter trap.
TurnOn: Forces a check of the questbit state.
TurnOff: Not used.

TrapQBFilter (QB Filter)

Effect: If the associated questbit is set, then it passes TurnOn and TurnOff messages through normally. However, if the questbit is not set, then it will block the transmission of that message. You can use this to form a simple type of logic in your traps, so that they do not kick in until a certain condition is met. If you find yourself building any kind of complex construction out of this, then your logic should probably get moved into a script proper.
TurnOn: Retransmitted or blocked based on QB state. If it transmits, will use the UseMsg property to send a message to the status line.
TurnOff: Retransmitted or blocked based on QB state.

TrapQBFilterOnce

Effect: Like TrapQBFilter, but only will ever activate once.

TrapQBNegFilter (Anti QB Filter) (2.27)

Effect: See TrapQBFilter. This has the same effect, but only passes along messages when the required QB condition is not met.

TrapQBNegFilterOnce

Effect: Like TrapQBNegFilter, but only will ever activate once.

TrapQBSet (QB Set)

Effect: Sets the value of the specified questbit, as controlled by the QB Name parameter.
TurnOn: Sets the QB to have a value determined by the QBVal property.
TurnOff: Sets the QB value to zero.

TrapRadCleanse (RadCleaner)

Effect: When activated via a TurnOn message, will remove all radiation from the player. Note that if the player is in a radiated area, they will immediately begin absorbing radiation again.
TurnOn: Clear out radiation on the object named "player".
TurnOff: Not used.
Notes: This is probably badly broken in multi-player, and may need to become it’s own special object so that it can directly operate on the frobber.

TrapRouter (Router)

Effect: Just passes along messages.
TurnOn: Sends out a TurnOn message.
TurnOff: Sends out a TurnOff message.

TrapShove (Shove Trap)

Effect: Provides a physics "push" to an object. Should usually be used by adding this script to the otherwise normal object in the world. The magnitude and direction of the push is determined by the Script a Shove property.
TurnOn: Applies the physics impulse.
TurnOff: Not used.

TrapSignal (Signal Trap)

Effect: Sends out a signal that AIs can respond to. The type of the signal is set by the "SignalType" property.
TurnOn: Sends out the signal to any AI that the trap is switchlinked to.
TurnOff: Sends out an "off signal" to any AI that the trap is switchlinked to. The off signal is just the same as the SignalType, with "Off" added to the end. So if the SignalType is "Ambush", the off signal is "AmbushOff".

TrapSlayer (Buffy the Trap Slayer)

Effect: Slays all objects that are linked to is via SwitchLinks. Use this instead of TrapDestroyer when you want to leave behind a corpse or cause a death animation to play.
TurnOn: Actives the slaying.
TurnOff: Not used.

TrapSound (Sound Trap)

Effect: Plays a sound, or halts a sound.
TurnOn: Plays the sound schema whose name is set with the Sound a ObjectSound property.
TurnOff: Halts any active schemas playing from the trap.

TrapSpawn (Spawn)

Effect: Generates an object of a randomly specified type, and at one of a variety of locations. The object is determined by choosing randomly among all the various objects specified. Each object type is assigned a weight W, and the total weights of all objects is Z. The chance of a given object coming up is W out of Z. The location of the object is specified by choosing randomly among all of the marker objects linked to the trap through a SpawnPoint link. Ideally, use the Spawn object. If the "self marker" flag is set, the trap itself is also used as a marker. If the PlrDist (Player Distance) flag is set, then the trap will exclude from consideration all markers that are within a certain predetermined distance from the player. If the PopLimit (Population Limit) flag is set, markers that have already generated an associated object are excluded. Any object generated will have a Script a EcoType property matching the EcoType property on this trap. This trap will only generate a number of objects total up to N objects, specified by the supply field. Leave this field at 0 to have an infinite supply.

If the object generated is an AI, additional behaviors apply. If the "goto player" flag is set, then the creature will attempt to directly go to the player’s location as of the time of the monster’s generation. If the trap has the AI a Ability Settings a Patrol: Does Patrol property set to TRUE, then the generated monster will also have that property set.

If the trap has a Sound > ObjSound property on it, then it will play the schema named by that property whenever a monster is successfully generated.

TurnOn: Causes the trap to generate a new object.
TurnOff: Not used.
Comments: Planned variant to generate once, and then destroy itself. Perhaps all “abnormal" properties on the object should be replicated on the spawned child objects?

TrapSuicide (Suicide Trap)

Effect: Causes the object to slay itself when activated.
TurnOn: Slays the trap object.
TurnOff: Not used.
Notes: Similar in effect to a TrapSlayer which is linked to itself, but more convenient.

TrapTeleport (Teleport Trap)

Effect: Teleports all objects that the trap is switchlinked to, to the location of the trap. So if there is a switchlink going from the trap to objects A and B, when the trap is activated, A and B will get teleported to the location of the trap. Both position and facing are altered.
TurnOn: Causes the teleportation.
TurnOff: No Effect.

TrapToxinCleanse (ToxCleaner)

Effect: When activated via a TurnOn message, will remove all toxin from the player.
TurnOn: Clear out toxin on the object named “player".
TurnOff: Not used.
Notes: This is probably badly broken in multiplayer, and may need to become it’s own special object so that it can directly operate on the frobber.

TrapTripOnce (Tripwire Once)

Effect: Like a standard TrapTripwire, but only goes off once, ever, when first entered.
OBSOLETE: Use TrapNewTripwire instead.

TrapTripLevel (Tripwire Level) (2.27)

Effect: Although this trap is activated like a standard tripwire, it’s effects are very different. This trap is only activated by the entry of the player. Once that happens, then the player moves to a new level, specified by the MultiLevel > Dest Level property. The specific location within that level that the player will appear at is determined by the MultiLevel > Dest Loc property. On the new level, the player appears at the location of a marker whose MultiLevel > Start Loc property matches the Dest Loc value.
TurnOn: Not used.
TurnOff: Not used.

TrapTripwire (Tripwire)

Effect: Generates messages corresponding to physics objects entering and exiting the physics model of the objects. A TurnOn message is generated whenever the model is entered, and a TurnOff message whenever the model is exited. If you want a tripwire that responds only to the player, use a TrapTripwirePlayer
OBSOLETE: Use TrapNewTripwire instead.
TurnOn: Not used.
TurnOff: Not used.

TrapTripwirePlayer (NIY)

Effect: See TrapTripwire, but only responds to the player’s entry and exit. Not implemented yet.

TrapTweq (Tweq Trap)

Effect: Control the Tweq properties on the trap.
TurnOn: Activates all tweqs on the object.
TurnOff: Halts all tweqs on the object.
Notes: If you are throwing off a one shot effect, don’t be afraid to set the “Sim" AnimC flag on the tweq. That way the trap will work regardless of whether the player can see it. Since many traps are invisible, this flag is often required. Important: make sure the TweqState on the property does not have any AnimC flags set, most notably “On". If the TweqState is on, then it will not wait for the trap before activating!

TrapUnlock (Lock Trap)

Effect: Causes objects that it is SwitchLinked to to become locked or unlocked. This does not change the state of the object this script is on directly!
TurnOn: Unlocks all linked objects.
TurnOff: Locks all linked objects.


There are also a number of "traps" that are fairly plot specific, but they are included here for completeness and reference. You probably shouldn’t use these unless you know what you are doing. They are not in the hierarchy, but can be placed by creating a generic "Traps" object and setting the right script (or scripts) on the object.

EraseRadiation (2.19)

TurnOn: Purges the "radiation level" property from all objects on the level, excluding the Player. This includes room brushes.

DestroyAllByName (2.19)

TurnOn: This will destroy all objects in the world that inherit from the archetype object described in the "ConsumeType" property.

TweqAllByName (2.27)

TurnOn: This will activate all tweqs on the objects in the world that inherit from the archetype object described in the "ConsumeType" property.
TurnOff: Like TurnOn, but halts the tweqs instead of activating them.


There are also many important ways in which TurnOn and TurnOff messages can get generated. Here is a quick reference summary.

Cameras
A camera, when it spots the player, will send out a message of any type, based on the data field of the camera’s link to a target object. For purposes of most traps, this should be either “TurnOn" or “TurnOff". Cameras are more normally used in security system construction, see the recipe in the next section.

Room Brushes
The BaseRoom, OnceRoom, and ExitRoom brushes will send out TurnOn and TurnOff messages along their links when the player enters and exits them. See object school documentation for more details. Messages are sent along SwitchLinks.

Buttons
Generic buttons send out TurnOn messages. Two-state buttons alternate between TurnOn and TurnOff messages. Keypads send out TurnOn messages when the right value is entered. Locked buttons required the player to be carrying the relevant keycard in order to send out their messages. All these messages are sent out along SwitchLinks.

Computers
Computers are like buttons in that they can send out their messages along SwitchLinks normally. They will also send out messages along their HackingLinks based on the player’s attempt to hack them. A successful hack will send out a TurnOn message. A critically failed hack will send out a TurnOff message.

Doors
A door will send out a TurnOn message when opening, and a TurnOff message when closing.

In addition, there are a handful of objects that respond to TurnOn / TurnOff messages.

Buttons
Buttons will act as if they have been frobbed when they receive a TurnOn message.

Doors
A door will open when it receives a TurnOn message, and will close on a TurnOff message. It will do this even if the door is locked, or does not have relevant FrobInfo properties.

Lights
Light objects with the basic animating light script on them will go their maximum brightness when they get a TurnOn message, and go to minimum brightness when they get a TurnOff message.


Part 2 - The Anarchist’s Cookbook

This section covers a variety of common constructions of traps to achieve cool and useful effects. Obviously, there are a near infinite number of legal constructions, but only a focused subset of those combinations are useful or relevant for our game. Collected here for your perusal is a set of these useful constructions, along with step-by-step directions for assembly. As designers create new and useful ones, they should be added to this document.

The following trap sets are generally ordered by complexity, but other than that are pretty random. Eit. When the directions talk about "linking" objects, unless otherwise specified, that means through a SwitchLink.

SHODAN Speaks
...or, the Overmind, or the ship’s computer. All that is required for this trap set is an EmailTrap, and a triggering method. The most common of these is either a room brush, or a TrapTripwire, linked to the EmailTrap. It doesn’t matter if the trap triggers more than once, since the EmailTrap will only go off once.
1. Construct a trigger (A). This should be a room brush, or a TrapTripwire. Place the trigger as desired.
2. Create a TrapEmail (B).
3. Set the Logs > Deck N property on B. Turn on the bit for the proper email number.
4. Link A to B.

Automap Kiosk
To wire up an info kiosk to give the player a map segment, it is a simple matter of using the TrapMedia script. Since the info kiosk itself is a "button" style object, this construction is easy.
1. Place an info kiosk object (under the Functional > Computers category).
2. Create a TrapMedia (B).
3. Set the Logs > Deck N property on B. Turn on the bit for the proper media (map) number.
4. Link A to B. For a special map that the player must hack into, use a HackingLink instead of a SwitchLink.

Light Switch
Two state buttons were made for this. This recipe is for a light that starts out off and turns on when first pushed, and will toggle off and on each time.
1. Place down a light object (A). This can be an abstract, invisble light object if you are using it just for a special effect.
2. Set the Renderer > AnimLight property on A. It’s minimum brightness MUST be zero. Set the mode to be "min value". Set other light properties to taste.
3. Place a two state button (B).
4. Link A to B.

Light Switch (On)
This is just like the Light Switch recipe, but the light starts on.
1. Place down a light object (A). This can be an abstract, invisble light object if you are using it just for a special effect.
2. Set the Renderer > AnimLight property on A. It’s minimum brightness MUST be zero. Set the mode to be "max value". Set other light properties to taste.
3. Place a two state button (B).
4. Add the TwoStateButtonOn script to B. Make sure the "don’t inherit" checkbox is set.
5. Link A to B.

Dramatic Spark Shower
If you want a repeating spark shower, just put down the RepeatingSpark SFX object (not implemented yet). This is for a specific spark shower that happens as the player is walking down a corridor, or otherwise at key dramatic times. This recipe can be easily altered to throw out debris or other
1. Construct a trigger (A). This can be either a TrapTripwire or a room brush. If there is not a good place to put in a trigger right where you want, consider adding a TrapDelay to time it properly.
2. Place a TrapTweq (B).
3. Add the Tweq > Emit property to B. Set the parameters to taste. For a one-shot spark shower, set numframes to 1, and rate to 0. Different emitted objects will generate different special effects. Depending on what object you emit, you probably want to only emit 1 object, as particle objects appear as many particles. Remember that you want the TweqEmit to use the "Sim" AnimC flag, and that the TweqState must not be set to "On".
4. If you want this to be a one-shot effect (which you probably do), make sure you set the tweq on B to "destroy obj" when halted.
5. Link A to B.
6.
If you also want a sound effect at the same time:
7. Create a TrapSound (C). Set the Sound > Object Sound property to the name of the sound schema to play.
8. Link A to C.

Broken Door
For a broken door with a little extra pizzazz, try this recipe.
1. Create your door (A) as normal.
2. Set the Door > Translating or Door > Rotating property on A to not open all the way.
3. Create a TrapDelay (B). Set its time (Script > Delay Time) to the same amount of time it will take for the door to stop moving.
4. Create a TrapTweq (C). Set its Tweq > Emit property (see the Dynamic Spark Shower recipe for more information).
5. Link A to B.
6. Link B to C.

Locked Door
Here is a fairly standard construction for setting up a locked door that, after being unlocked, will open automatically on a tripwire. The basic idea is that the tripwire is routed through the keycard slot, which, if locked, knows not to relay the message. Once it becomes unlocked, the message will flow through as normal. This has the extra advantage that if you put a keycard slot on both sides, only 1 needs to be unlocked in order for the door to function normally.
1. Create your door (A).
2. Put down 2 keycard slots, one on either side of the door (B & C). If you door can only ever be opened from one direction, you can omit object C.
3. Create a tripwire (D).
4. Set the "Locked" bit on B (and C).
5. Set the "KeyDst" on B (and C) to match the kind of keycard required to open the door.
6. Link D to B.
7. Link B to A.

The additional steps should be followed only if you have an object C (two slots).
8. Link D to C.
9. Link C to A.
10. Create an Unlock Trap (E).
11. Link B to E.
12. Link C to E.
13. Link E to B.
14. Link E to C.

The idea with the Unlock trap is that if one card slot is activated, it will unlock the other card slot as well (so that it’s color changes to green, and so on).

Watch Out For Falling Debris
To make things fall to the ground, you have two options. One simple option is to just use a tweq trap along with a tweq emit, as illustrated in the Dramatic Spark Shower recipe. However, if you want something already fine and in the world to come plummeting down, you need something different.
1. Create your falling object (A). This object MUST have a Sphere physics type in order for this to work. For this purpose though, you can have objects that are normally OBBs, like doors or railings, pre-placed with an overriding physics model just for this purpose.
2. Create a trigger, usually a room brush or a tripwire (B).
3. Put the TrapGravity script on object A. You probably want to set the "don’t inherit" flag.
4. Link B to A.

If you want to play a sound effect as the object falls, add the following steps:
5. Create a TrapSound (C). Set the Sound > Object Sound property to the name of the sound schema to play as the object begins to fall.
6. Link B to C.
7. If you want a sound effect as the object hits the ground, coordinate with Eric or Kemal about setting up a collision sound schema for the object in question.

If you want the object to get destroyed when it hits the ground, you can add the following steps:
8. Put the TriggerCollide script on A.
9. Create a TrapDestroyer (D).
10. Link D to A.
11. Link A to D.

Light Change
Often you want a dramatic change in lights when some key event happens. For example, in an ambush you might want to turn off one set of normal lights while turning on a set of colored "alert" lights. Another common use is for restoring power to part of the ship. This sort of construction is the only way to change the color of lighting in an area.
1. Instead of lighting the room normally through light brushes, use animated lights set to the "max value" mode. This set of lights is object set A.
2. Create a set of lights, using animated light objects, that will provide the altered light state. After testing these lights, set their Renderer > AnimLight property mode to "min value". This is object set B.
3. Create a trigger object (C). As usual, these can be anything that sends out a TurnOn message, but is usually a room brush, tripwire, or button. If C can generate TurnOff messages, it will restore the original lighting mode.
4. Create a TrapInverter (D).
5. Create a TrapRouter (E).
6. Link C to D.
7. Link C to E.
8. Link D to every object in set A.
9. Link E to every object in set B.

To just turn out the lights, only do steps 1, 3, 4, 6, and 8.

Reinforcements
This is a standard, but moderately complicated trap / trigger system. You should set up this construction in each major area of your level, and then tune appropriately. Several other recipes require this framework to be in place first.
1. Create a TriggerEcology (A). Set the various Script > Ecology properties including the period, as well as the parameters for monster generation in normal, hacked, and alert modes. Set the Script > EcoType property to a unique value on the level, X.
2. Create a TrapSpawn (B). Give the object the Script > Spawn property, and set the fields for possible monster types to generate. Turn on only the population limit (PopLimit) and player distance (PlrDist) flags. While you can set the SelfMarker flag as well, I recommend against it. Set the Script > EcoType property to X. A trap with these flags already set can be found in the object hierarchy as "RandMonsterGen".
3. Create a set of spawn point markers at key points in your level. This is object set C. Pay attention to plausible paths that the monster could have come from, and be careful not to put too many in one area. Remember, each spawn marker can potentially have one monster at it, but never more than one, so put down 2 if you want a heavily reinforced area.
4. Create any appropriate patrol routes near any relevant markers (C). Set the AI > Ability Settings > Patrol: Does Patrol property on C.
5. If you want any monsters to already be under the accounting of this zone, set their Script > EcoType property to X.
6. Link A to B. (SwitchLink link flavor)
7. Link B to every object in set C. (SpawnPoint link flavor)

Security System
Security systems are a standard gameplay construction that we use numerous places throughout the game. Essentially it is a linked ecology and camera, where the camera can bring a horde of monsters down on the player while the alarm is up. Alarms can be taken down through security computers, and the state of the alarm is given through alarm screens. All of this comes together into a fairly complex construction. Fortunately, almost all of these in the game are built in the exact same way, so once your learn this recipe, you can replicate it several times in your levels.

1. Create a Security Camera (A), found under the Monsters category. Tune the various AI perception properties on A to control how quickly it spots the player. With the Camera: Parameters property, You can also tune how fast it rotates, and the arc it covers.
2. Create an Ecology (B). See the TriggerEcology entry for a detailed description of the various fields. Place zeroes in each of the fields for the “normal" states, as they are not used by this system. When the alarm is activated, it should be guaranteed that creatures respond. You should set a short “period", like 10-15 seconds. “Alert Min" and “Alert Max" should be close together, and less than or equal to the number of markers you will create during Step 4 of this procedure. “Alert Recovery" is the number of seconds it will take for the alarm to reset itself, and a value of 15 is recommended.
3. Create a TrapSpawn (C). Turn on only the PopLimit, GotoLoc, PlayerDist and SelfMarker flags. A trap with these flags already set can be found in the object hierarchy as DirectMonsterGen. Put (C) at the point where you want one of the reinforcement monsters to be generated.
4. Place one or more additional spots for reinforcement, D1…Dn. These should be ordinary markers (or you can use the Spawn Marker for clarity). You should have as many total reinforcement spots (C + D1 + D2 + … + Dn) as you want maximum monsters to show up in full alert mode. Keep in mind that some of these may not activate immediately due to player proximity, so ideally pad it upwards by about 1.
5. Create a Security Computer (E). Whether or not the camera can see the computer can strongly change the nature of the encounter. Set the Player > Hack Duration property on it for how much benefit the player gets out of hacking into it. Merely frobbing the computer will disable the alarm. Set the GameSys > Hack Text for any special hacking text. Set the GameSys > Hack Diff property to control the ease of hacking.
6. Place one more more Alarm Screens (F1 _ Fn). These will change between a “security alert" mode and a normal mode depending on what is going on with the alarm.
7. Whew, all the objects placed. Now we begin a lot of links. First, put a normal Switchlink (not an AICamera link) between A and B.
8. Put a reciprocal Switchlink between B and A.
9. Link B to C.
10. Link B to all the objects in set F.
11. Put a SpawnPoint link between C and each of the objects in set D.
12. Link E to B.

Apparition
This is for an entire apparition apparatus, that is, the apparition as well as the ectoplasm that both begins and serves as the trigger for the apparition.
1. Create an Ectoplasm object (A).
2. Create an Apparition “monster" who will be carrying out the activity (B). Note that there are a few varieties of apparitions based on model in the hierarchy, but any should do.
3. Create a marker that is the starting location for the apparition (C).
4. SwitchLink A to B.
5. Put an AIWatchObj link from B to A. Note the order is reversed from the SwitchLink! This link is link “L".
6. Set the radius & height parameters on L for the distance at which the apparition should trigger.
7. Set the the step 1 action on L to be “Signal". Set the first parameter to be “apparition". Set the second parameter to be the object ID of B.
8. Set the link kill parameter on L to be “Kill on trigger".
9. Put the AI > SignalResponse property on B. It should already have a bunch of data set by default. Fill out steps 2 through 5 to be the actual content of the apparition.
10. Create an ApparStart link between B and C.

That should be enough to get your basic apparition going. If you want to have multiple apparitions running off of the same ectoplasm object, just repeat steps 2-10 with a your new objects B and C. More complex synchronization can be achieved by playing with the pseudoscript data in step 9.

Staggered Lights
Sometimes you may want a series of lights to turn on over time, so that one comes on, then the other, then the other. While you could do this with a series of Delay Traps, this is a common enough construction that there is a special script to facilitate it.

1. Set up a normal light switch construction, with a light A.
2. Put the DelayLight script on A instead of BaseLight.
3. Set a Script a Delay Time property on the light which is how long it waits after receiving it’s turn on message (or turn off message) before actually responding.

Simple Pseudo-Script
Pseudo-scripts are a powerful tool for controlling AI behaviors in certain situations. Their control and function is beyond the scope of this document, but they can be used for all sorts of simple AI scripted behaviors. Here is an easy recipe for triggered pseudo scripts in the familiar SwitchLink metaphor that you are familiar with.

1. Create a monster, A.
2. Create a trigger of whatever variety you choose, B.
3. SwitchLink B to A.
4. Put an AI a Signal Response property on A.
5. Set the signal type to be SwitchOn (or SwitchOff, as you please).
6. Fill out the pseudo-script in the Signal Response property to get your customized behavior.

Refer to R:\PRJ\CAM\DOCS\TECH\AI\DARKAI.DOC for more detailed information regarding the use of pseudo-scripts.

Object Consuming Button
This construction should generally only be used for specific plot-blocking constructions. It will create a device that needs something put in it, like a power cell, circuit board, command codes, that sort of thing. When the right object is used on it, it will “eat" the object in question, activate any tweqs on itself, and sends out TurnOn messages like a 1-state button does. The device will only ever activate once.

1. Place your device, such as the power override device on medsci. It should be using the model that is the “empty" state. This is object A.
2. Put a script > consume type property on A. Set the value to the hierarchy name of the kind of object that it eats. For medsci, this is "power cell".
3. Put the "ObjConsumeButton" script on A. Remember to set the “don’t inherit" flag.
4. Put any appropriate tweqs on A. They will be activated when A gets "fed", just like when a TweqTrap goes off. This should probably include a TweqModel to the version of the model that has the cell embedded in it.
5. Hook up appropriate doors, special effects, off of A. It will send out a "TurnOn" when it gets fed correctly.

Unlocking Remotely
If you have a button or tripwire somewhere that you want to unlock a door elsewhere, use this recipe. This is very useful for plot events that unfold and as part of the chain of activation, want to open some doors elsewhere on the level.

1. Construct an appopriate trigger object A.
2. Place down your Unlock Trap, object B.
3. You should have a tripwire -> keycard slot -> door assembly. The keycard slot is object C.
4. Link A to B.
5. Link B to C.

If you want to instead lock the keycard slot when A goes off, remove the inverter from the assembly.

Invisbly Locked Door

The standard tripwire -> keycard slot -> door construction works great in the standard case, but what if you want a door which is doesn’t unlock via a card slot, but does become operative later in the game? Just construct a standard locked door, and make the cardslot have no refs. This is a good combination with the Unlocking Remotely recipe listed above.

Plot-dynamic Ecology
Sometimes in the game you will want to change the monster ecology / spawning behavior based on plot events. The QBFilter trap is the key to achieving this. This recipe discusses an ecology which does nothing until a certain piece of quest data is set, at which point it will kick in.

1. First, you must have an otherwise normally functioning ecology / spawn construction. The ecology trigger is object A, and the spawn trap is object B.
2. Remove the SwitchLink, if any between A and B.
3. Create a QB Filter Trap, object C.
4. Link A to C.
5. Link C to B.
6. Set the Script > QB Name property on C to be the name of the quest data that you are filtering on.
7. Set the Script > QB Val property to be zero.

If you want to have one ecology that operates before the quest bit, and a different one afterwards, then use two questbits, so that one is set when the other is not. Then set up two parallel ecologies (they can connect to the same spawn), each one going through it’s own filter for the specific QB that it wants to use.

Killing A Group

If you want something to happen when a number of creatures are killed, then use the following construction:

1. The creatures that are required to be killed are object set S1.
2. Add the “TriggerDestroy" to each object in set S1. Make sure you choose the correct setting for whether the script should inherit, based upon other scripts on the object. You probably DO want to inherit (so leave the checkbox unchecked in the scripts property).
3. Create a Multi Trigger (A).
4. Whatever trap you want to go off as a consequence of successfully destroying all the creatures is object B.
5. Link each object in set S1 to A.
6. Link A to B.

Part 3 - Useful Tricks

· Use TrapRouters to break down complicated trap into manageable subsections. For example, if you want a trap which turns on a bunch of lights, and turns off a different bunch, make one router for all the “on" lights, and another for all the “off" lights. Then trigger both of them individually from the master trigger. This can be much simpler than having one trigger with a giant pile of links coming off of it. This works especially well with lights (see the Light Change recipe).
· If some complicated trap is not working properly, test individual sections by linking plain old buttons to segments of your trap chain. Start with the smallest, final effect, then work your way backwards until the whole trap is working. Isolate the problem, then you can solve it more easily (or bring it to a programmer’s attention).
· If you want a given trap to only work once, take a key element of the trap sequence (often the trigger, or a router placed immediately after the trigger for this purpose) and put the TrapSuicide script on it. That way as it does it’s thing, it will eliminate itself, causing the trap not to go off in the future. You don’t need to take this precaution with the various data (log, cutscene, email, media) traps, since they know to do nothing if the player already has the data.