Editor support for creating and assigning NavigationMaps to NavRegion, NavLink, and NavAgent

[Ghostalireza]

Describe the project you are working on

I am working on a project that involves multiple types of agents with different sizes and navigation behaviors.

Describe the problem or limitation you are having in your project

Currently, NavigationMaps can only be created and assigned through code. By default, navigation nodes (NavRegion, NavLink, and NavAgent) connect to the default NavigationMap unless they are explicitly reassigned at runtime.

In a project with multiple agent types, this becomes problematic. For example, if I want three different NavigationMaps for three enemy sizes, I must manage the assignment manually.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The proposed enhancement is to allow NavigationMaps to be created and managed directly in the project setting, and to provide an editor property for NavRegion, NavLink, and NavAgent that lets the user select which NavigationMap they should connect to by default.

This would:

• Streamline the workflow by letting developers set up maps visually in the editor instead of only through code.
• Remove the need for complex runtime workarounds to reassign NavigationMaps.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It is possible to implement a workaround with code, but it is not clean. For example, I created a singleton MapManager that holds three maps for three enemy sizes, along with custom inherited navigation nodes that expose an agent_size enum property. These nodes request the correct map from the MapManager and call set_navigation_map().

However, this approach requires waiting for one or two physics frames before assigning the map, otherwise the assignment is overwritten by the default map initialization. It also clutters the editor view, especially when multiple NavRegions and NavLinks overlap.

Is there a reason why this should be core and not an add-on in the asset library?

This functionality addresses a fundamental workflow in Godot’s navigation system. NavigationMaps are already part of the engine core, and providing editor-level support for managing and assigning them aligns with how Godot handles other fundamental systems (such as physics layers or animation trees). Implementing this as an add-on would not integrate as seamlessly as a built-in solution.

[smix8]

In general this multi agent navmesh juggling is handled with proposal #12707 that streamlines this to a single access point for queries that does this agent handling internally. Creating agent types globally in project settings would be an option for that.

The inspector property gui is extremely limited and has a lot of sync issues. It is not the right place to do any of the more complex things that requires staying in sync between project, world, globals and servers.

For the current way of handling multiple maps the most likely path would be do add a NavigationMap node and emulate a lot of the old Godot 3 behavior with nodes searching there parents first for assignment. That had a lot of issues of their own which is why it was removed with Godot 4, but it had arguably an easier workflow for multi-map assignments. It also would add a lot of unnecessary code complexity due to all the node quirks involved (re-parent events suck).

However, this approach requires waiting for one or two physics frames before assigning the map, otherwise the assignment is overwritten by the default map initialization.

This isn't really the case, the default map assignment happens for all navigation objects (regions, agents, obstacles, links) on the internal engine enter tree notification (or in case of agent post enter tree, because it depends on the parent node being ready). The script notifications happen all after that so whatever map change is done there will override whatever default was set before. The only thing that "delays" is that all these map changes are in the sync queue until the actual NavigationServer sync is done but the order in which those map change commands are execute are the same.