Event Receive Abort AI backs to the same task

Hey, i got a problem with Event Receive Abort AI. When i add this event to my behaviour tree (even without doing anything next, null event) my whole tree gets stupid and freeze in that state even if I try to add changing state in Event Receive Abort AI. Its like it calling itself again. Is it bug or i dont understand proper use of it?

1 Like


We’ve recently made a switch to a new bug reporting method using a more structured form. Please visit the link below for more details and report the issue using the new Bug Submission Form. Feel free to continue to use this thread for community discussion around the issue.



Had this same issue, try to add a finish execute at the end of your receive abort.
It seems that by adding the receive abort event, you override its normal fonctionnality which is to finish execute, so if you don’t add it yourself it will never finish the task

1 Like

FINALLY! I have been having so much trouble with my higher priority tasks not being able to abort that one.

It was all because I was missing the “Finish Abort” after the Event Receive Abort AI!


This is so bad :tired_face:. Glad I worked it out, but I lost about a day and a half to this and was about to completely give up on Behavior Trees altogether.

Since omitting this FinishAbort call completely breaks behavior trees (what’s more, in totally unpredictable and opaque ways) this easy-to-make user mistake really should be checked for, either at task compile time, or at runtime. I’d like to jump in the source and propose a check/fix, but I really can spend any more time on this right now!!!