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.
- 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.
Thanks, that explains it. It’s not completely intuitive though… It would be great if it gave an error / warning.
Thank you for your reply. The example i presented was only supposed to show my problem in the simplest possible manner. Here is a picture:
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.
Again thank you for your time.
3 hours until I find this, trying all kind of things, god, answerhub is such a mess. Thanks .
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.
The solution you’ve proposed works, thanks .
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.