Sample Trigger Entity for trigger1
A Trigger is an entity that is activated when there is a collision with its associated model. Every trigger must have a model associated with it through the Model entry in the entity structure. If this model is animated then the animation will start when the trigger is activated. A trigger does not directly control any other entity. Instead, it sets an internal flag to indicate if it is active (on or true) or inactive (off or false). Other entities read this flag to determine the state of the trigger.
When a trigger is activated it stays on for the number of seconds entered in the TimeOn field. It then stays off for the number of seconds entered in the TimeOff field before it can be reactivated. If the bOneShot field is true then the trigger will only activate once.
The szSoundFile field contains the name (if any) of the WAV file to play when the trigger is activated. The bAudioLoops field is used to indicate if the sound plays once or is repeated.
If the bShoot field is true then the trigger can only be activated by shooting it, not by the player hitting it.
If the UseKey entry is true then the trigger can be activated by the Use key.
If the PlayerOnly entry is true then only the player can activate the trigger by collision.
Triggers can also be triggered. If there is a entity name entered in the TriggerName field then the state of that entity will be checked and must be on before the trigger can be activated. If the state of the TriggerName field entity is off and you attempt to activate this trigger then its callback flag will be briefly set to on. We will see how this can be used when we look at Logic gates.
|
Sample Trigger Entity for trigger1 |
This sample entity defines a Trigger called trigger1. It is attached to a model called door1trigger which, if animated, will run at 100% of the defined animation speed (AnimationSpeed = 1.0). It is non-shootable and will, when activated, stay on for 5 seconds then turn off for 1 second before it can be activated again. This trigger is activated when the player collides with the model called door1trigger. No sound is played when the trigger is activated.
Controlling a Door
Lets look at how we can use the sample trigger to control the opening of a door. First we will examine a door that will open when the trigger is activated. After that we will look at a door that must be hit by the player after the trigger is activated to open.
 |
Sample Door #1 |
The important entries in the door entity (at least for triggers) are bNoCollide and TriggerName. We have set the TriggerName to the entity name of our sample trigger, trigger1. This allows trigger1 to control the opening of the door. Since bNoCollide is set to true the door does not require a player collision to active it. Instead the state of the trigger determines if the door is activated. When trigger1's state is true the door is activated and the door model animates, thus opening the door.
 |
Sample Door #2 |
The difference between this door and the previous door is the state of bNoCollide. In this door it is false, which requires the player to collide with the door before it will open. Since there is also a trigger associated with this door its state must be on when the player collides with the door or nothing will happen. Since the trigger is only on for 5 seconds after activation the player must collide with the door within this timeframe in order to activate the door opening. If you collide with the door when the trigger is off, the door's callback flag is briefly set to on. This can be used by Logic Gates to activate other entities.
NOTE: Platforms are controlled in the exact same manner as doors so everything previously said about doors also applies to platforms.
Logic Gates are an entity that gets the state of a trigger (or triggers) or another Logic Gate (or gates) and sets its own state from this. There are two fields that hold the entity name of the trigger or gate. These are Trigger1Name and Trigger2Name. Some types of gates require two trigger entries while others require only one. The Type field is used to determine what type of gate the entity is. There are 12 different types of logic gates:
Type 0 AND - its state is the logical AND of Trigger1Name state and Trigger2Name state.
State of Trigger1Name |
State of Trigger2Name |
State of And Logic Gate |
Off |
Off |
Off |
On |
Off |
Off |
Off |
On |
Off |
On |
On |
On |
Type 1 DELAY - when the state of Trigger1Name changes from off to on it waits for the number of seconds entered in the Delay field before changing its state to on.
Type 2 NOT - its state is the inverse of the state of the Trigger1Name entry.
State of Trigger1Name |
State of Not Logic Gate |
Off |
On |
On |
Off |
Type 3 OR - its state is the logical OR of Trigger1Name state and Trigger2Name state.
State of Trigger1Name |
State of Trigger2Name |
State of Or Logic Gate |
Off |
Off |
Off |
On |
Off |
On |
Off |
On |
On |
On |
On |
On |
Type 4 XOR - its state is the logical XOR of Trigger1Name state and Trigger2Name state.
State of Trigger1Name |
State of Trigger2Name |
State of Xor Logic Gate |
Off |
Off |
Off |
On |
Off |
On |
Off |
On |
On |
On |
On |
Off |
Type 5 FLIPFLOP - when the state of Trigger1Name changes from off to on the state of this gate is inverted (i.e. if it was on then it is off and vise versa).
Type 6 CALLBACK - its state is set to the state of the callback flag for the Trigger1Name field entry.
Type 7 HOLD - when the state of Trigger1Name changes from off to on the state of this gate stays on for the number of seconds entered in the Delay field before being set to off.
Type 8 ATTRIBUTE - Trigger1Name is the name of an attribute of the player. The state of the gate is on if the amount of this attribute is greater than the amount specified in Amount.
Type 9 ALWAYS ON - when the state of Trigger1Name changes from off to on the state of this gate stays on after that, regardless of changes in the state of Trigger1Name.
Type 10 USE ATTRIBUTE - this gate is on if the active Use attribute is the same as the attribute specified by the name in Trigger1Name.
Type 11 CLEAR USE ATTRIBUTE - when the state of Trigger1Name changes from off to on, and if the active Use Attribute is the same as the name specified in Trigger2Name, then the Use Attribute is cleared and the Hud element is deactivated.
Type 12 CHECK ENTITY CONTENTS - This gate checks the model contents that the desired entity actor is currently in and goes on if the contents match the desired one. Trigger1Name is the name of the model contents. This is the type you set in Brush Properties in the editor. This name can be one of the following:
Trigger2Name is the name of the entity or Player for the player actor.
Type 13 STOP OXYGEN RESTORE - Normally the player's oxygen attribute is restored to maximum whenever he is not submerged in a Liquid. This gate checks its Trigger1Name entry and, when it is on, stops the automatic restoring of the oxygen attribute. If Trigger1Name is off the restore is not halted.
Type 14 DIFFICULTY LEVEL - Trigger1Name must contain one of the following names: Easy, Normal or Hard. The gate is on if the difficulty level matches the desired name.
Type 15 ACTIVE WEAPON SLOT - Trigger1Name contains either a weapon slot number between 0 and 9 or All for any weapon. The gate will be on if the active weapon slot matches this number or, in the case of All, if any weapon is active.
Type 16 CHARACTER NAME - Trigger1Name contains the name of one of the characters that can be selected from in the Character Selection menu. The gate is on if the name of the character in use matches this name.
NOTE: When an entity has a TriggerName field either the name of a Trigger or a Logic Gate can be entered there. This makes it possible to hook gates and triggers together to create a complex action.
Controlling Entities with Triggers and LogicGates
We will now look at several examples of controlling entities using multiple triggers and logic gates. The first example will be a door that can be activated by either of two triggers.
|
|
 |
 |
