How I can modify navmesh settings to get grid like movement? I know that pathfinding is based on array of coordinates, so I think if I can increase gap between them it will give grid like movement. The question is however if it possible to do it using blueprints without modifying C++ code?
Umm… don’t know how that can be done if it’s possible but you can just make your own grids and have your own movement algorithm instead of using pathfinding, and make your characters move to another grid once they reach the grid that’s gonna be the turning point.
yes, I’m aware of this possibility but I would be glad to use node like Move To without need to code anything. And building pathfinding system on top of another doesn’t seems to me good thing that’s why I’m asking, cos’ I’m actually doing exactly that right now))
I think there’s a misunderstanding. You would also use the Move To node (or any type of it) in the approach I described as well. You can just untick that checkbox to use pathfinding inside the node to disable that, but you won’t need to since you’re gonna calculate the path yourself anyway so it can stay. What you’d wanna do is moving your characters to the grid that’s gonna be the turning point, and once it’s reached, calling the same function to move your characters to a new target which will be the next turning point. The only thing you’d need to add is that algorithm to calculate the path in your grid terrain. Here’s an article that you might wanna check out for that:
Hope this helps! 
Maybe I’m mistaken but I can use Move To (also move to actor or location) only if I have a Navigation Volume , right?
Yes, you would need to keep your Nav Mesh. You’re just gonna move your characters to the targeted grids that are inside the navigation bounds.
Yes, this is exactly my point. To make AI character move using these nodes UE actually using A-pathfinding, this is a reason for putting Navigation Volume there. I certainly may be totally wrong, but it seems like making another A-pathfinding tool on top isn’t a good idea.
But for sure that it’s huge possibility that UE pathfinding is so complicated, because it is used mostly to emulate real world moving, that it can’t be simplified to basic pathfing.
…
We’re not overriding any pathfinding algorithms. We’re just executing our own in this approach.
Look, you can also achieve that sharp turns without using grids, but that won’t work if there are obstacles in your terrain.
So you actually need to define grids for your characters to be able to reach to their destination. (If you want that to happen on a single try, that is)
You can’t achieve that sharp turns that we usually see on characters moving on grid terrains while the accurate pathfinding is on, because it’s path is smooth. And I don’t think you can make it sharp because you would need to define grids for that, how else are you gonna determine when to turn another way?
There are couple way of doing this using native pathfinding.
One is straight forward which is to make smallest volumes putting in grid like order and to make links between them. I don’t have a UE video for this but this one from Unity if it allowed to post it here https://youtu.be/HqjsQlWIMkg
Sorry for that. I think I can essemble the same in UE. And thank you for reminding me about it.
Second is to reduce size of A-Path grid cells. UP: I suddenly realize that navigation mesh is generated that based on cell size, that’s why it’s so strange sometimes. And then mesh is used to getting coordinates, not a grid. Grid is used only to find closest coordinates of a path. That’s why it can’t be possibly change the way I want it. But there are possibility to get coordinates of grid cells (or path points) using Navigation Path Object. I can possibly use these one to use with Move To. Thank you, and sorry for bothering you, it clears my head a bit.
What you’re describing is exactly what the approach I explained would produce. Like I said, grids would be required for that, and by using our own path finding algorithm, we can make the characters move accordingly. Maybe you can try implementing it, it would be easier than adjusting the existing path finding algorithm in my opinion.
In this case, grids are already not used as volumes but coordinates that are separated from each other. We’re taking the center point into account.
I’m not sure if it will produce the result you want, but I wonder what happens when you adjust the cell size of the Nav Mesh by navigating to the outliner window, selecting the Recast Nav Mesh, and from the details window, and setting the cell size to a really big value. I’m not on my PC right now so I can’t test it myself. Though I doubt it will result in the way you want.
Okay just tested it, nuh uh that won’t do.
1 Like
This kind of setup is possible as simple approach.
1 Like
Are those Nav Links? That seems like a great way to overcome this issue manually! I see some small issues (which is fine if you’re ok with them) but I’m glad that you were able to figure it out! 
I don’t get it. I’ve added this one node to the template:
Bam, grid movement on navmesh with pathfinding.
1 Like
I think OP’s objective was to implement a 4 way movement system to the characters by restricting diagonal movements
What the navmesh for then since we need to ignore pathfinding it produces? If you need to move via nodes, then you need a very different method than a navmesh.
I originally suggested OP to use the A* Search algorithm but it wasn’t desired I guess
1 Like
I must admit that:
Is rather clever, though. Not sure how reliable it is. @evgeni_doudar_1 do give us an update once you get it running somewhat close to what you need.
1 Like
Yeah, I’ll try to build an enemy movement using this, let’s see if I can do it.
1 Like
yes, these are small nav volumes and links between them. I need to find a way to not set them up manually, that’s true))
You can try implementing the approach that I explained. As grids, you can manually place actors that are just collision volumes or dynamically create a vector type array that stores the center locations of each grid.