Sometimes AI does not move, AIMoveTo ends with "Aborted"

I have a strange problem and I believe it has to be a bug but I am not completely sure so I don’t put it in the Bug Reports section.

http://puu.sh/gGVBF/7de6849f71.png

The yellow guy on the bottom of the image is trying to move to the building on top of the image. I am using the AI MoveTo Node in a custom Task in my Behaviour Tree.

If I place another one of the building then one of the green guys turn into a yellow guy and also starts moving to his own building, and the strange thing is, mostly it works. So it’s depending on the location of the building or on the location of the AI, but as you see in the screenshot the yellow guy clearly has no obstacle between him and the building. I would say in 70% of the cases it does work and the other 30% not. So if I would place more buildings then out of the 6 guys standing around 4 would correctly move while 2 would just standing around and do nothing (and failing with “Aborted”.

The AI MoveTo is very simply set up, I just get the actor location of the building and move to it with an acceptance radius of 150.

Since I use the AI MoveTo Node I can actually print what was the problem after a Fail, and it seems it’s just always aborting. I can’t find any information about what exactly the different Fail states of the AI MoveTo nodes mean, could anyone help me with this?

Since I heard there is a fix regarding navigation in the Github 4.7.4 branch I compiled it from source and tried it out, but unfortunately my problem still occurs.
One strange thing I noticed is that “IsNavigationBeingBuilt” is actually all the time false, even if there is nothing changing in the map.

The cause of the issue seems to be the mesh of building. If I disable “CanEverAffectNavigation” on the Mesh, the AI moves correctly. If I add another mesh (just a cube) with same dimensions as the other mesh and the cube affects navigation, it also works.
It’s strange, I never had problem with specific meshes and as you see on the screenshot the navmesh around the mesh is generated without any problems. This has to be a strange bug where navigation stuff does not work if a mesh has some special whatever. Should I attach the building actor so you can check this out?

For now, go ahead and attach a copy of the mesh in question so that I can take a look at it. If you post some information about how the AI MoveTo is triggered and how the values are fed into it, that may help as well. Once I have that I will test it out and see what I can find, then get back to you.

Thanks!

Download
The AI Move To is called with an acceptance radius of 300 and the target is the actor location. The AI Move to is called every tick.

Hi

Thanks for the asset. I was able to test it and see the AI navigate to the mesh correctly (that is to say, they navigate to the side of it where the origin is), but it is a very simple setup that I am using. To clarify my test, I am using a BT that runs into a task for ai movement:

That is the task. I have the object set by default to the building actor that contains only the mesh component.

Does this look similar to what you are using? I was not sure about the actor cast I was doing to get the location. That was just a guess. How are you passing the location to the BB/BT Task? Also, can I see the part of the BT that uses the custom movement?

I noticed that the size of the mesh was very different however. What do you have it scaled to in your project?

Thanks!

This is the Transform of the Mesh inside of the Actor:

http://puu.sh/gMF0j/1bbf23951f.png

I should have mentioned that I don’t directly move to the actors location but actually get a random point in the radius around that mesh with the radius being my acceptance radius multiplied by 0.9 .
My MoveTo Task is actually a bit complex since I do Error detection and only fail after 3 times the “fail” of the AI MoveTo Node was executed, and only if the fail statement was not “Skipped”. Then I wait .2 seconds and try it again. It looks like this:

http://puu.sh/gMFiJ/0dec5a5319.png

http://puu.sh/gMFGz/c1259e6c99.png

“Destination” is the target Actor. “DoErrorCheck” is true. Acceptance Radius is 300.
And the origin of my actor is in the X/Y middle of the mesh!

I wonder, in your setup you connect the upper exec output pin of MoveTo directly to the success FinishExecute. Isn’t the upper exec pin always called, even if it has not succeeded? I think you should only return success if the success output pin of AIMoveTo is executed.

Thanks a lot for your help!

I see now, thank you very much for that information. I was able to reproduce it where the FAIL condition prints constantly as the AI walks toward the destination. I was able to fix it by using an AI Execution event instead of the AI Tick.

The reason is that the “Success” condition is only met when the target is reached. I was seeing the constant fail, but the second it reached the point a success was given. This is correct for how the node works.

Based on the Task that you’ve posted and what it does, I would suggest having everything run on Execution. The gate is for if you need to interrupt movement I take it? This would be best done without said gate in the task, but instead have a decorator that aborts Self at the condition that normally closes the gate (just a simple blackboard decorator with a bool “Is Set” check should do it).

One example of something similar to this can be found in this thread:

This has an AI that basically says “Go to a point until you are interrupted”. Not sure if that is exactly what you are going for, but I thought it may help.

Let me know if this helps you and if making those changes fixes the problem. If not, I am happy to further assist.

Thanks for trying it out!

I think you missed that I actually check whether the fail is “Skipped” since skipped it not a real fail, but just a “AI is already moving, so I don’t have to do it again”. The problem is, my AI does not start moving and does not fail with “Skipped” but only with “Aborted”.

You said you fixed the constant “Skipped” fails with doing the AI MoveTo in the Execute and not in the Tick, but this is not my problem. My AI does not move to the mesh (if CanAffectNavigation on the Mesh is true, otherwise it works and with every other mesh it works no matter whether CanAffectNavigation is true or false).

The gate is for being able to stop execution of moving after I have get a fail different to “Skipped” for 3 times and the delay of 0.2 seconds is executed. This is because if the navmesh get’s updated on the location where the AI is the AIMoveTo fails, so I wait 0.2 seconds in the hope that the navmesh updating is finished, then I open the gate again and the AI tries to move again. But this is not important here since my navmesh does not get updated.

, please further assist :wink:

Sorry about the wait, I got sick yesterday and left early, but I’ve been thinking about your response and I have some debugging ideas.

Can you try changing out the “On Fail” execution to instead go into a “Switch on Enum” for the “Movement Result”, then have it print? What the other result besides “Skipped” is being returned? Is it always “Aborted”? Finally, if you do a “Watch this value” for the return of “Get Random Point in Radius”, does it have any correlating results for the Aborts?

Does it happen to any BT that uses this particular node? If not what does this part of the failing behavior tree look like?

I have a couple of questions just to clarify how things are functioning as well. If you don’t close the gate after a few failures, but instead continue attempting the movement, does it continue being stuck? If you unhook the Nav Data does that change anything?

I was saying to try the other technique because calling AIMoveTo on tick is not something I would recommend, as it is not performant by comparison to only calling it when it needs to be updated and putting it on tick makes it frame dependent as well. Just a suggestion for making it easier on the hardware.

Let me know if those suggestions help to debug the issue. I’ll keep investigating what I can on my end.

Sorry there hasn’t been a follow-up to this recently. I haven’t heard back in a while and wanted to keep you updated.

Unfortunately, I was unable to reproduce this with the help of AI team members, but we are all fairly sure it’s related to the movement issue here as well: AI sometimes always "skipping" // Unclear what different Fail States from "AI MoveTo" Node mean - AI - Epic Developer Community Forums.

I’ve even had come over and try his hand when he came into town from . It’s honestly left us scratching our heads. We’d like to see a copy of the project if you are comfortable with sharing that.

Again, terribly sorry I wasn’t able to fix the problem thus far.

Hi !

First I really want to say thanks for your help, you are incredibly helpful, you really dig into the problems, also in the forums, it’s just really really nice to work with you on stuff like this, you are awesome! :slight_smile:

I have not thought a lot more about this bug because I have it basically fixed with turning off collision for the mesh completely and instead add another (invisible) cube mesh to the actor which has the same dimensions and let this mesh do the collision and navigation generation. This works and the AI don’t get stuck.

I have also implemented your suggestion of not calling the MoveTo every tick and generally improved my whole AI walking. So I don’t even know whether this bug would still occur in my project if I would use the mesh for collision and navigation generation.

It might be related to the other problem, where I also have not thought much about but I know it’s still happening. I just have not used AI much in the last months because, you know, there are these struct bugs in 4.7 which make my game pretty much unplayable because my AI is really struct driven and (inherited) structs in 4.7 just contain trash. So after 4.8 is out I will be able to use my AI again and then I will again have to work on letting the AI not getting stuck.

If I then still get this problem I will try to send you the project to show it to you :slight_smile:

Thank you that’s very nice :slight_smile: Please do let me know, and I are still interested in getting to the bottom of this. Glad to hear there is a work-around for now. I hope you don’t mind if I mark this and the other report as answered for now. Feel free to reopen them or start a new thread when you are available.

Good luck!

I ran into this problem; I fixed it for me by just checking when it’s failed; If it was “Aborted” to just fire the movement again and again until it’s successful.