Navigation2D is deprecated in Godot 3.x. Need to use Navigation2DServer.map_get_path() instead

[StraToN]

Describe the bug
Escoria makes big use of Navigation2D node to perform character path calculations. However, Navigation2D is deprecated in current stable version of Godot so we need to move to Navigation2DServer.map_get_path instead as advised in Navigation2D

If I'm not wrong this causes a warning in the editor's debugger.

To Reproduce
N/A

Expected behavior
After fix, the behaviour should be identical to current, but shouldn't use Navigation2D system anymore.

Screenshots
N/A

Versions

• Escoria: develop branch
• Godot: 3.4 stable

Additional context
N/A

[BHSDuncan]

I believe this is related to godotengine/godot#65257 (comment) somewhat, as we had to do a bit of hacking already. We should probably wait for the updated/improved/fixed Navigation2DServer to be finished/backported from 4.0 before we start removing Navigation2D. It's definitely something that's been on my mind for some time now.

[smix8]

It is safe to remove all Navigation2D and Navigation nodes from a project and use Navigation2DServer.map_get_path() instead. The only thing to note is that the old pathfinding was done relative to the node while the new NavigationServer pathfinding expects global positions and returns paths with global positions so if the old Navigation2D was not always kept at world origin this needs to be adjusted.

In current Godot 3.5+ Navigation2D node (and Navigation) acts as dummy node that routes the get_simple_path() function to the newer NavigationServer.map_get_path() function. The only thing unique to Navigation2D rightnow is that it creates a new navigation map for all the navigation related child nodes. If Navigation2D is removed from the scene all navigation related nodes will register on the World/World2D default navigation map instead. Since most games are absolutely fine with just the default navigation map removing the Navigation2D changes nothing for them.

[BHSDuncan]

It is safe to remove all Navigation2D and Navigation nodes from a project and use Navigation2DServer.map_get_path() instead. The only thing to note is that the old pathfinding was done relative to the node while the new NavigationServer pathfinding expects global positions and returns paths with global positions so if the old Navigation2D was not always kept at world origin this needs to be adjusted.

In current Godot 3.5+ Navigation2D node (and Navigation) acts as dummy node that routes the get_simple_path() function to the newer NavigationServer.map_get_path() function. The only thing unique to Navigation2D rightnow is that it creates a new navigation map for all the navigation related child nodes. If Navigation2D is removed from the scene all navigation related nodes will register on the World/World2D default navigation map instead. Since most games are absolutely fine with just the default navigation map removing the Navigation2D changes nothing for them.

Right, but what about Godot issue 65257 (mentioned above, which you've also commented on)? While I understand that it's "safe" to do what you said, does issue 65257 not potentially affect things?

[smix8]

We discussed this issue 65257 among navigation devs that is why I came here from the link.

In short, the old 3.4 behavior with artificial parameter position snapping will not come back in both Godot 3.5+ and Godot 4.x as part of the NavigationServer. If your 3.4 project relied on this behavior you will need to add a custom check with a project appropriated epsilon and snap the positions yourself.

[BHSDuncan]

Ah, ok, thank you for the update.

Then, to confirm, as in the "solution" I said we were going to use back in the original ticket, using our own is_equal_approx with an appropriate epsilon is the way to go?

[smix8]

Yes you will need your own depending on your project size / scale as default is_equal_approximate() functions epsilon might fail for you.

That is one (there where many other) reason why we can't implement this automatically or with a toggleable option in the NavigationServer. There is just no "right" epsilon for this kind of checks without knowing all the project details. It also doesn't capture how the precision of float decreases as you get farther from the origin. E.g. the old behavior had plenty of bugs after certain project sizes or polygon layouts so we can't just go back.

[BHSDuncan]

Perfectly fair and understandable. Thank you again!