This should do the same thing. But with only this change, now it’s working as intended. It’s not an ideal solution though since it obfuscates what the conditional keys are.
So the question is, why is this happening? Is there something I’m not understanding or is it just an underlying bug in the BT?
Oh boy… There is not enough information here. At least for me to help you, I will need more information. Which one is low priority? Which node is the problem? And what is the exact problem?
I would strongly encourage you not to design your behaviour tree that way. It is definitely not efficient. This is the reason why you should carefully design your BT as it leads to a hard-to-debug problem. For starters, I would suggest each branch should have a maximum of 2 nodes. If you need more, you should change to an enumeration method to do the switch.
I would also avoid having more than 1 decorator on the node (only one decorator). I’ve seen a lot of startups make this mistake, which leads to chaotic and non-scalable code. And for the love of god, please rename the nodes.
What more information do you need? There are two decorators on one node, both go to “pass” (from the “fail” state), both are set to “aborts both,” and yet they don’t abort. I recreated the functionality in a custom decorator with an AND operator, and now that decorator does abort. I don’t understand there to be any difference in how the two cases operate so I’m wondering why the former case isn’t working.
It’s subjective; you will have to debug it yourself, as I have no idea how you designed your code.
It can be any of the following. As I said, your screenshots do not tell much about it.
Is the conditioned being set inside the controller class or the character class? Does the controller get a validity check? Does the condition get executed at all? Do the “setters” get a valid reference? Which nodes should be prioritised, and can the node execution be cut off during execution? If so, it needs to be handled properly to invalidate the current setters if needed. Making sure it does not affect the other data keys.
Again, the idea of designing one node to have multiple decorators, I personally think it is a bad practice. You will have a hard time debugging and scaling your code. I would make only one decorator node at most for the tree node parent.
Also, this screenshot is not ideal. Instead of getting the data from the controller>blackboard, which is double the work, you should get the data to the blackboard since BT already reference the blackboard data. If you want to get a gift from person A, you should just ask person A to give you the data. Why would you ask person C to request person A, and then ask person C to give you the gift? It’s a waste, since you already have contact with person A, so just ask person A.
