| Excerpt |
|---|
Tasks are functions that Process Instances process during a trigger execute in sequence when they run. |
Creating a task
Create a function, then add it to a trigger like Process Instance like so:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
var myTaskFunc = function(params...) {
// task code here
}
function anotherTaskFunc(params...) {
// task code here
}
// add two tasks to "myTriggerfoo" process instance:
PulseProcesses("myTriggerfoo").addTask(myTaskFunc).addTask(anotherTaskFunc);
// Note: See triggerinstance.addTask() for more info on the .addTask() params
// You can also just add anonymous functions
PulseProcesses("myTriggerfoo").addTask(function(params...) {
// task code here
}); |
Note: Tasks are processed in the order in which they're added to the process instance.
There are several parameters to the triggerinstance.addTask() function that you should check out, such as defining the task name and setting a task scope and indicating that tasks should be player-iterated.
Task parameters
When the trigger processes process instance executes a task, it passes in a bunch of parameters as followsthe following parameters:
| Parameter | Type | Notes | Pulse Version |
|---|---|---|---|
| player | Number | The player ID the task is to process, see Task Iteration for more info. | 0.1 |
| taskData | Object | A container where a task can store data to access next time it runsdata container associated with the current task, useful if you want to store data for subsequent executions of the task.
| 0.1 |
| triggerDataprocessData | Object | A trigger-level data container , allowing tasks within that trigger to share data between themselvesassociated with the process instance, useful if you want to share information between tasks.
| 0.1 |
| runData | VariantAny | data that is passed in when a trigger run starts - see trigger() for more info A data container associated with the current process instance run. For example, it could contain information from the event that triggered the run. Tasks can also store information specific to the current run in this data container and then have instance.onEnd() event send the runData off to some other process or function. The runData object is deleted after each run, immediately after instance.onEnd() is fired. | 0.1 |
| timeRemaining | Number | The number of millisecods remaining on this game tick before game lag will be noticed by end users. Not an exact figure, but usually fairly accurate. Your task can use this to limit it's running time. If your task runs out of time, it can store where it's up to on the taskData object and return | 0.1 |
| triggerName | String | The name of the trigger process isntance that's processing executing the task. | 0.1 |
| taskName | String | The name of the task (specified or determined during triggerinstance.addTask()) | 0.1 |
Task return values
Tasks can optionally return 'true' to indicate they're not finished yet.
| Value | Type | Notes | Pulse Version |
|---|---|---|---|
| Anything that equates to Boolean false | If that task function does not return anything, or returns something that equates to false, the task is deemed to be complete for this run and the trigger process instance will move on to processing the next task. | 0.1 |
true | Boolean | If the task returns In this scenario, the trigger will stop processing any additional tasks on the current game tick, and on process instance will wait until a subsequent game tick will resume processing tasks starting with the one that was incompleteand then execute the incomplete task again. Your task can store where it was up to, etc., on the taskData or runData object so that it can pick up where it left off next time it runs. Just remember to clear down that info after the task completes. | 0.1 |
| PROCESS_STATE_ABORT | Constant | If the task returns this constant, the current process run will be aborted. | 0.1 |
| <error> | Any exception | The trigger will abort the current run. | Planned for 0.2 |
Notes
When a trigger runs (see trigger()) it process instance runs it will run each of its tasks in the order they were added to the trigger. If there isn't enough time left in the current game tick, some tasks may be deferred to a later game tick.
If game objects (anything derived from Base object) are stored in taskData, triggerData processData or runData, it's possible those objects have been destroyed before a task gets round to processing them so – so ensure you have good Error Handling around any code that processes game objects within a task.
| Div | ||
|---|---|---|
| ||
AvailabilityRequires:
Some changes to return values are planned for Pulse v0.2. |