Behave Plugin : Behavior Tree Perpetually "Running" actions Prempting problem

Question

I am using the Behave Plugin to make behavior trees for my game

So, I have a behavior tree that looks like this : http://imagebin.org/278510

The Actions marked in Red are basically Perpetually Running actions once reached, they make my guard perpetually rotate in 360 degree circles or 180 degree scans.

This works as expected and everything is fine, however, when a higher priority subtree is introduced things get hairy, So, suppose my higher priority subtree chases the player when he is seen, the guard chases the player eventually loses him, now, I want the patrolSubtree to be completely Re-evaluated (i.e. starting from goToWayPoint) , it will however , come to the patrolSubtree sequence and see that a chain leading to doScanFull is "Running" and will start to rotate the guard "in place" wherever it was when it lost the player.

I believe there should be some way to resolve this, as even in the case of non "Perpetually" running actions, this may cause unexpected behavior when a "Running" action is interrupted by a higher part of the tree.

Can anyone suggest a way to do this ?

I think there should be a way to reset the entire subtree at whim, so that all "Running" actions are cleared, or is there some better way ?

Furthermore, What if I dont want my Top level Selector to be affected by the "Running" state on any Action ? i.e. I want that selector to check every possibility underneath it to see which one to run , that way , if the guard is doing a HalfScan and he sees the player , the "Chase Subtree" will actually evaluate. If the Top level Selector was affected by the Running state of stuff under it though, then the higher priority actions may never evaluate because some stuff was in the "Running" state.

Thanks a lot, Nik

Answer 1

So, it seems I figured out a solution to this problem, I had to go through many many texts to figure this out. So, here goes, the solution is basically to use 'Interrupts'.

Interrupts are basically decorators that have check for preconditions every AI frame when control goes through them, so if a low priority action has an interrupt on the way to it, the interrupt will be evaluated every time the low priority action is actually executed.

So, the interrupt basically checks for preconditions that would mean that a higher priority subtree must be evaluated, if these preconditions are ever true, then the interrupt breaks out of the current subtree and forces a re-evaluation on the entire tree, which would result in higher level actions being executed, since the top level selector would actually go to higher priority actions.

The attached image will probably explain the solution much better than any wall of text.

http://imagebin.org/280408