I have a blueprint based behavior tree task that uses a AI Move To node to move a ai character toward the player character. I call this BTT_MoveToRange. I would like the ai character to stop some distance away and then attack. I setup a Selector with a service that is checking the range. Once the player character is in range, it sets a blackboard value to InRange=true. The Selector uses the BTT_MoveToRange task. The task has a decorator that is supposed abort once InRange=true. This all works fine and watching the BehaviorTree running, I see that once the AI is within range, it stops running my BTT_MoveToRange task and switches to my BTT_AttackNearestEnemy task.
Here’s the problem: the AI continues to move towards the player even after aborting the BTT_MoveToRange. I thought I could handle this by adding a Event Receive Abort inside my BTT_MoveToRange and calling StopMovement. But this abort event never gets called, so I can’t call StopMovement.
Is there some trick to getting your Event Receive Abort node to fire? I would hate to have to add a node to the sequence just to stop. I would want the ai to stop if anything caused it to abort the BTT_MoveToRange.
In the move to range task, after the event tick and before the gate, make a check for that boolean in the blackboard. And if you are in range call Finish Execute.
That should short circuit move based on inrange, but it doesn’t handle any other abort reason. I’m mostly interested in how Event Receive Abort is supposed to be used. It does not appear to fire when the InRange Blackboard Decorator abort criteria are reached. If there was some even higher level abort outside of this immediate tree then just checking InRange wouldn’t be helpful.
Well, both. I would like to stop the pawn using the abort. Mostly I want to make sure I’m using the nodes the intended way. I’m hoping I don’t have to insert dozens of variable checks in all my tick functions to handle all the abort conditions.
This particular behavior tree I’m working on is to learn the systems.
Found the problem. It wasn’t a problem with Event Receive Abort.
In my BTT_MoveToRange, I was handling the OnFail pin from AIMoveTo. If this happened, I was calling FinishExecute with Success==false. It just so happens AIMoveTo will fail for many reasons, not all of them catastraphic, namely the Skipped result. On some EventReceiveTick events, it would pump my AIMoveTo node, and fail with Skipped. This would call FinishExecute with Success=false, and remove the node from relevancy. This would then end the BT selector node called Range. Then BTT_AttackNearestEnemy would activate. So, the reason Event Receive Abort never fired was because FinishExecute was called before it had a chance. The fix was to not call FinishExecute unless it was a real failure other than Skipped.
Lesson: If your EventReceiveAbort isn’t firing, it’s because you’re calling FinishExecute.