Lets look at what has been done here. First, we have two triggers, called trigger1 and trigger2. Next we have a LogicGate (called OrGate1) whose type is 0, which is an Or gate. This gate requires two triggers which we have set to be trigger1 and trigger2. Last, we have a door with bNoCollide set to true so it is solely controlled by the trigger, which is set to be OrGate1, our logic gate. Now lets see what happens when a trigger is activated. When the state of either trigger is on the state of the Or gate is on, which in turn activates the door.
Next is a light that is controlled by a trigger configured like a light switch - you turn the light on and off by hitting the trigger.
|
 |
 |
You will notice that we have modified trigger1 so that the on time is now 1 second. This means the trigger can cycle every 2 seconds. If you want it to cycle even faster just change the TimeOff and TimeOn values to even smaller numbers. The logic gate, named FlipFlop1, is of type 5, which is a flipflop. A flipflop holds its state until the trigger's state changes from off to on. Then it inverts its state. Therefore, each time we activate trigger1 the logic gate FlipFlop1 inverts its state - i.e. it goes from on to off or off to on. This mimics a normal on/off switch. The dynamic light uses FlipFlop1 as its trigger so it activates when FlipFlop1's state is on and deactivates when it is off.
When Triggers, Doors or Platforms are controlled by a trigger they can generate a Callback state. This happens when you attempt to activate them, by player collision, when the trigger state is off. A Teleporter always generates a Callback state on collision. This Callback state is only on for a few clock cycles but can be detected by a logic gate of type 6 (Callback). This gate can then be used to trigger some other entity. The most obvious use of the Callback is to display a message if you attempt to open a door that is "locked". We will now look at an example of just that.
|
 |
 |
 |
First, we have a door (called Door2 since there is no szEntityName) controlled by a trigger called trigger1. The door must be collided with after the trigger is activated to make it open. There is a logic gate of type 6, Callback, which is triggered by the Callback state of the door. The state of this logic gate is on when the Callback state of the door is on. This happens if you collide with the door when the state of the trigger is off. Lastly, there is a message entity that is triggered by the state of the Callback1 logic gate. When it is triggered it will display the text message "Hit the Trigger to Activate the Door" for 5 seconds before deactivating.
NOTE: the Trigger1Name of a logic gate of type Callback must be either a Trigger, Door or Platform name. These are the only entities that generate a Callback state.