This track (for the first game, The New Order) works out the binary layout of its skinned-character mesh format (.md6mesh/baseModel), including the long-standing puzzle of how many meshes a model file actually contains versus a header field that doesn't reliably say so. The resulting reader decodes 96% of all 755 skinned models in the game byte-exact to the literal end of file, with a clean negative control and, this pass, a second, independently-written decoder that reproduces the same results from scratch. This pass's main job was fixing one mistaken claim from earlier passes (a header field was wrongly said to always equal 1; it doesn't, in under 7% of files) and extending several findings to the full corpus instead of a handful of samples. None of this is runtime-tested since it's pure binary-format research with nothing yet wired into the project's asset viewer.
The mesh-count puzzle, solved
A model file carries two different "mesh count"-looking fields; only one of them is actually reliable. Field B, located by a constraint-propagation scan (not read directly from any single header position), is the true mesh count on 755/755 files, including both known counter-examples where a naive reading would get it wrong (one file with 7 meshes, one with 3) — now independently reproduced by a second decoder sharing no code with the first. Field A (a separate count appearing after a joint-remap table) is not reliably the mesh count and, contrary to an earlier claim carried across two prior passes without ever actually being checked corpus-wide, is not always 1 either — it differs from 1 on 51 of 755 files (6.8%), concentrated on multi-piece player/creature models (hands, wounded characters, a mechanical creature) and destructible multi-part props. It most likely represents a pre-export "meshes before splitting" count rather than the runtime mesh count.
Per-mesh layout
Each mesh's preamble carries explicit vertex-count/triangle-count fields. Two smaller per-mesh flag fields were checked corpus-wide for the first time this pass: one is 1 on 99.6% of meshes, with its only exceptions on destructible/mechanical props (not hair, correcting an earlier guess); a second is 1 on 99.5% of meshes, with its exceptions exclusively on foliage/bush props. A whole-file trailer (materials list) decodes cleanly for every file that reaches it. One 12-byte range inside each vertex is the strongest remaining candidate for a per-vertex joint-weight index — corpus-wide, it is the lowest-entropy of three candidate byte ranges on 99.7% of meshes with enough vertices to test meaningfully, with the handful of exceptions being plausible non-skinned special cases (a rigid propeller, an instrument dial, a flat billboard sprite) rather than counter-evidence. This remains an inference, not a proof — no skeleton joint ID table was actually cross-checked against it, because the skeleton file's own binary joint hierarchy is still undecoded.
Coverage and reliability
- 725 of 755 (96.0%) skinned models decode byte-exact to the literal end of the file.
- The remaining ~4% (mostly character/hair/destructible models with extra trailer content) have a known, bounded location but undecoded content.
- A corpus-wide negative control (random 1–4 byte file mutations, 600 mutated samples across 5 random seeds) produced zero false accepts.
What's needed to use this
Wiring the reader into the project's model viewer would cover 96% of skinned models with roughly half a day to a day of integration work and no further format research. Decoding the remaining ~4% and the skeleton's own joint hierarchy (needed to turn the joint-weight inference above into a proven fact) is separate, open work.
In-game test
Not needed for this pass — pure offline format research, nothing changed that touches a running game. Once the reader is wired into the project's viewer: open a simple prop model (e.g. a compass or combat knife) and check visually that shape and texture look plausible — a one-step visual check, no game launch required.