Decorators don’t all execute top-to-bottom!
While it’s true that “conditional” decorators do execute top-to-bottom in a group, that shouldn’t usually matter. (“Conditional” decorators shouldn’t be changing any values anyway, so they won’t have any effect on each other. Basically they act as a big list of “And” requirements; the only reason the order matters at all is as a possible performance optimization, but generally that won’t rise to a level where it actually matters.
Other types of decorators (“standard” decorators) don’t necessarily execute in any order relative to the conditional decorators. For instance, “Force Success” happens whenever the subtree (including the node “Force Success” is on and all of its decorators) is going to return for any reason. In that case, if it’s failing, “Force Success” will change the return value to true. So for example, if you have a node with “If Goal Is Set” and “Force Success” on it, it doesn’t matter what order those decorators are in! Force Success occurs when the node returns, which could be when “If Goal Is Set” returns false. So even if “If Goal Is Set” is above “Force Success”, success will STILL be forced when “If Goal Is Set” fails!
Similarly, “Loop” as a decorator also happens when the node returns, so all of the other decorators will be re-executed through each loop even if they are above “Loop” in the node.
If you want to make sure that some conditional happens only once and THEN a loop occurs, you’ll need the conditional to be on a higher parent node in the tree. The same goes for any conditionals which you do NOT want to force success on.
We intend to improve the UI of our Behavior Trees to show these types of decorators separately and put them in separate lists. However, there’s currently nothing stopping users from making nodes that behave in both ways, in which case the two parts of execution occur at different times. So be wary about presuming the order!