In my behaviour tree for my AI, there is a task “GoToWaypoint”, in which the node “AI MoveTo” node is used to move the character to their next waypoint, created by the player earlier in gameplay. This works 95% of the time perfectly, on exactly the same set of waypoints, (Paths can be saved and loaded) but sometimes they will get to their waypoint, finish any tasks they need to do there and upon GoToWaypoint being called to progress to the next waypoint the AI MoveTo node will fail, and the Movement Result enum will return “Aborted”. The waypoint is within the navmesh (the AI will move there with no problem most of the time!) and I can’t find any change between when it fails and when it succeeds. I’m also very unclear on what can cause it to return “aborted”, it’s apparantly not being blocked, so are the possible things that can cause it? Thanks for any help on this, you can see the GoToWaypoint here:
Aborts usually occur as a result of obstructed geometry. What constitutes obstructed geometry can sometimes be surprising.
I had this problem on a project where it appeared everything was working okay, but the level’s geometry had been imported as a single static mesh. Its collision was automatically set to one solid collider hull built around the whole level. Funnily, this does not prevent a nav mesh from being generated inside of it, and so everthing can look perfectly okay even though all the actors are living inside solid collision. By getting rid of this collider completely, we successfully enabled AI to navigate the level.
That’s what I’d advise looking at first – in your viewport, click “Show” and then check “Collision” to see how that actually looks as compared to the expected layout of objects in your scene.
I think you’re right about it being collision based. I’ve managed to fix it by increasing the acceptance radius to 50. It’s inherently difficult to re-produce so I can’t say for certain it’s fixed but I’ll say it’s solved for now since I haven’t been able to re-create it since making the change
‘Aborted’ also happens if you set your max acceleration or max walk speed to zero in your movement component. Maybe you got an algorithm that changes the acceleration for some reasons? I had this case.
For those stumbling upon this post and the proposed solutions fail: in your Project Settings, check the “Engine - Navigation System” section.
I added a Supported Agent here, following instructions for a different issue. Probably did something wrong.
After removing the Supported Agent and cleaning up the DefaultEngine.ini (removed the [/Script/NavigationSystem.NavigationSystemV1] section), the AIMoveTo started to behave nicely again.
I solved it by selecting the Floor actor, and setting to true: Fill Collision Underneath for Navmesh
Maybe If I had used a Plane instead for the floor I wouldn’t have had this problem.
That solution really helped me a lot!
Had same problem - for now, if the result is aborted, I’m changing movement mode from walking to flying. Later on my AI switches to walking again in some certain events, and for now it seems that it fixes the issue.
For me the target actor was just BARELY off the ground even though it was in the nav mesh bounds volume. Fixed it by placing my target actor a little into the ground, and it fixed it so far.
Man. you are genius. It’s really so funny “fix”. I used it too. Thank you!
i got the same error. and i had to solve the problem by adding Floating Pawn movement to my Pawn.
Same here. Needed to add FloatingPawnMovement to my pawn.
Also check your Navigationvolume (press P when selected), the ground should turn green.
for Preferred Nav Data, I selected Recast Nav Mesh.
Had a similar issue and resolved it by adding a simple collision to the static floor meshes, without a mesh collision the NavMesh isn’t working.
In my case, I created a large level mesh modeled in Blender and imported into into Unreal Engine, with collision set to Use Complex as Simple. I dislike using the Landscape toolset because it doesn’t do caves, overhangs, or arches very well.
Anyway, for the life of me I couldn’t understand why AI MoveTo always aborted, but it had to do with just that– the imported level mesh. The navmesh seemed to be casting perfectly, but it wasn’t allowing characters to move on it. BY FREAK ACCIDENT I found the solution by checking a single checkbox: “Fill Collision Underneath for Navmesh” under Navigation in your NavMesh details.
Very hard-to-find solution for something that LOOKS like it’s operating properly, being covered in friendly green NavMesh despite not functioning, so kudos to me, but this is a solution for those using static meshes (or in my case, one LARGE static mesh) as level collision.