Generate a navmesh for a camp

Smithbox can build the navmesh of a Nightreign (or Elden Ring) map from the collision of the parts placed in it. There are two routes: the Navigation Editor in the Map Editor, and the MCP bridge tool nav_generate.

Not proven in game. The generated files re-read, pass Smithbox's own checks and compare well with the game's meshes, but nobody has yet watched an enemy path on one. Read Known limits first.

If you only need enemies to walk around props you added, you do not need this page. Flag the props instead. That is proven in game. See The proven alternative.

What was checked for this page: every name, parameter and default below was read from the code. Nothing was run. The in-game statements come from the team's notes, not from the code.

What a map's navigation is

• One .nva file per map. It lists the map's navmesh models.
• One .nvmhktbnd binder per map. It holds two Havok files per model: an n file (normal characters) and an o file (large characters), named <n|o><map digits>_<model>.hkx.
• One navmesh serves every variation of a map. There is no variation field in the files.

Before you start

• A Nightreign or Elden Ring project. The Navigation Editor refuses other games.
• The map must have an .nva and a navmesh binder already. Generation needs an existing navmesh file of the map as a template. A brand new map id has none, so start from a copy (step 1 of the MCP route).
• Havok loading must be on (the Map Editor setting MapEditor_SkipHavokLoad must be off), or the navmesh files cannot be read. Collision loading must be on for the in-editor route.
• Work on a copy, not on a vanilla camp. A camp's navmesh is shared by all its variations.

Route 1: in the editor

1. Load the map in the Map Editor.
2. In the Tools window, open the Navigation Editor section. If it is missing, turn it on in the Tools window's View menu: Navigation.
3. Under Map, pick the loaded map.
4. Open the Models tab and scroll to the Generate group.
5. In the viewport, select the collision parts and assets to walk on. The group shows them under Selected parts ("N collision parts and M assets selected"). Dummy assets are not used.
6. Tick Blocker on a selected part to generate around it instead of on it. Blocker tags last for the session. Every tagged part of a loaded map counts in each generation, selected or not. The Blockers list has Untag per part and Clear. Tagged parts show as red boxes while the overlay is on.
7. Pick the target:
   • As a new model
   • Replace model NNNNNN's navmesh (the model selected in the Models list)
   • Into a free placeholder, with the option Give it the collision model's ID
8. Adjust n set and o set if needed. Each has: Cell size, Agent radius, Agent height, Max climb, Max slope, Max edge length, Face size, Triangles only, Jump and fall links (then Jump height, Fall height, Link reach), and Reset.
9. Press Generate. It runs in the background ("Generating..."). The result is applied as one undo step.
10. Save the map (File > Save). The .nva and the navmesh binder go into the project folder.

The editor route has no "solid" role, no variation filter and no MinIslandArea setting. Use the MCP route for those.

Route 2: through the MCP bridge

Read mcp-bridge.md first, above all its safety rules. Check smithbox_status before you touch a running Smithbox.

1. Make a copy of the camp with its navigation:

   create_map_copy(source="m43_02_00_00", new_id="m43_02_00_90", with_navigation=True)
   

   This writes the MSB under the new id into the project folder. With with_navigation it also copies the source's .nva and .nvmhktbnd, with the files inside the binder renamed after the new map. Nothing else is copied (no collision, lights and so on). new_id must look like m43_02_00_90 and must not exist yet.

2. load_map(map_id="m43_02_00_90")

3. nav_info(map_id=...) lists the map's navmesh models: model_id, n_name_id, o_name_id, n_faces, o_faces, placeholder, n_clearance_seeded, plus nva_layout and the binder's files.

4. Try it without changing anything:

   nav_generate(map_id="m43_02_00_90", variation=2, n={"MinIslandArea": 20}, o={"MinIslandArea": 20},
                blockers=["AEG099_123"], dry_run=True)
   

5. Run it for real with dry_run=False. Add save=True to save the map straight away, or call save_map later.

6. nav_validate(map_id=...) runs the editor's validator on the result. It returns errors, warnings, by_code, the same counts for the game's own files (vanilla_by_code) and codes_not_in_vanilla. Anything in codes_not_in_vanilla is new with your edit.

nav_generate parameters

Regexes ignore case and match a part's name or its model. A part that matches several lists is a blocker first, then a solid, then walkable.

Only Asset and Collision parts with a model are read. Map collision comes from the map's high collision binder. An asset's collision comes from its own collision binder (_h, else _l).

Settings you can override in n and o (an unknown name is refused with the list of known names):

MinIslandArea drops joined pieces of the finished mesh smaller than that many square metres (prop tops, roofs, ledges). The comparison runs in the findings document used 20.

What comes back

Part counts per role, missing_collision (models with no collision found), walkable_triangles, solid_triangles, blocker_boxes, seconds, and for each set faces, edges, vertices, islands_dropped, faces_clipped_by_blockers, jump_links, fall_links. After a real run: applied, the binder files changed, validator_errors, validator_warnings, and saved_to when save was set.

How to tell it worked

• nav_generate returns applied: true and face counts above zero for n and o.
• nav_validate shows nothing in codes_not_in_vanilla.
• In the editor, the Navigation Editor's Overlay tab draws the new mesh over the map.
• Whether enemies use it in game is not proven. Test that yourself and write the result here.

What goes wrong

Known limits

From Documentation/Claude/Navmesh Generation Plan.md, section 6 (2026-11-11):

• Not tested in game. Whether enemies path on a generated mesh is open.
• A copied map keeps the source's NameIDs and map UID. A new map loaded beside its source may clash.
• No jump or fall links by default (Links is off). Most of the game's n files have them.
• No gate nodes.
• No face data flags. The game sets 0x1000000 on about 6% of n faces; generated meshes leave it unset.
• m60 open-world tiles also need NVC connector files. Smithbox does not make them.
• Coverage against the game's own meshes, with assets and collision as input and MinIslandArea 20: the camp m43_02_00_00 covered 87% of the game's n area and 80% of its o area; the church m41_01_00_00 90% and 86%. Generated meshes have more faces than the game's because of the 2 m face grid.
• A POI map's own collision is a two-triangle placeholder. The ground there comes from assets, so leave assets on.

The proven alternative: flag the blocking props

Each asset has a row in the param AssetEnvironmentGeometryParam. Its field navimeshFlag ("Pre-destruction Navmesh Flag") tells the game how the asset affects pathing. The first values of its enum ASSET_NAVIMESH_FLAG are 0 None, 1 Obstacle, 2 Impassable.

Setting this flag on the rows of blocking props was tested in game on the Boneyard variation of camp m43_02_00_00 (2026-11-11): enemies pathed around the props much better, with no navmesh edit. This is the team's note of that test; this page's writer did not repeat it.

So for a custom POI or props added to a camp:

1. Find the asset rows of the props that block the way.
2. Set navimeshFlag to Obstacle or Impassable on them, as a param edit in your stage.
3. Leave the navmesh alone.

Only generate a navmesh when the ground itself is new (a new map id with new floors).

To inspect or patch an existing navmesh file without Smithbox, the Havok2014 tool has navinfo, navcover, navunlink and navclearance. They are described in ../ports/map-tools.md.