I have a behavior tree that always gets stuck on the MoveTo node, despite reaching the destination. The Acceptance Radius is set to a huge value (500), and the pawn reaches the the goal within .01 in each dimension. What am I doing wrong?
edit: I should note that this is in 4.7 preview 8.
FWIW it does move past the MoveTo node if I attempt to path outside of the navmesh volume.
All works as expected. Here’s what’s happening:
- You request AI move to
TargetLocation - AI is moving to location
- AI reaches location
- Move task finishes with success
- BT reruns from root, looking for highest possible task to run
- Finds
Move Tonode and runs it - Since AI is already at location the task instantly returns with success
- Next frame goes to point 5
You need to add a test checking if AI is already at location.
Cheers,
–mieszko
Am I misunderstanding how sequence nodes work? I thought that they were supposed to run each of their children until one of them failed. (Most of my limited understanding of behavior trees comes from this article Behavior trees for AI: How they work)
If I add a decorator to the MoveTo node that always returns true it gets stuck on the MoveTo node, and if it always returns false the entire sequence is aborted (as I expect). If I replace the sequence with a selector, and add a decorator to the MoveTo that fails if the actor is close enough, it runs the MoveTo on the first pass through the tree, completes, and then runs the sound node on the second pass. Is there a way to do this on one pass through the tree, without the delay?
Wait! I’m wrong, you’re right! I didn’t notice it’s a Sequence 
So theoritically this should work exactly how you expect. I feel there might be a bug in how we treat node results if your root is a sequence. Yeah, that ROOT is not the real root - it’s just a dummy editor-time node so that you can indicate which BB asset to use.
Can you try making that first composite node a Selector and then make your sequence it’s child? Let me know if it still doesn’t work. If it doesn’t it may be a bug in BT move task
Sorry for the confusion!
–mieszko
No problem, thanks for being patient with me. If I modify the BT so it goes selector → sequence → (MoveTo, Sound) it still only executes the MoveTo.
Looks like a bug then. I’ll file it and have a look. If it’s serious (and sounds like it could be) I’ll try squeezing it in for 4.7.1. Thanks for reporting it!
Thanks for your help!
I gave it a go and it did work. I’ve reused someone else’s project exhibiting a bug to test it. I’m attaching it so that you can spot the differences in setup. Hope it helps! Let me know.
Could something be wrong with my navigation mesh/system/configuration? If I set the acceptable radius to 1000000000.0 it still moves the pawn to the target location and stays inside the MoveTo node.
If I add an obstacle to the middle of the navmesh, it seems to get stuck on the MoveTo only if the pawn didn’t get anywhere near the obstacle. If I move it such that it stops near the obstacle (but not so close that it can’t reach the desired position) it escapes the MoveTo node and plays a sound.
Is there a simple way to debug what’s going on inside MoveTo?
I figured it out using the visual logger:
Despite the fact that I set the target location’s Z coordinate to the Z coordinate of the actor (it’s constrained to a single plane), it seemed to think that it was about 100 units off in the Z direction each time it ran MoveTo. If I hard-code the Z destination to -94, it works fine. (Though it does seem to move the actor such that the edge lines up with the destination, not the center)
One thing to note is that we project goal locations to navmesh before calculating paths - maybe that’s what you’re seeing as a Z offset.
Do you need more assistance with this? If so, can you supply us with a stripped-down version of your project? Or at least share your navigation system’s configuration (like your ini files for example). Project would help more of course 
It would help to know what it uses for the position of the actor. It seems to me like it’s using the center-ish of the actor to calculate distance, but using the base of the actor to calculate its location in the editor. (The ~94 unit offset is almost exactly the distance between the arrow doodad in the actor to the base of the actor)
I think I fixed it:
- get the target location
- project the hit result onto the nav mesh with Project Point to Navigation
- path to that instead of the target location
I’ve got a much better understanding of how this stuff works now, thanks!
Hi Mieszko-
Post-4.7 I believe I’m seeing a slight change in behavior in path building. As you mention “we project goal locations to navmesh before calculating paths”. When I look at the pre-4.7 path, all of the path points are projected as expected. Post-4.7, all of the path points are projected except for the last one, which retains the original goal location Z.
I believe that’s why we may be seeing a variety of issues like this one and (AI actions have unneccessary delay - AI - Epic Developer Community Forums ), where move requests are failing out due to incorrect Z values.
I’m fairly confident that projecting the goal location to the navmesh before issuing the move request will solve the problem, but it’s unclear if this change in behavior is by-design or a bug.
Thanks for reporting it, I’ll look into it soon. Cheers!