I encountered a really unexpected behavior when using Behavior Trees. Decorators that are connected to the first node (directly below root) do not work. More specifically the decorators are simply bypassed as if they were not there.
Reproduction:
Create a new BT
Connect a selector or sequence
Add a decorator (e.g. a custom decorator that always returns false)
Add a task to sequence (e.g. wait)
Tell an AIController to run the BT
The task will always run
If this is an intended behavior I would love it if someone could explain it to me since I didnât find it anywhere in the documentation
Iâm a little confused as to what you are attempting to accomplish. Can you show me a screenshot of your behavior tree and explain your end goal? Perhaps I can see what is occurring.
As I understand it, the âRootâ node is essentially a dummy node for editing purposes, and the node you attach below it will be the real root of your tree at runtime. As such, it wouldnât make sense to attach a decorator to it, since preventing it from running would just result in the tree immediately starting again from the root (i.e. the same place).
Still, if this is the case, it would seem to be an oversight to allow decorators to be attached and not give any warning.
As you can see the example task i being performed even though the decorator is set to block execution. Normally, if this node was placed anywhere else, the would not run. This created a great deal of confusion for me as a first time user. Now that i look at it again i see that the decorator is set to -1. It is however easily missed, which I can attest to :).
explained the reasoning below and the problem is easily solved by adding a sequence or selector in between. However, It would be great if there was some mention of this is the documentation. Or even better, there could be a warning when a decorator was placed the first node (more than the -1 in execution order).
Iâm only suggesting this so that other users donât run into the same problem.
You could argue that it makes sense for the main tree, but the bug still occurs in subtrees, and there failing at the root is very meaningful - it returns control to the parent tree in the correct spot.
I have to say, this behavior doesnât make much sense to me. I want the decorator to fail (and go back to root node) but it seems that the only way to get around it is to introduce a âblankâ node between Root and Real Root.