Why does my behavior tree stops firing?

I’m trying to set up a simple BT logic:

-when the enemy doesn’t know or doesn’t remember the player (set by the RememberPlayer bool), it should move to a random location.

-if the enemy has seen the player, so he does remember it, do something else.

however when the enemy spots the player and sets rememberplayer to true, it just stops the BT.

what am I doing wrong?

Hey @fael097!

Should be as simple as this:

So in a BT, everything flows left to right, then down when it finds an applicable path.
What you have is “Do this, then do this”, but in a sequence, if part A fails, it returns to root and part B never fires, whereas in a selector, the return only happens if ALL options fail, but it will prioritize left to right. Just keep in mind, in a selector, it chooses the FIRST thing that works and moves down, it does NOT do all things attached to it, only the FIRST thing, whereas a sequence does ALL things but drops back to root on ANY failure. :slight_smile:

2 Likes

Oh! now I see it haha, thanks.

So let me go ahead and ask you, could you tell me what exactly the “observer aborts” do? this is confusing me a lot. specially the “self” and “both” part.

So Decorators run while the execution path runs through it based on change in the condition. These aborts tell when the condition should still be checked.

Self: Only checks when the BT flow hits it, and is passing through it.
Example: Flow MUST be going through the decorator, change happens, it restarts the BT from root.

Lower priority: Checks when anything lower in priority (to the right) is running, but not when the flow is passing through itself.
Example: Flow Must be going through a LOWER PRIORITY branch (to the right), NOT itself or ANYTHING to the left. Value changes, BT restarts from root.

“Both” checks everything lower priority AND itself- no options allow checking conditions during higher priority task flows, for that you would need another decorator in an earlier spot, as it has not yet been called upon in the logic.

1 Like

Ah! It makes a lot of sense now. Thanks for the simple explanation, I just couldn’t wrap it around my head.

So when a decoration aborts, it aborts that node back to its parent, right? I think that’s the main thing that was confusing me, I thought it would abort its own execution and move to the next node to the right, but that would be completion, not abort. Is that right?

Hey again @fael097, happy to help and glad you’re getting it! But no, when a decorator aborts, it doesn’t go to its parent.

It starts the whole behavior tree over from the very top, that’s an important distinction because it could be affected by earlier variables in a larger tree. But if all other variables are the same, it goes so fast when observing the BT during play that it COULD look like it goes to the parent.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.