fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

47
docs/re/structures/collisionset.md
View File

@@ -67,10 +67,30 @@ weapon and shield — the same sub-part vocabulary as the `XBG7` render models,
these are per-part collision proxies. The asteroid meshes carry exactly the
stage prefixes that have an `_AsteroidVolume_wp` `MCOL`.
🟡 The name correspondence to the render models is **not demonstrated**. Only one
`XBG2` build manifest survives on the disc (`machines\rou_e104\…`), so matching
`_cmesh` stems against `.xbg` object names covers 4 of 158 — no coverage, and
therefore no evidence either way. It is not a refutation; it is an untested claim.
### ✅ The names *are* the game's own resource ids (upgraded from 🟡 the same day)
The previous write-up recorded this link as **untested**, because matching
`_cmesh` stems against `.xbg` object names covered only 4 of 158 — the disc keeps
just one build manifest (`machines\rou_e104\…`), so that test had no power in
either direction.
The right corpus is not the manifests, it is the **`GameResourceID` field** of
the `DefTables` / `GP_MAIN_GAME` records — 480 distinct values, e.g.
`GameResourceID = 'rou_e010'`. Against those, with a control that shuffles the
characters of each stem:
| | |
|---|---|
| ship / mob stems prefixed by a real `GameResourceID` | **108 / 112 = 96.4 %** (55 exact) |
| same stems, characters shuffled (control) | **0 / 112 = 0.0 %** |
| asteroid stems prefixed (expected none — they are not resources) | **0 / 46** |
So a `CollisionSet` entry is `<GameResourceID>[_<part>]_cmesh`: the collision
proxy for one part of one game resource. The four unmatched stems are
`rou_e303_wep`, `rou_f301_body`, `rou_f302`, `rou_f303_body`.
The 0 / 46 on asteroids is worth keeping: a test that fires on everything would
be the bound-check hazard again. It separates the two families correctly.
## 🟡 The world unit — the metre reading does not survive this file
@@ -95,9 +115,22 @@ game's units really are metres and its ships are kilometre-scale, or `500km` in
that filename names something other than the box's span. The 500 000 arithmetic
stands; the *interpretation* does not have independent support.
An independent scale reference — the flight model's speed values against a
measured traversal time in the running game — would settle it, and has not been
run.
**And there is no second instance of the convention to check against.** Sweeping
every `.pak` on the disc for a name carrying a kilometre figure returns
`mapmesh_box_500km.col` / `.rgn` and nothing else — 162 references, all to that
one pair. So the reading rests on a single filename, with no corroborating
example anywhere in the data. That is not a refutation; it is the absence of any
static way to settle it.
My objection's own premise did survive its check: `rou_e010` is a real
`GameResourceID`, and `e010_ADAN_Attacker_S` appears 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` and
`_HF_Wayne` variants of the same unit — so it is suggestive, not evidence.)
🔴 **Blocked on the oracle.** An independent scale reference — the flight model's
speed values against a measured traversal time in the running game — is the only
route left, and it needs an emulator run rather than the disc.
Reproduce with `tools/re-capture/collisionset.py verify` / `list`
([`../data/collisionset.txt`](../data/collisionset.txt)); `collisionset.py obj`