- Concurrency: tasks (blue stuff) can be run at parallel and a certain point of a task (percentage of completion, distance to end of path, etc) can trigger another parallel task.
- Variables: the usual flow diagrams break down when you have too many things to connect, solution? Use local variables!
- Ordered: the connections have order. This was important lesson learned from countless hours of debugging Crysis flowgraphs.
The arrows at the top of the tasks are execution points. When triggered, the task starting at that location will start executing.
There was also a syntax to define how the next tasks would have been triggered. In the above examples the next task is always triggered when the previous on is finished. I had an idea to also have some kind of notation to require all tasks to be finished before the next one was carried on.
The orange boxes are variables. Grey boxes are functions. Some functions take variables as input (could be stacked ala werkkzeug).
I think that "patrol point is not valid" should have a trigger line coming to it from the same bundle where the patrol point selection and restart is triggered (that eval would be 2 and restart would be 3). The grey text in the patrol box should actually read "Patrol(StartPoint)".
The overall design was much inspired by werkkzeug and PD.