I move the AI using MoveTo (inside a behavior tree) and then assign the TargetLocation as the player location. The player then walks to the end of the ledge shown in the screenshot below. The AI sadly follows the player outside of the navmesh. And then the AI get’s stuck because, there is no navmesh where he is standing… But the AI should not ever get outside of the navmesh…
How can I prevent the AI from walking outside of the NavMesh without resorting to ‘spamming’ invisible walls?
Could it be an UE4-bug? Reproduced in other projects as well. Also applies to both SP and MP of course.
If movement mode is Walking then character can move anywhere outside navmesh. If movement mode is NavWalking then character can move only on the navmesh but can trigger navmode to Walking if it is outside navmesh.
That sadly didn’t change anything. The AI still walks outside of it. If the player jumps outside of the navmesh at the same time the AI does it’s moveto-player in the behavior-tree then he will walk outside of the navmesh even with that option enabled in it’s character-controller. And then when it arrives at it’s location outside of the navmesh it will be stuck.
In Walking mode a character should not stuck anywhere.
What a gameplay debugger output for moving and navmesh in runtime?
I’m not sure what you mean, all I know is the vislog:
There is a weird cone visible at the end when the ai get’s stuck. The vislog stops at that point.
And the editor seems to crash so now and then when using vislog…
I did find out that the NavMeshWalking DOES restrict enemies from moving to a location outside of the navmesh (when making them walk to a VECTOR-location). But when using MoveToTarget (player) they do not and they will walk outside of the navmesh and get perma-stuck. Is this a bug?
Even when the targetlocation and lastknownplayerlocation are the same, one node works (restricts to navmesh) but the other one does not. Note that TargetPlayer is typeof playercharacter and lastknownplayerlocation is a vector.
Also the vislog shows a red bar when navigating with lastknownplayerlocation when the lastknownplayerlocation is outside of the navmesh (as I would expect it to). But TargetPlayer does remain blue-ish and they move outside of the navmesh without errors/warnings.
Maybe it’s intended behavior that when moving towards another actor/character that the navmesh is ignored and that they can move outside of it?
Okay I tested it again and I replaced the TargetPlayer with TargetLocation (vector) instead and now they do restrict themselves to the navmesh.
Only question now is: intended or bug?
For Vector projection to navigation was enabled by defaults. For Actor mode this test was skipped.
// fail if projection to navigation is required but it failed
if (bCanRequestMove && MoveRequest.IsProjectingGoal())
It is not a bug.
Closing question. Short answer: use a vector for the MoveTo-node instead of an actor and it will work. Details are in comments above.
I’ve been encountering this problem as well. It seems that even converting my AI to Navmesh Walking and using move to Vectors They still sometimes get forced off the nav mesh when in groups.
If this happens they default to a movement mode of Walking (as they are designed to do) but since there is no nav mesh under them, the AI can’t path find out of the space.
Hi,
I had the same problem. But the vector solution was not quite right.
So editing some properties of the navigation mesh was able to solve it. Now the enemy does not leave the navmesh when he makes a “moveto an actor task”
So I decided to do all the solutions here, set target as vector, set to NavMesh Walking for movement, and set the Observed Paths to 0.1
so far so good, it seems to be working now.
Hi, I’m encountering this same problem right now, with the MoveToLocation task it works and the Ai doesn’t go off bounds. But the problem is that it doesn’t offer the same chasing behavior than the MoveToActor offers
This is still an issue in 2019. I found a pretty good solution to it that allows you to use MoveTo with an Actor while still preventing the AI from moving off the NavMesh and getting stuck. Basically I just created my own very simple Decorator Called BTD_CanMove where I check that the Actor the AI is trying to move to is also on the NavMesh. I then add that Decorator to my MoveTo node in the Behavior Tree.
Hope this helps!
How is it not a bug that using Vector acts different than Actor when that is neither desired or explained? I need to use Actor for moving targets and it’s a supported feature, so I’m not sure using a vector solves the issue.
Could you elaborate on that check or point me to the code? Out of context I don’t understand what that check means.
Exactly this. Using a Vector is completely different than an Actor in terms of features. One doesn’t replace the other outright. I’m having the same issue on 4.22 in 2019.
ELKatlan, check out my solution below. It’s pretty simple and allows you to use MoveTo Actor.
Yeah, not a bad workaround. I’d prefer the AI moves to the edge of the navmesh rather than stopping once their target leaves though. Not sure pathing supports that, as I think the path creation fails immediately once it can’t find a path to the target, which would fail the MoveTo.
Also curious if your solution works with deceleration. It seems like the AI would stop immediately rather than decelerate slowly if you’re using those features.
Regardless, I’d call this a bug.
Use MoveTo with an Actor is smoothing. When AI get’s stuck,i would let AI try MoveDirectlyToward to some walkable place several times.
