A trigger in mission templates (and in module_triggers for that matter) takes the following form
First Part: how often the trigger is checked, either in seconds* or as a hard-coded event such as "ti_on_agent_hit"
Second part: the delay, in seconds*, between reading the conditions block and executing the consequences block. This does not work if you are using a "word"/hard-coded event interval, such as "ti_on_agent_hit"
Third part: the re-arm delay, in seconds*, between when the consequences block was finished and when the trigger can be checked again. A special re-arm delay "ti_once" is used for triggers that should only complete themselves (have their condition pass and then execute their consequence) once and then never fire again.
Fourth part: the conditions block, always executed when the trigger is called
Fifth part: the consequences block, only executed if the conditions block does not fail, and after the delay interval has passed.
*Note, unlike other numbers in the module system, the 3 intervals/delays of triggers do NOT need to be integers.
In practice, it looks like this:
Code:
(10, 2, 60,
[
(eq, 1, 1),
],
[
(val_add, "$global_variable", 10),
]),
In this instance, the check interval is every 10 seconds, so the trigger will be checked every 10 seconds. The delay interval is 2 seconds, so if the conditions block is true, the consequences block will fire 2 seconds later. The re-arm interval is 60 seconds, so after the conditions block is found to be true, it will be one minute until this trigger can be checked again.
The conditions block is a simple equality test 1==1, that will always pass, so the consequences block will always fire 2 seconds after the trigger is checked. The consequences block then takes a global variable and increments it by 10.
Timed Triggers
Understanding the check interval/delay/re-arm intervals of timed triggers can be tricky so here is an illustration:
Code:
(2, 1, 3, [<a condition that sometimes fails, sometimes passes>],
[
#some consequences
]),
This trigger, like all timed triggers with a check interval >0, will start to be checked around the first 1 second of the mission:
Code:
Second Event
1 Trigger checked; condition fails--apply check interval (+2 seconds)
3 Trigger checked; condition fails--apply check interval (+2 seconds)
5 Trigger checked; condition passes--apply consequence delay (+1 second)
6 Consequence fires and completes--apply check interval (+2); apply re-arm delay (+3)
11 Trigger checked; condition fails--apply check interval (+2 seconds)
13 Trigger checked; condition passes--apply consequence delay (+1 second)
14 Consequence fires and completes--apply check interval (+2); apply re-arm delay (+3)
19 Trigger checked....
So, although we have specified a "check interval" of 2 seconds, we see that the trigger is not checked only on even seconds; instead it is checked in seconds 1, 3, 5, 11, 13, 19.
If one wants a completely "scheduled" trigger, both consequence and re-arm delays cannot be used.
Two Triggers of the Same Type/Interval
When there are two triggers of that have the same check interval (be that in seconds, or on an event ti_*) the order they appear in the mission template matters. The trigger that appears first in the template will fire first, followed by the next trigger of the same interval, and so on. That means if you have two triggers that fire ti_on_agent_spawn, the one that appears in the file first will execute before the second one.
Triggers near the beginning of a Mission
Logically, the trigger ti_before_mission_start takes place before the scene is set up and before agents are spawned into the scene. Next, spawning takes place before any other triggers fire--ti_on_agent_spawn triggers are the only triggers firing at this point. Next, ti_after_mission_start triggers fire, as well as any triggers with a check interval of 0 (every frame) as the mission timer starts. Event-based triggers will not be called until their ti_* event occurs; other timed triggers begin being called somewhere in the first second of the mission, though after ti_after_mission_start triggers and every frame (check interval 0) triggers.
If you have triggers that do not need to fire that close to mission start, adding something like
Code:
(store_mission_timer_a, reg0),(gt, reg0, <second-to-start-checking>),
to the conditions block will help ease the CPU load at mission start.
Neither ti_before_mission_start nor ti_after_mission start need "ti_once" in their re-arm delay as they will only ever fire one time.
To summarize, at the start of a mission we have:
ti_before_mission_start
--Spawning-- (ti_on_agent_spawn)
--Time Begins--
ti_after_mission_start & triggers with check intervals of "0" (which fire @ a mission time of approximately 0.2 seconds)
--Timed Triggers (still within the first 1 second of the mission)
--Event-based triggers
