Compatibility of TrinityCore .mmtile (DNAV) navmesh tiles with recast-navigation-js Detour WASM

[lovour-lab]

First of all, thanks for recast-navigation-js — it’s an impressive and very useful project.

I have a question about binary compatibility between recast-navigation-js (WASM Detour) and TrinityCore mmaps .mmtile files.

Background

I’m working with TrinityCore mmaps generated by Trinity’s official tools.
Each .mmtile file contains Detour navmesh tile data, not tilecache layers.

I verified this by parsing the files manually:

Tile data contains DT_NAVMESH_MAGIC = 'DNAV' (little-endian shows as VAND)

DT_NAVMESH_VERSION = 7

Header fields such as:

polyCount, vertCount

bmin / bmax

bvQuantFactor

This matches dtMeshHeader layout from Detour

So the .mmtile files are dtNavMesh tileData, intended for dtNavMesh::addTile().

What works

If I load a .nvmesh file exported by recast-navigation-js itself:

NavMeshImporter.importNavMesh() works

findRandomPoint, findNearestPoly, findPath all work correctly

So the WASM Detour build itself is functional.

The problem

When I try to load Trinity .mmtile tileData into recast-navigation-js:

navMesh.addTile(tileData, flags)

I consistently get:

status = DT_WRONG_MAGIC (0x80000001)
tileRef = 0

I also tried scanning offsets inside the .mmtile file and passing only the raw DNAV block (starting at the Detour header), but no offset succeeds — always DT_WRONG_MAGIC.

This suggests that:

The magic value itself (DNAV) is correct

But the WASM Detour build likely expects a different binary layout / ABI than the one used by TrinityCore

What I want to clarify

I’d like to confirm whether the following assumption is correct:

TrinityCore .mmtile files are not binary-compatible with the Detour build used by recast-navigation-js, even though they share the same DT_NAVMESH_MAGIC and DT_NAVMESH_VERSION.

Specifically, I’d like to ask:

Is the Detour version / build configuration used by recast-navigation-js expected to be ABI-compatible only with navmesh data generated by the same build?

Are there known differences (struct packing, compile flags, poly ref layout, etc.) that would cause valid Trinity .mmtile tiles to fail addTile()?

Do you consider loading external Detour tileData (e.g. TrinityCore mmaps) out of scope for this library?

If compatibility is theoretically possible, is there a documented or recommended way to adapt external tileData?

What I am not trying to do

I’m not trying to convert .mmtile into TileCache layers

I’m not assuming Trinity uses TileCache

I understand that TileCache and NavMesh tileData are different pipelines

My goal is simply to understand whether direct navmesh tile reuse across different Detour builds is feasible or intentionally unsupported.

Summary

Trinity .mmtile = valid Detour navmesh tileData (DNAV, version 7)

recast-navigation-js loads its own .nvmesh fine

Trinity tiles always fail DT_WRONG_MAGIC

Likely a Detour ABI mismatch, not a file parsing mistake

Any clarification would be extremely helpful before I decide whether to:

Move pathfinding to C++ (Trinity-side), or

Rebuild navmeshes using recast-navigation-js instead of Trinity tools

Thanks a lot for your time!

[isaac-mason]

Hello, I am not very familiar with TrinityCore. I can point you to some details about how recast-navigation-js handles the persisted format however.

The ser/des logic can be found here: https://github.com/isaac-mason/recast-navigation-js/blob/bc0440cc2396844325e388d883b9241e7a56d4d5/packages/recast-navigation-wasm/src/NavMeshSerdes.cpp

This code was lifted from the RecastDemo source at some stage: https://github.com/isaac-mason/recastnavigation/blob/599fd0f023181c0a484df2a18cf1d75a3553852e/RecastDemo/Source/Sample.cpp#L351

Because the export format is not really part of the "core" library but a snippet copied around, the compatibility between recast-navigation-js's format and others using recastnavigation is more implicit than explicit.

Any clarification would be extremely helpful before I decide whether to:

• Move pathfinding to C++ (Trinity-side), or
• Rebuild navmeshes using recast-navigation-js instead of Trinity tools

The correct decision here is probably very subjective to the rest of your technology. Let me know if I can answer any other questions to help though.

Hope this helps!