x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

AI sometimes always "skipping" // Unclear what different Fail States from "AI MoveTo" Node mean

http://puu.sh/gMBm1/c980e8e9fe.png

These nice brown/grey guys don't want to move sometimes. The "AI MoveTo" Node is called every tick and it generally often fails with "Skipped" even if the AI is moving fine, but then sometimes it always fails with "skipped" while the AI does NOT move. I can't find any information about what the different fail states mean. Sometimes I get "Aborted" Errors (other answerhub post) and also don't know why exactly the AI MoveTo failed.

This are actually two posts in one, one question about the fail states and a bug report that the AIs just stop moving. The bug report is more important.

Mieszko, please explain :)

Product Version: Not Selected
Tags:
more ▼

asked Mar 23 '15 at 09:08 PM in Bug Reports

avatar image

John Alcatraz
1.2k 57 136 125

avatar image Ben Halliday STAFF Mar 23 '15 at 10:35 PM

Hi John,

We're moving this to Using UE4, as the first question isn't a bug, and the bug you mention is being addressed here:

https://answers.unrealengine.com/questions/196151/sometimes-ai-does-not-move-aimoveto-ends-with-abor.html

avatar image John Alcatraz Mar 23 '15 at 10:49 PM

Nope, it's a completely different bug not related to the other one in any way (completely different AI, errors and reproduction steps), that's why I moved it back to the bug reports section :)

avatar image John Alcatraz Mar 26 '15 at 12:09 AM

The other issue is actually way less important, but for this one here I would really like to see a fix in 4.7.4 :)

(comments are locked)
10|2000 characters needed characters left

1 answer: sort voted first

Hi John,

The EPathFollowingResult states are defined in the 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
     };
 }

The "Skipped" Failure is caused by retriggering the AI MoveTo, interrupting the 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 the location that is given is the same, it counts as skipped.

"Aborted" means that it was forced to stop for a reason besides "Blocked", "OffPath" or "Invalid". The AI was interrupted and stopped instead of being given a new location to move to.

I am also requesting this information be added to the tooltip. I hope that helps you with debugging the movement.

Let me know if you need further assistance. I am also continuing investigating the other post you made about aborted movement.

Cheers!

more ▼

answered Mar 26 '15 at 02:11 PM

avatar image John Alcatraz Mar 26 '15 at 11:40 PM

Thanks a lot Alex, your detailed answers are incredibly helpful! I wish everyone of the Epic stuff would be willing to help with the same energy as you do :)

I followed your suggestion and updated all of my AIMoveTo Nodes to be execution from the Receive Execute AI Event and not the Tick. Now I actually don't get spammed with skipped fails. The real problem seems to be that the AI is blocked.

You have to know, this problem occurs only "rarely" (mostly after 20-30 successful attempts to move away from the building), but if it occurs then the AI will just stand and idle around forever which is really bad (it breaks the whole game).

The question actually is, why is it blocked. You see a screenshot in the main post of this thread, and here is another screenshot:

http://puu.sh/gQYLO/88e80b26f2.png

