Move to goes to the waypoint and becomes motionless. Then it fails because it thinks it didn’t reach the destination. I increased the size of the acceptable radius but it still fails. It is moving correctly but the behavior tree isn’t behaving correctly. It is acting like the move failed.
Hey @TinyTracker1!
Are you sure it’s not because you’re starting again AT the waypoint? Sometimes when there’s a fail it doesn’t necessarily mean it didn’t activate. I believe if you start within the acceptable radius, it will fail because you didn’t move. And if there’s nothing else on the BT to do, it’s going to loop that every third tick, giving you a multitude of failures, which is a good thing! Because you can use those fails to move on to the next branch of the select and choose to do that other path.
it is incrementing the waypoints. So it is going to new waypoints. But for some reason it just sits on “move to” for a very long time and then it fails…
I am assuming it is failing because of the selector going to the wait. and then starting all over again with a new waypoint. the selector is behaving more like a sequence than a selector.
So the way a selector works, is it tries each of its children left to right, until one succeeds, then restarts the tree. A sequence does each one left to right until one fails, then restarts the tree.
Try using a sequence there instead, actually. Can you do that and report back any differences? If it’s the same result we’re going to have to dig for some more info!
As requested… Sequence only.
I tinkered with the waypoints. When I lowered the waypoints under the ground it stopped failing. Is there some kind of path solving issue in regard to move to and the z axis?
Yes, there is! So the goal for a MoveTo itself is a Location (vector 3), so it has an X, Y, and Z. The AI will try to get within a certain distance of the XYZ. If it’s too low or too high to reach, it will fail. The acceptable radius is a sphere around said point.
If you weren’t doing so, you want to keep your waypoint at about hip level, or about 50 units above the walkable surface! 
Did that explain sufficiently?
That doesn’t make much sense. I had to put it under the floor to get it respond. And when it was level with the player it didn’t matter how high I set the acceptable radius. It wouldn’t change the behavior
If I supply “move to” with a vector for the location of the waypoint it works fine. If I supply it with an actor it doesn’t work correctly.
Have you tried setting the radius to 3 and setting it above ground, then putting the AI about 10 feet away with a clear, level path?
Also, can we possibly get a screenshot of the level itself, at least this part of it? (and for good measure… move the navmesh slightly so it redraws. It’s weird but sometimes it fixes a lot of issues, I really can’t explain why.)
Здравствуйте, у меня была похожая проблема! Оказалось что прикрепленный предмет (пистолет) имел на SpawnActor, Coollision:But Always Spawn и AI распознавал Actor- прикрепленный предмет, я поставил Ignor Collision на SpawnActor и все заработало корректно! Надеюсь что помогу еще кому нибудь
The thing you’re doing with your waypoint node should instead be a service on your move to. That way each frame it tests the location to determine if it has reached the waypoint. The way you have it setup, even if you do get it running it will feel stiff and mechanical. Try to model Behavior Trees the way you think about tasks IRL. Drive to StopLight if green continue if yellow and distance < x slow to a stop. If red and distance < y brake hard.
TL:DR Look into services and decorators.
For anyone reading this and having a similar problem. I never found a solution because I stopped using the behavior tree and I built AI movement with blueprints. I felt it gave me the control I needed. Good luck.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.