Hey, thanks for looking at it. I’ve just tested it with a node size of 1, and that seems to fix it. However, in my project, I need a node size of 0.333.
So it seems to be the combination of small node size and high timescale.
Sorry I’m still reading, just haven’t responded. I don’t really have time right now to try swapping back to a FollowerEntity, but I too use a small node size (in fact, I’m on 0.05). That’s unfortunately not something I can increase as it would drastically impact our gameplay.
Our timescale is set to 1 though, but it does get worse if you increase the timescale. I recall reading somewhere in the docs that that’s probably due to the simulation having to catch up or something.
Do you two mind sharing your need for a smaller node sizes? There may be a workaround for what you’re both trying to achieve.
In our case we only use dynamically generated navmeshes, as the player is in full control of placement of pretty much everything. We don’t align furniture on a grid so we need a smaller grid size to make sure that you don’t block off to much when rotating stuff (see image for an example). We also ported over a ton of assets from the original so we were stuck with the size of things.
We used to use the Unity navmesh for this, but ran into a lot of edge cases that were pretty much impossible to solve. We specifically opted for a grid to make it easier to find and solve these type of issues.
We’ve been playtesting for a few weeks now and the AIPath is working flawlessly so far.
We have a grid based building system where one cell has the size of 1x1. If we had a larger pathfinding grid size, there would be no pathfinding collision for the whole door which causes people to walk at the edge of the door, half through the wall, but we want them to be walking in the middle of the door.
It’s not possible for us to change the size of the buildable objects, as our whole system is already based on it.
I was going to suggest the Recast Graph in this case then, but if AIPath is working for you, that’s totally fine 
For this though, I am going to suggest looking at a Recast Graph. If there’s anything preventing you from using it let definitely let me know, but I think in this case you can get a little “have your cake and eat it too” from a Recast Graph.
I unfortunately can’t use a Recast Graph, because I need tags and penalties.
You can actually get tags working with Recast Graphs-- the general idea is to use NavmeshCut with “Is Dual” set to true, which will just make a new seem rather than remove the geometry altogether. Then you apply your penalty and tags. Midway down this page is a section detailing more of this.
Is it also working to update it in runtime? I have a grid based building system where the player builds up rooms and streets in the game. Therefore I already have a script that’s updating areas of the grid graph once something was built or demolished.
Since this is working really well already, I would honestly prefer to stay with the Grid Graph. Is it planned to fix the bug with the lower node size? I’m sure that other customers will have the same issue in the future.
The Navmesh Cut solution should be fine during runtime.
I wouldn’t call it much of a bug personally but that’s a per person line to draw. My logic, is that if set your agent’s move speed to 40,000 and it doesn’t work well…that’s not much of a bug it’s moreso just outside of the design of the program.
I’d probably tell other folks the same thing though, as well. Not that anyone who has this issue is in the wrong somehow, but rather that there are ways around this already.
Alternatively, those who are down with getting their hands dirty with some code editing can modify the FollowerEntity to accomodate this edge case, or simply make a custom movement script to have their cake (Grid Graph) and eat it too (Small Grid Size).
I appreciate your perspective, but I believe the issue extends beyond being merely outside the intended design. The behavior occurs even with node sizes slightly below 1, which are common in games requiring finer navigation precision. If this behavior only manifested with extremely small node sizes, I would agree it falls outside the expected use case.
I would be grateful if you could consider investigating whether the current implementation can be adjusted to handle smaller node sizes more gracefully. Alternatively, providing clearer documentation on its limitations would be greatly appreciated. The current documentation (FollowerEntity - A* Pathfinding Project) mentions that it works well with a timescale greater than 1 but doesn’t specify any restrictions regarding node sizes below 1.
I could be 100% wrong with this too This could in fact be a bug, or something @aron_granberg may want to address in a future update. So I’ll tag him on this and we can get his perspective on it as well. Regardless, hearing other folks input on this kind of stuff is always useful so thanks for providing it.