There actually two AIs been stuck at the exact same position, but of course in different times (just random). So the AI is next to the building, then get's the order with AIMoveTo to move to it's own building (this is a baker, so it's building is the bakery). It start's moving, and then stop at this position. Then it's playing the idle animation forever and every attempt to move is failing with "blocked". Since the target location never changes and there were 20-30 successfull movements to the target before, the issue has to be the start location (the building you see in the screenshots).

avatar image John Alcatraz Mar 26 '15 at 11:41 PM

The building actually does not have any path colliding geometry since it is a dynamic obstacle, which you see here:

alt text

The building on the left has path colliding geometry, the building on the right (where the AIs get stuck) has not. So, what is "blocking" the AI? If it would run against some collision, the AI would just run against it and not fail with blocked, so this can't be the cause of the problem, since it's not even start moving. What exactly does "blocked" mean? The most probably thing I could imagine is "Could not calculate path to the target because something is blocking the way". But what is blocking the way? Since there were 20-30 successull movements from almost the same start location to the exact same target location there is clearly nothing blocking.

The only possible thing I can imagine is that the AI somehow moves too far out of the navmesh, since you see on both screenshots that the AI is standing exactly on the edge. Then it's outside of the navmesh and can't move since all path's are blocked. And this would be a bug, right? ;)

avatar image Alexander Paschall ♦♦ EPIC Mar 27 '15 at 03:27 PM

The "Blocked" result is caused by something that is not being "seen" by the navmesh impeding the AI from reaching its goal. For instance, a mesh that does not have path colliding geometry. In this case it is caused by the building not having path colliding geometry.

While looking into this, I was able to find a bug with the navmesh not updating properly when the "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 the NavMesh with a bugged "hole" that AI does not path around correctly (causing the "Blocked" error). When I set it back to true, the AI never get stuck and path correctly again. However, the entire time, the NavMesh rendered the hole as if it was actually affecting the NavMesh. I can even move the mesh after it is unchecked and the hole will remain in the same place, causing navigation issues. I have reported this to Mieszko and will make sure it is given high priority. (UE-12906)

I believe this is what is happening to your project in this and the other bug report, but can you confirm that?

In either case, the building will need that property set to "true" or else it will block AI movement without allowing them to path correctly.

avatar image John Alcatraz Mar 27 '15 at 04:42 PM

If something is not "seen" by the navmesh, as far as I know the 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, the AI starts moving, reaches the wall and just continues running against the wall and never really fails.

I wonder why you think my building is not affecting the navmesh? "Can Ever Affect Navigation" is true on the buildings "NavCube". That's why you see on the picture that it is affecting the navmesh. The only special thing is, I have added a seperate invisible cube mesh (which I call NavCube) to the building actor which does affect navigation, while the real mesh does not affect navigation. This is just for me being able to control how big the affected navigation area around that building is. I actually did this because I hoped being able to fix the problem with increasing the area around the building where no navmesh is created. But it has not helped.

I just set the "NavCube" mesh to be a "DynamicObstacle", this means that there is no navmesh created on top of the mesh. And that's why I think there is no path colliding geometry, if the engine know it will never draw a navmesh on top of something, this "something" does not have to exist as a mesh.

So this can't really be the cause for the issue.

avatar image Alexander Paschall ♦♦ EPIC Mar 27 '15 at 06:16 PM

I wonder why you think my building is not affecting the navmesh?

My misunderstanding, I thought "Can Ever Affect Navigation" was what you meant by "The building on the left has path colliding geometry, the building on the right (where the AIs get stuck) has not." I did not know that meant you were using a DynamicObject enabled static mesh underneath the original mesh. I have changed my tests to reflect this.

If something is not "seen" by the navmesh, as far as I know the 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, the AI starts moving, reaches the wall and just continues running against the wall and never really fails.

That should return "Blocked" after a certain amount of time without moving (unless it is grinding across the 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. The bots run into the wall of buildings that are not affecting the navmesh, then they get stuck and return "Blocked" while idling in place. Which is the expected behavior.

For clarity, I want to show you how my test is set up:

alt text

EDIT: The left half of the bots path correctly, the 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 the test.

It may be a better idea to have you give me the exact building blueprint that you are using where this occurs, as the mesh alone is not causing the error. That way there is less guess work on my side of testing and I can easily put the object into a report as well. Make sure to migrate it out with everything it references as well to be safe.

navmeshtest.jpg (116.1 kB)
avatar image John Alcatraz Mar 27 '15 at 06:34 PM

Ok, I never tried this without having the AI slowly grinding in any direction, mostly the AI is actually grinding to left or right.

I think you should not use the mesh which I sent you for the other problem. The mesh seems to have some own issue which is causing the aborted issue we are talking about in the other thread. This is a problem I have never experienced with any other mesh, including the building we talk about in this thread.

If I hit "migrate" on the 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 the NavCube a dynamic obstancle, it looks like this:

alt text

So, why do you think is the AI getting blocked? I still think it's somehow moving out of the navmesh and then can't continue moving... Wouldn't this be possible?

avatar image John Alcatraz Mar 27 '15 at 11:12 PM

Ok, I took a video for you so you know what exactly I mean...

https://www.youtube.com/watch?v=gOGhCzx9y4M

You have to know, the guy on the right actually does not move because there is no flour left in the storehouse, and he needs to get flour. But the guy on the 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.

avatar image Alexander Paschall ♦♦ EPIC Mar 30 '15 at 10:22 PM

Hey John,

Thanks for that video, it really clears up what exactly you are seeing out of your AI. I'm altering the test I've made with an AI that tries to move between two locations and also uses the Get Random Point node. I'll get back to you on this soon once I've had a chance to run through the tests, but I wanted to keep you updated in the meantime.

avatar image Alexander Paschall ♦♦ EPIC Apr 01 '15 at 10:15 PM

Hi John,

It does appear that the character is getting off the navmesh slightly when it gets close to the building based on the 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 the Nav Agent Radius to something like 120 (or more). This will cause the AI to not get so close to the edge of the navmesh when considering the navmesh's bounds.

To reset the AI after it gets stuck use a Time Limit decorator and force moving. Replace the "Move To Extended" with a Selector. Under that selector, put the "Move to Extended" with a "Time Limit" decorator , then to the right of that put a task that will "reset" the location. The "reset location" node can be a "Move Directly To" node targeting a vector away from the collision, since it should not use the NavMesh foe movement.

I'm still testing this and talking with Mieszko 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 the behavior. It would help me understand exactly why it stops at that point.

avatar image John Alcatraz Apr 09 '15 at 03:25 AM

Thanks a lot Alexander!

I have tried setting the Agent Radius from 42 to 120, but it does not help. I actually don't even know why it was 42 since the 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 the AI after it get stuck, I don't think that's practicable. The AI does not know in which direction the thing is which causes the "collision". The AI knows the building where it goes, but it may walk around 30 other buildings on the way to its target building and could get stuck on all of the 30 buildings, so I can't just take a vector away from the building. I could get a random point in radius around the 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 the 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 the case it's stuck I more probably would get a random point in a small radius and just "teleport" the 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 the AI is stuck. Such visible error handling gives the player the feeling that something doesn't run smooth ;)

avatar image Alexander Paschall ♦♦ EPIC Apr 10 '15 at 11:14 PM

I have tried setting the Agent Radius from 42 to 120, but it does not help. I actually don't even know why it was 42 since the 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 the Agent Radius in the RecastNavMesh for it to take effect. I hope that helps!

The default being -1 is a bit odd and I'll look into it. It should automatically set itself to the the same size as whatever the Capsule Radius is set to though.

I am afraid that was the 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 the building, however I haven't gotten them stuck in this way. So, what I'd like to suggest is if you could share the 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 the Fortnite AI team to assist in debugging this next week.

avatar image funkish Aug 04 '16 at 09:33 PM

Have you debug this issue? =) One year pass and problem same. Could you help me?

avatar image Sean L ♦♦ STAFF Aug 05 '16 at 05:58 PM

If you are still experiencing this issue, due to the age of this post, please open a new thread in the Bug Reports section of Answerhub and we'll take a look at your specific issue. Thanks!

(comments are locked)
10|2000 characters needed characters left
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question