Triggers are themselves functions – so you can just run them directly to make them process their tasks.
Syntax
// Preferred method (for code clarity):
Pulse("yourTrigger")(obj, maxDuration); // retrieve "yourTrigger" via Pulse() and then run it
// Alternate method (for code brevity):
yourTrigger(obj, maxDuration); // run a "yourTrigger" via it's global function
Parameters
Be sure to read important notes below to fully understand the persistence and possible side effects of using these parameters!
Parameter
Type
Mandatory
Notes
Pulse Version
obj
Variant
Optionally pass in an object (or anything else) and it will be passed through to tasks when they are processed.
0.1
maxDurtion
Number
Optionally define the maximum amount of time the trigger should process tasks for per game tick.
Note: The duration will be limited to PULSE_GAME_LAG.
0.1
Return values
A boolean return value indicates whether some tasks were deferred to a later game tick – are there some tasks left to be processed?
Value
Type
Notes
Pulse Version
true
Boolean
Some tasks are deferred to a later game tick
0.1
false
Boolean
All tasks for this run have been processed.
0.1
Notes
Running a trigger directly via the trigger function has the exact same effect as running it via trigger.run().
Each time a new trigger run is started, the parameters (obj, maxDuration) are stored so they can be passed in to each task being processed in that trigger run. For this reason, it's not advisable to put game objects (anything derived from Base object) in to the "obj" param as they might get destroyed before the task processing them is run. If you must pass in a game object, then just make sure you have decent Error Handling around any code that interacts with it.
If another trigger run is started before the current one is finished, it's parameters will be queued up (in an array, so there can be multiple runs queued) while the in-progress run is completed to ensure the tasks of the current run get the expected parameters. When the current run finishes, the current parameters are cleared down and the queued parameters restored ready for the new run.
If a trigger has more than PULSE_MAX_QUEUED_RUNS in its queue, warning messages will be shown, indicating that a bigger interval or some other corrective action is required by the developer.