Event with Sequence Abort

fang

New member
hi, Justin

I am running the behavior tree designer now, I have no issue with the event sending and receiving, but once it is combined with the sequence abort function, I am confused.
here I simplified the issue with the Iskeydown and sequence nodes.

the tree is set as run endless, and the sequence node set as "Both" abort type.

In tree A , once I press the key, it will log out "B" first, then log out "A", in my understanding after the tree aborted, it runs from Iskeydown node to LogB, but why there is one more logA executed after logB node? I expect the Iskeydown should only abort the sequence once, but it looks abort twice.
A.png

I tried more and found that in treeB once I press the key to abort the tree, the tree only runs LogB node to print out "B", doesn't execute logA node anymore. but it will stop at the Wait node, I tried to replace the Wait node to any other task nodes, it always stops at the second node from the IsKeydown node. I don't understand why this could happen.
B.png
I read the IsKeydown node code, it looks like the tree checks the IsKeydown condition in every update, once it is not pressed, then it will return failure. So I am guessing that when I press the key, the tree aborts and run from the sequence. but in the next update, the Iskeydown condition is failure already, which aborts the sequence node to run over again.

how to make the event trigger node just acts like a normal event in code which only run once when it is triggered?

thanks.
 
Last edited:

Justin

Administrator
Staff member
IsKeyDown is being reevaluated because of your Both conditional abort. If you only want that to be reevaluated once you can change the Both abort time to just Lower Priority.
 

fang

New member
IsKeyDown is being reevaluated because of your Both conditional abort. If you only want that to be reevaluated once you can change the Both abort time to just Lower Priority.
thanks for the reply, I think I tried the Lower priority before

firstly, In TreeA, I believe I analyzed wrongly, the logA always run after logB because the tree runs repeatedly and LogA is always the first node in the new round, my fault.

In Tree B, the reason I set it to both because I assume the event will trigger a long time node like Wait for several second, 。. after the first event triggers them, these actions should play one by one, and meanwhile when the second trigger comes these action nodes can be interrupted and triggered to run over again, more like get hurt, interrupted and replay.

now if I set the sequencer abort as a lower priority, once these actions nodes are triggered, they will not stop until play to the end of the sequence, which means no response for the new trigger coming. it more like death or fall down action immune for the second attack.
 
Last edited:

fang

New member
I guess it is hard to solve it under the sequence node, I tried to replace it with the selector node and set abort as Both, it looks fine, the only issue is that the child sequence will always run automatically once at the beginning.

C.png
 

Justin

Administrator
Staff member
Instead of conditional aborts I recommend using the interrupt/perform interruption tasks. Take a look at the RTS sample project for an example, but this will allow you to have more control over when a task is interrupted.
 

fang

New member
Instead of conditional aborts I recommend using the interrupt/perform interruption tasks. Take a look at the RTS sample project for an example, but this will allow you to have more control over when a task is interrupted.
ok,thanks a lot ~
 

fang

New member
Instead of conditional aborts I recommend using the interrupt/perform interruption tasks. Take a look at the RTS sample project for an example, but this will allow you to have more control over when a task is interrupted.
hi, Justin, I just explored the RTS project and other sample projects. I found that the interrupt/perform method more like a polling method, and it only can interrupt to stop the sequence. not like the way I wish to trigger new round and stop the old round

If I stick back to the abort function, just wondering if possible to make the tree abort function depends on event firing but not the event node state change? which also can make the node connection clean and easier to understand.
 

Justin

Administrator
Staff member
Conditional aborts work by interrupting the task when the OnUpdate status changes. There isn't a separate condition that is checked to determine when the abort should trigger.

You may be able to create a new task that checks for the key being down and caches the result when it is true. When the task is reevaulated by conditional aborts it can then return this cached result. You can later reset the cached result with a different task within the tree.
 

fang

New member
Conditional aborts work by interrupting the task when the OnUpdate status changes. There isn't a separate condition that is checked to determine when the abort should trigger.

You may be able to create a new task that checks for the key being down and caches the result when it is true. When the task is reevaulated by conditional aborts it can then return this cached result. You can later reset the cached result with a different task within the tree.
ok, understood, thanks for the reply.
yes, in these days I am also thinking to customize a condition task to convert the event detection as a boolean state to trigger the abort function properly if no anyother default methods, I will try this first, thanks for the help,
 
Top