re: name-resolve all 40 MiscBin entries, and demonstrate the REGN<->MCOL pairing

The names live outside MiscBin: they are the MapPath / MapMesh /
CollisionMeshes field values of the per-stage StageResource object (IDXD schema
3c9ae32e, in every GP_MAIN_GAME_<lang>.pak), and each hashes with the ordinary
pak name_hash straight to a TOC entry.  40/40 resolve, no collisions -- the 11
REGN as <stem>.rgn, the 11 MCOL as <stem>.col, and the 18 remaining blobs as
CollisionSet_S01..S16 / _Tutorial / _test.bin.  The .pe string table at 651540
was the way in: MapMesh and MapPath sit adjacent there.

This upgrades the pairing claim.  The first section of mcol-collision.md could
only say REGN and MCOL had matching *distributions* of bbox and cell size, and
flagged that as not an object-to-object link.  A phase record names one .rgn and
one .col, and all 11/11 pairs share a stem and agree exactly on both.

The names also check the format work from outside it: mapmesh_box_500km.col is
the object decoded here as 8 vertices and 12 triangles spanning exactly
+-250000, and its name says that cube is 500 km across -- so one world unit is
one metre, and a wrong stride could not have produced a box that measures what
its own filename claims.  70 of the 87 phases use it: most stages' only
collision is the arena wall, and _AsteroidVolume_ names the rest.

Still open: the 18 CollisionSet_*.bin are named but not decoded (all exactly
1675148 bytes), and CMapColliderBridge in the RTTI names the runtime consumer
without following it into the code.
This commit is contained in:
Sylpheed RE agent
2026-08-26 09:21:00 +00:00
parent c0a7033295
commit fa5a51ac78
3 changed files with 206 additions and 0 deletions

Binary file not shown.

View File

@@ -486,3 +486,69 @@ any object out as a Wavefront OBJ.
belongs to — and the object-to-object pairing with `REGN` that the header
distributions only hint at — is still unknown. And the runtime consumer has not
been found, the same gap `REGN` has.
## ✅✅ All 40 `MiscBin` entries are name-resolved, and the `REGN`↔`MCOL` pairing is now demonstrated
**2026-08-26.** The names are not in `MiscBin`. They are the values of three
fields of the per-stage `StageResource` object (IDXD schema `3c9ae32e`, present
in every `dat/GP_MAIN_GAME_<lang>.pak`), and each hashes with the ordinary pak
`name_hash` straight to a TOC entry:
Phase_1 MapPath = 'S14_p1_AsteroidVolume_wp.rgn' → REGN
MapMesh = 'S14_p1_AsteroidVolume_wp.col' → MCOL
CollisionMeshes = 'CollisionSet_S14.bin'
**40 / 40 entries resolved, with no hash collisions** — the 11 `REGN`, the 11
`MCOL`, and the 18 remaining 1 675 148-byte entries, which are the
`CollisionSet_S01…S16.bin`, `CollisionSet_Tutorial.bin` and
`CollisionSet_test.bin` blobs. Nothing in the archive is unaccounted for.
The route in was the `.pe`: `MapMesh` and `MapPath` sit adjacent in the string
table at file offset 651 540, next to `CollisionMeshes` and `3DSetup.tbl`.
### The pairing, upgraded from "matching distributions" to an object-level link
The first section of this page could only say that `MCOL` and `REGN` had the
*same distribution* of bounding boxes and cell sizes, and flagged that this was
not a demonstrated object-to-object pairing. It is now: a phase record names one
`.rgn` and one `.col`, and for all **11 / 11** pairs the two share a stem and
agree exactly on bounding box and cell size.
| stem | phases | verts / tris |
|---|---|---|
| `test` | 3 | 34 / 60 |
| `mapmesh_box_500km` | 70 | 8 / 12 |
| `S01_AsteroidVolume_wp` | 3 | 111 / 218 |
| `S04_AsteroidVolume_wp` | 2 | 405 / 790 |
| `S05_AsteroidVolume_wp` | 2 | 89 / 174 |
| `S08_p1_AsteroidVolume_wp` | 1 | 134 / 260 |
| `S08_p2_AsteroidVolume_wp` | 1 | 8 / 12 |
| `S13_AsteroidVolume_wp` | 1 | 73 / 134 |
| `S14_p1_AsteroidVolume_wp` | 1 | 502 / 924 |
| `S14_p2_AsteroidVolume_wp` | 1 | 632 / 1 164 |
| `S28_p1_AsteroidVolume_wp` | 1 | 554 / 1 020 |
`_AsteroidVolume_` also says what the meshes *are*: the asteroid fields, which
is why the collision hull is a closed manifold and why most stages need none —
**70 of the 87 phases use `mapmesh_box_500km`**, the bare arena wall.
### The name confirms the decode, and gives the world unit
`mapmesh_box_500km.col` is the object this page decoded as **8 vertices and 12
triangles spanning exactly ±250 000** — a cube. Its name says that cube is
**500 km** across, and the decoded span is **500 000.0** units exactly, so
> **one world unit is one metre.**
This is a name-based inference, but the arithmetic is exact and it runs the
other way as a check on the format work: a wrong stride or index width could not
have produced a box whose measured size matches its own filename.
Reproduce with `tools/re-capture/miscbin_names.py <extract root> [--pairs]`
(recorded in [`../data/miscbin-names.txt`](../data/miscbin-names.txt)).
❔ Still open: the 18 `CollisionSet_*.bin` objects (magic `0x00000810`, and all
**exactly 1 675 148 bytes**, which is odd for per-stage data) are named but not
decoded. And the runtime consumer now has a name — the `.pe` RTTI carries
`CMapColliderBridge` and `CSingleton<CMapColliderBridge>` at offset 9 044 264 —
but has not been followed into the code.