One note, in this post when I mention “abort system” it will mean the system similar to the one used in event driven behaviour trees.
There is nothing wrong in caching nodes, it is indeed common and I implemented my tree also with suspending execution. My point here is that the tree is not fully implemented in the way it should be, so for example if there is node caching, then there should be abort system (or something similar) implemented from the start to make the tool fully complete in it’s design.
About parallel - if you have real tree without merging branches, then aborting would probably just revert everything below and buble up. However there are various types of abort: Self, Lower Priority and Both. Here is the first problem, should everything below Run in parallel… node be treated like two separate subtrees or just part of this single tree? This is more of design problem than a question.
Consider the tree below, we are running two waits in parallel, then assume the condition (red arrow) is the aborting node.
In case of Self
abort, the left wait should be probably aborted or anything running below it.
But what if abort is set to Higher priority
? Should we abort parallel (right) wait? If we take into account parallel branch in priority system, then is it really parallel, and does the order of subbranches matter? If not, then can we abort this branch in case they are considered like completely parallel tree?
And very important question, where it actually ends? Do we just reset right side and after abort the left one will continue only? Or we just reset right side to Run in parallel until…?
Consider different graph with merged branches:
There are parallel branches running the same part of the tree (bottom sequence).
When I run the tree, the right parallel branch will finish first and bubble the sucess to the top of the tree, while parallel branch need to finish the last running wait.
Currently the graph stucks forever in the weird state, waiting for the last running wait node, but at the same time it’s in success state. Even if I enable repeat, it never starts again, it’s stuck forever, what I believe is just a bug. However that is not the point here, what I want to show in this example is that in this case branches can’t be even considered separate. What should we do if we enable abort for higher priority nodes? Do we abort everything? each branch does it separately? It’s complicated as there is no just one state, but multiple states.
It would become probably even more crazy if we consider running multiple root nodes with merging points or loops.
To be clear you don’t need to answer all those questions here, I just try to show my point of view and I think everything comes back to:
During the design stage, did you consider problematic cases and you found a solution to them (but they are not implemented right now), or you are trying to solve problems on the fly (que sera, sera)? I mean both common behaviour tree problems, and also things you put on yourself by deciding to add uncommon features or taking different approach.