Add better documentation to explain the purpose of interrupts

[SavoVuksan]

This is not really a but more a question regarding interrupts. How do they work? Do they work implicity when a BT changes the Composite or do I need to call it directly in one of my leaf nodes?

I am trying to create an enemy AI with a BT. The enemy should aim at the player as soon as they are in sight. The aim action runs forever as long as the player is in-sight. As soon as they leave it should go into the waitforever action where we wait until the player gets in sight again.

I think I would need interrupts here. But I am not quite sure since I am pretty new to BT.

Does anybody have a plan if I am understanding interrupts correctly/BT?

[bitbrain]

Hey @SavoVuksan - thanks for raising this. We probably should have a dedicated section in the wiki about interrupts, as they can be confusing at first.

The general idea behind interrupts is that you may have a running action but suddenly that 'branch' will not get visited any longer, so now you end up with a 'running' action that actually does not run any longer. In case that happens, beehave will propagate 'down the tree' and interrupt everything before proceeding to the new branch.

What you need in your example is not interrupts (as interrupts are more of an internal working) but instead, you should utilise conditions

Basically like this (pseudo-code):

AimTargetSelector <-- should be selector, so only 1st condition is ever executed if true
   PlayerLostSequence
      InverterDecorator
         IsTargetInRangeAreaCondition
      WaitAction <-- this gets run each frame, so no need to wait 'forever' but just... wait
      LostEmoteAction
   PlayerFoundSequence
      ... the rest of it

The idea is that this tree gets executed every frame. In case the target is not in range, the player lost sequence will just play. It is critical here to make the parent a 'selector', as we only want to execute the 'PlayerFoundSequence' in case the 'PlayerLostSequence' fails.

[SavoVuksan]

Ok, thanks for clarifying how interrupts work. Regarding your pseudo code example. The WaitAction would be a running action as long as the condition !isTargetInRange is active. Otherwise, the emote would play all the time. Am I right?

[peterpants2]

That's helpful as I also wondered if Interrupts were more performant that using Conditions as I imagined they were signal based. It sounds similar to a sort of 'reset' track for animations. i.e. return the action to a particular state upon interruption