An objective must have one or more tasks. Not all tasks needs to be mandatory, but if you won’t flag at least one task as mandatory then objective will be ignored during “goal” evaluation (this is not bad by itself, just be aware of that).
[updated] How Tasks are organized in objectives
- We define the tasks inside the Objective element.
- A task can be "dependent" on other task or
- Be flagged as "mandatory", which means, it is part of Objective success evaluation.
A dependent task, creates order between tasks. This means that “dependent” tasks won’t be evaluated until at least the “parent” task will be flagged as “complete” at least once (complete = success).
How Objective is being flagged as success
When we have a mandatory task, one or more, the objective tests if ALL mandatory tasks are flagged as complete (success).
This means that you must be careful when you set a task as “mandatory”, since the plugin will expect ALL of them to be “complete” when it evaluate them.
An objective won’t be set as “complete” (success) as long as one of its “mandatory” tasks is not “complete”.
Non mandatory task is ignored during evaluation of objective.
A “Task” is a new concept in Mission-X v3, the idea is to define a "to do" action that combined with other tasks will create an objective and goals.
A task highlights “what needs to be done”. It has certain configurations that take shape during Objective iteration.
A task must be linked to a trigger or a script. The bulk of logic resides in them.
plugin keep track on task status changes using the following flags:
You can see that the definition of a mission is much shorter than in Mission-X v2, but it also not hierarchy organized, so you need to keep track of what you are doing.
[09-oct-2017] uploaded better image. Click on image for larger view.
There is no one way to create a mission file. You can start from:
- Tasks in Objective
- Triggers, messages
The mission file I pasted here, is divided into categories for easier reading.
A task is merely a template that define an action a simmer need to fulfill.
A task needs to have a unique name and can have title to display to the simmer. It must be based on a trigger or a script. When you base a task on trigger, you probably want it to be based on a physical location, like when a plane touchdown a runway, for example.
The last attribute I want to comment on, is the "always_evaluate". This means that even if a "task" has been completed (meaning success), the plugin will continue to evaluate it and modify its state.
A set of tasks (1 is also fine), represent an Objective.
An objective have 1 or more tasks in it. One task should be a mandatory ( I'll speak on that topic later).
Key attributes for Tasks:
- "name" of the task - must be unique in Objective.
- "depends_on_task": A task can be dependent on other task, which help optimize performance.
- "mandatory": If a task is mandatory.
"always_evaluate": This is an important attribute, it basically tells the plugin that even if the task "is complete" the plugin will continue to evaluate it, and modify its state. This is crucial for a success design of multiple mandatory tasks in same Objective.
- Task 1: you need to enter park area.
- Task 2: you need to pull park-brake, in the park area.
Both of the tasks are mandatory. Which means that plane must be in the parking area during "Task 2".
If you won't define the attribute: "always_evaluate" for both tasks, it might not behave as you expect, and Objective can be flagged success even when plane has exit the park area.
The "depends_on_task" attribute, allow us to define order of evaluation against other tasks only in same objective.
For example, lets assume we want the simmer to land in KOAJ airfield, and then park in GA parking area.
For that we prepare two tasks: "ReachParkArea" and "ParkInKOAJ".
You can check the mission image above. Please pay attention that the "ParkInKOAJ" task is dependent on "ReachParkArea", which means that the plugin will first evaluate any not dependent tasks and then will evaluate all their dependent tasks recursively.
This allow the plugin and designers two things:
- Plugin does not need to evaluate dependent tasks if their "parent" task is not complete.
But if the "parent" task was flagged as complete at list once, then the dependent task/s will be evaluated,
- A designer can direct the simmer which steps to do to achieve an Objective.
Example: We can create a set of tasks that define a run-up test of a Cessna 172c.
In this case we should only flag the last task as mandatory, and thus we will have a complete objective.
Please be advice that this is a snippet of a test mission, so there isn't much detail in it, and design might change, although the concept should be the same.
Until next time
Have great time simming