These nice brown/grey guys don’t want to move sometimes. “AI MoveTo” Node is called every tick and it generally often fails with “Skipped” even if AI is moving fine, but then sometimes it always fails with “skipped” while AI does NOT move. I can’t find any information about what different fail states mean. Sometimes I get “Aborted” Errors (other answerhub post) and also don’t know why exactly AI MoveTo failed.
This are actually two posts in one, one question about fail states and a bug report that AIs just stop moving. bug report is more important.
Nope, it’s a completely different bug not related to other one in any way (completely different AI, errors and reproduction steps), that’s why I moved it back to bug reports section
EPathFollowingResult states are defined in code as such:
UENUM(BlueprintType)
namespace EPathFollowingResult
{
enum Type
{
Success, // reached destination
Blocked, // movement was blocked
OffPath, // agent is not on path
Aborted, // aborted and stopped (failure)
Skipped, // aborted and replaced with new request
Invalid, // request was invalid
};
}
“Skipped” Failure is caused by retriggering AI MoveTo, interrupting current movement. It basically means “I was going to point A, but skipped it because I was told to go to point B” Even if location that is given is same, it counts as skipped.
“Aborted” means that it was forced to stop for a reason besides “Blocked”, “OffPath” or “Invalid”. AI was interrupted and stopped instead of being given a new location to move to.
I am also requesting this information be added to tooltip. I hope that helps you with debugging movement.
Let me know if you need further assistance. I am also continuing investigating other post you made about aborted movement.
Thanks a lot , your detailed answers are incredibly helpful! I wish of Epic stuff would be willing to help with same energy as you do
I followed your suggestion and updated all of my AIMoveTo Nodes to be execution from Receive Execute AI Event and not Tick. Now I actually don’t get spammed with skipped fails. real problem seems to be that AI is blocked.
You have to know, this problem occurs only “rarely” (mostly after 20-30 successful attempts to move away from building), but if it occurs then AI will just stand and idle around forever which is really bad (it breaks whole game).
question actually is, why is it blocked. You see a screenshot in post of this thread, and here is another screenshot:
There actually two AIs been stuck at exact same position, but of course in different times (just random). So AI is next to building, then get’s order with AIMoveTo to move to it’s own building (this is a baker, so it’s building is bakery). It start’s moving, and then stop at this position. Then it’s playing idle animation forever and every attempt to move is failing with “blocked”. Since target location never changes and there were 20-30 successfull movements to target before, issue has to be start location ( building you see in screenshots).
building on left has path colliding geometry, building on right (where AIs get stuck) has not. So, what is “blocking” AI? If it would run against some collision, AI would just run against it and not fail with blocked, so this can’t be cause of problem, since it’s not even start moving.
What exactly does “blocked” mean? most probably thing I could imagine is “Could not calculate path to target because something is blocking way”. But what is blocking way? Since there were 20-30 successull movements from almost same start location to exact same target location there is clearly nothing blocking.
only possible thing I can imagine is that AI somehow moves too far out of navmesh, since you see on both screenshots that AI is standing exactly on edge. Then it’s outside of navmesh and can’t move since all path’s are blocked. And this would be a bug, right?
“Blocked” result is caused by something that is not being “seen” by navmesh impeding AI from reaching its goal. For instance, a mesh that does not have path colliding geometry. In this case it is caused by building not having path colliding geometry.
While looking into this, I was able to find a bug with navmesh not updating properly when “Can Ever Affect Navigation” property is altered.
What I found was that if I place a mesh with “Can Ever Affect Navigation” set to true, then set it to false, it will leave NavMesh with a bugged “hole” that AI does not path around correctly (causing “Blocked” error). When I set it back to true, AI never get stuck and path correctly again. However, entire time, NavMesh rendered hole as if it was actually affecting NavMesh. I can even move mesh after it is unchecked and hole will remain in same place, causing navigation issues. I have reported this to and will make sure it is given high priority. (UE-12906)
I believe this is what is happening to your project in this and other bug report, but can you confirm that?
In either case, building will need that property set to “true” or else it will block AI movement without allowing them to path correctly.
If something is not “seen” by navmesh, as far as I know AI usually is running against it with full running animations. So if I have a start point and an end point and between there is a wall which does not affect navigation, AI starts moving, reaches wall and just continues running against wall and never really fails.
I wonder why you think my building is not affecting navmesh? “Can Ever Affect Navigation” is true on buildings “NavCube”. That’s why you see on picture that it is affecting navmesh. only special thing is, I have added a seperate invisible cube mesh (which I call NavCube) to building actor which does affect navigation, while real mesh does not affect navigation. This is just for me being able to control how big affected navigation area around that building is.
I actually did this because I hoped being able to fix problem with increasing area around building where no navmesh is created. But it has not helped.
I just set “NavCube” mesh to be a “DynamicObstacle”, this means that there is no navmesh created on top of mesh. And that’s why I think there is no path colliding geometry, if engine know it will never draw a navmesh on top of something, this “something” does not have to exist as a mesh.
I wonder why you think my building is
not affecting navmesh?
My misunderstanding, I thought “Can Ever Affect Navigation” was what you meant by " building on left has path colliding geometry, building on right (where AIs get stuck) has not." I did not know that meant you were using a DynamicObject enabled static mesh underneath original mesh. I have changed my tests to reflect this.
If something is not “seen” by
navmesh, as far as I know AI
usually is running against it with
full running animations. So if I have
a start point and an end point and
between there is a wall which does not
affect navigation, AI starts
moving, reaches wall and just
continues running against wall and
never really fails.
That should return “Blocked” after a certain amount of time without moving (unless it is grinding across wall, but still moving slowly).
Is it never returning anything after a few seconds of being stuck? I am getting “Blocked” results when I try this. bots run into wall of buildings that are not affecting navmesh, then they get stuck and return “Blocked” while idling in place. Which is expected behavior.
For clarity, I want to show you how my test is set up:
EDIT: left half of bots path correctly, right half will get stuck and return a “Blocked” failure.
Let me know if that reflects what you are experiencing or if there are any changes I should make to test.
It may be a better idea to have you give me exact building blueprint that you are using where this occurs, as mesh alone is not causing error. That way there is less guess work on my side of testing and I can easily put object into a report as well. Make sure to migrate it out with everything it references as well to be safe.
Ok, I never tried this without having AI slowly grinding in any direction, mostly AI is actually grinding to left or right.
I think you should not use mesh which I sent you for other problem. mesh seems to have some own issue which is causing aborted issue we are talking about in other thread. This is a problem I have never experienced with any other mesh, including building we talk about in this thread.
If I hit “migrate” on building it wants to migrate almost my whole project, e.g. every other building I have. But this problem here is not specific to this one building, it can happen everywhere, I just only use this one building as example because my AIs just always move to it.
if I don’t make NavCube a dynamic obstancle, it looks like this:
So, why do you think is AI getting blocked? I still think it’s somehow moving out of navmesh and then can’t continue moving… Wouldn’t this be possible?
Ok, I took a video for you so you know what exactly I mean…
You have to know, guy on right actually does not move because there is no flour left in storehouse, and he needs to get flour. But guy on left has get flour and actually stucks. It's really just random that he get stuck when there was only one flour left, mostly it happens before.
Thanks for that video, it really clears up what exactly you are seeing out of your AI. I’m altering test I’ve made with an AI that tries to move between two locations and also uses Get Random Point node. I’ll get back to you on this soon once I’ve had a to run through tests, but I wanted to keep you updated in meantime.
It does appear that character is getting off navmesh slightly when it gets close to building based on video. I wasn’t able to recreate it on my machine, but I do have some suggestions for preventing this from happening and fixing it when it does.
To help prevent this from occurring, in your AI’s Character Movement Component try increasing Nav Agent Radius to something like 120 (or more). This will cause AI to not get so close to edge of navmesh when considering navmesh’s bounds.
To reset AI after it gets stuck use a Time Limit decorator and force moving. Replace “Move To Extended” with a Selector. Under that selector, put “Move to Extended” with a “Time Limit” decorator , then to right of that put a task that will “reset” location. “reset location” node can be a “Move Directly To” node targeting a vector away from collision, since it should not use NavMesh foe movement.
I’m still testing this and talking with about what I’ve found. He’s making a lot of fixes to NavMesh due to what we’re seeing.
Let me know if those suggestions help or change behavior. It would help me understand exactly why it stops at that point.
I have tried setting Agent Radius from 42 to 120, but it does not help. I actually don’t even know why it was 42 since default value for this is -1, and I also don’t know what -1 means. But 120 does not change anything
Regarding your “hack” to reset AI after it get stuck, I don’t think that’s practicable. AI does not know in which direction thing is which causes “collision”. AI knows building where it goes, but it may walk around 30 other buildings on way to its target building and could get stuck on all of 30 buildings, so I can’t just take a vector away from building.
I could get a random point in radius around AI and let it walk to it without navmesh (Move Directly To Task) but I don’t like to have to use a whole task with decorators etc for this. I like to encapsulate such behavior all into one task (All Error handling should be inside MoveToExtended), and apart from this it could easily happen that MoveToExtended fails because there is no path to target or because of other reasons, and then nothing should happen, I would not want to call “Move Directly To” after any time.
So for case it’s stuck I more probably would get a random point in a small radius and just “teleport” AI to this location. I think this looks less strange than an AI who runs in a complete wrong direction (away from “collision”).
But I would like to have a solution which really works and not just some Error handling after AI is stuck. Such visible error handling gives player feeling that something doesn’t run smooth
I have tried setting Agent Radius
from 42 to 120, but it does not help.
I actually don’t even know why it was
42 since default value for this is
-1, and I also don’t know what -1 means. But 120 does not change
anything
That was my fault, I see I had left out a step to that. You’ll need to increase Agent Radius in RecastNavMesh for it to take effect. I hope that helps!
default being -1 is a bit odd and I’ll look into it. It should automatically set itself to same size as whatever Capsule Radius is set to though.
I am afraid that was best work-around that comes to mind at this time.
To give you an update, I have a large test with many bots running back and forth “gather” items to drop off at building, however I haven’t gotten them stuck in this way. So, what I’d like to suggest is if you could share complete AI itself (BT, custom tasks/services/decorators, AIcontroller, etc) without any other content. Then I’ll add it into a bare-bones project and start debugging what is happening until I have a repro for a bug report. We can do this privately via forum PM if you’d prefer. Sorry it came down to that, but unfortunately it seems to be an edge case.
I’m also going to sit down with one of my friends on Fortnite AI team to assist in debugging this next week.
If you are still experiencing this issue, due to age of this post, please open a new thread in Bug Reports section of Answerhub and we’ll take a look at your specific issue. Thanks!
