This track maps out how TNC's AI navigation data works — the binary format of the baked navmesh files, whether there's any way to toggle or edit walkable area at runtime, and whether a custom map built by reusing an existing donor map's navmesh (as the project's proof-of-concept custom map already does) carries any gaps. The binary navmesh format is now fully decoded across every file in the game (not just spot-checked), and a second, previously-undocumented navigation layer was found: named regions that mission scripts can toggle open or closed at runtime without any new geometry or rebuilt mesh — a real, corpus-common authoring lever this project didn't know about before. Everything here is static format/corpus analysis; the one practical question this can't answer offline (whether enemies actually move and path correctly on the project's reused navmesh) is queued as a short in-game test at the end.
The navmesh format, fully decoded
Every .hknavmesh file in the game (55 distinct payloads) now decodes with zero failures:
u32 N -- count of named navigation regions
N × { u32 len; char[len] name } -- region names, plain ASCII
u32 size (little-endian)
u32 size (big-endian, same value repeated byte-swapped)
"TAG0" ... -- a standard Havok binary tagfile containing
the actual baked walkable mesh (faces/edges/
vertices) plus a clearance cache
An earlier tool only handled this correctly by accident, for files with zero named regions — any file with named regions needs the region-list header parsed first, which this pass adds. Some maps carry extra sibling .hknavmesh files (e.g. ..._nav_section_1); these are not a different format, just separately-loadable chunks of the same map's navmesh sharing the identical region-name list.
A second navigation layer: toggleable blocked regions
A map's region-name header is not decoration — it is exactly the set of idNavRegionEnt entities placed in that map (confirmed matching for 38 of 39 map directories checked; the one mismatch is a harmless, retail-shipped stale reference, proof the engine tolerates a name in the header with no matching entity). Each region entity has a startFlags field (e.g. NAVREGION_BLOCKED, or archetype-specific flags like NAVREGION_BLOCK_COMMANDER) and can be flipped open or closed at runtime by the mission-script node ActionModifyNavRegion — used 310 times across 216 of the 2,408 retail mission scripts, overwhelmingly in the pattern "a breakable prop takes damage → the region behind it unblocks." This is a real, corpus-proven, currently-authorable lever for editing where AI can walk without touching the baked mesh at all — reusing an existing region's own flags, not creating new walkable area.
No classic "AAS"/cover system in this game
This game's AI navigation architecture has zero of the older cover/obstacle classes (idAAS2, idCoverBlocker, etc.) that the first game in this series used — that whole system was replaced wholesale by the Havok navmesh plus scene points plus the toggleable-region layer above. This is a genuine architecture change between the two games this project covers, not just a renamed format.
What the project's reused custom map inherits
The project's proof-of-concept custom map (built by reusing an existing donor map's geometry and navmesh) never touches the navmesh file at all — it ships byte-identical to the donor map's own navmesh, and the donor map happens to have zero toggleable regions, so this second layer was never exercised by that map. The geometry reuse mostly lines up with the new layout by construction, but not entirely: one whole room has retail navmesh underneath it that is not actually connected to the player start over walkable new floor, so the enemy originally planned for that room had to be relocated to a corridor instead. Areas genuinely beyond the donor map's old walkable footprint simply have no navigation data at all (not a mismatch, an absence) — careful layout work reduced this unavoidable gap from an early draft's 163 m² down to about 3 m² in the final version.
What's achievable for custom-map navigation
| Approach | Status |
|---|---|
| Reuse a donor map's navmesh by aligning new geometry to it | Proven, implemented — the only way to get new walkable surface at all |
| Toggle an existing named region's block flags | Proven possible and corpus-common — can only affect faces the bake already has, never create new ones |
| Build a new navmesh from scratch | Not feasible — no encoder exists in the project, and the baked format needs more than just the walkable mesh (a working clearance cache too). The engine's only in-game navmesh edit is a cutter that removes surface (an obstacle hole), never adds any. |
Open questions
- Whether a genuinely new, hand-added region entity (a name not already in the navmesh's baked header) is tolerated at load time, by symmetry with the proven reverse case — not tested.
- Exact runtime meaning of the region flag strings beyond their literal names.
In-game test
Two separate, cheap checks on the already-built custom map: (1) confirm the placed enemies actually move and path normally in the reused-navmesh area; (2) only relevant for a future custom map built from a donor that does have toggleable regions — place an additional, previously-unknown region over an already-walkable area and confirm the map still loads normally and that area stays usable for AI.