re: confirm the cmesh<->model link via GameResourceID; world unit is oracle-blocked

Two follow-ups on yesterday's^Wthis morning's CollisionSet write-up.

1. The _cmesh <-> render-model link, which I recorded as UNTESTED because
   matching stems against .xbg object names covered 4 of 158.  The disc keeps
   only one build manifest, so that corpus was never going to answer it.  The
   right corpus is the GameResourceID field of the DefTables / GP_MAIN_GAME
   records -- 480 distinct values.  Against those, with a control that shuffles
   the characters of each stem:

       ship/mob stems prefixed by a real resource id   108/112 = 96.4%
       same stems, characters shuffled  (control)        0/112 =  0.0%
       asteroid stems prefixed (expected none)           0/46

   So a CollisionSet entry is <GameResourceID>[_<part>]_cmesh.  The 0/46 on
   asteroids matters as much as the 108/112: a test that fired on everything
   would be the bound-check hazard again.

2. The world unit.  Sweeping every pak for a name carrying a kilometre figure
   returns mapmesh_box_500km.col/.rgn and nothing else -- 162 references, all to
   that one pair.  The reading rests on a single filename with no corroborating
   instance anywhere in the data, so no static test can settle it; marking it
   blocked on the oracle rather than leaving it as an open static question.

   My objection's premise did survive: rou_e010 is a real GameResourceID and
   e010_ADAN_Attacker_S is in the stage tables, so the 133-unit mesh does belong
   to a craft the game calls an attacker.  Whether the trailing _S means "small"
   is a further guess (there are _EX4 / _HF / _HF_Wayne variants), so it stays
   suggestive rather than evidence.
This commit is contained in:
Sylpheed RE agent
2026-08-26 09:41:46 +00:00
parent cc1f9e6734
commit 83d019515f
4 changed files with 130 additions and 10 deletions

View File

@@ -437,8 +437,15 @@ search cannot find a *schedule*.
proxies (`_bdy`/`_brg`/`_eng`/`_wep`/`_sld`) plus 46 stage asteroids.
⚠️ **This downgraded the "1 unit = 1 m" claim to 🟡** — it implies a craft the
tables call *small* is 133 m and the largest object 447 km (89 % of the arena).
🟡 The `_cmesh`↔render-model name link is **untested, not confirmed**: only one
`.xbg` build manifest survives, so the check covers 4/158.
✅ **The `_cmesh`↔model link is now CONFIRMED** (upgraded from 🟡 the same day):
the right corpus was the **`GameResourceID`** field, not the `.xbg` manifests —
**108/112** ship/mob stems are prefixed by one of the 480 resource ids, against
a **0/112** shuffled-character control, and correctly **0/46** on asteroids. A
`CollisionSet` entry is `<GameResourceID>[_<part>]_cmesh`.
🔴 **The world unit is BLOCKED on the oracle.** Sweeping every pak for a
km-bearing name returns `mapmesh_box_500km` and **nothing else** (162 refs, all
that one pair) — the convention has no second instance, so no static test can
settle it. Needs a measured in-game traversal against the flight model.
`tools/re-capture/collisionset.py verify|list|obj`
([`data/collisionset.txt`](data/collisionset.txt)).
❔ Still open: no material/surface-type field exists in the record, and the