re: the roster's two vocabularies, and a prefix match I mistook for a hit

Correction to the previous commit's own result. The raw byte sweep reported
rot_n001 "26 times in 7 archives" - a SUBSTRING count. The exact field value
occurs zero times, in every IDXD record and every non-IDXD payload. What the
disc carries is rot_n001_break x14, LOD_Frame_rot_n001_break x7,
GameModel_rot_n001_break x5. rot_n001 exact is not on this disc. A prefix
match is not an exact match, and a byte sweep is the tool that breaks it.

rou_e202 does exist, in the other vocabulary: a Model field of a Generic
record, six times, one per GP_MAIN_GAME_<lang> pack, with no GameResourceID -
which is why the GameResourceID census called it absent.

Set arithmetic over every IDXD record: roster 40, Generic.Model 46,
GameResourceID 480; roster n Model 34, roster n GID 38, roster n both 33.
38 + 34 - 33 = 39, so 39 of 40 are one or the other and rot_n001 is the sole
exception. The six that are GID but not Model: mob_n040..043 are the four
AsteroidGroup_00N.AsteroidModelName values (asteroid models, not units) and
rou_e004 is a Level_0.Model.

What selects the 40 is still open, but two answers are dead: not the
Generic.Model set (34 of 46), not the GameResourceID set (38 of 480). The 12
Generic.Model values outside the roster include rou_f002 and rou_f004 - the
player's own craft for S7-S16/S24-27,29 and for S28 - while rou_f001 is kept,
so "the playable models" is dead too.

All fifteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 01:15:38 +00:00
parent 692a8045f0
commit 9480f0aa8a
2 changed files with 98 additions and 0 deletions

View File

@@ -5660,3 +5660,46 @@ functions outside the 60 that materialise one of the 60 global addresses — far
broad to be a consumer list. The globals sit in a dense data region, so that route
has no power; the consumer needs a different one. Also unsettled: what selects 40
of the disc's 172 `rou_*` ids, and which disc field holds `rot_n001`/`rou_e202`.
---
## 🔴✅ 2026-08-28 — the roster's two vocabularies, and a prefix match I mistook for a hit
Item (a): which disc field holds `rot_n001` / `rou_e202`.
🔴 **Correction to yesterday's own result.** The raw byte sweep reported
`rot_n001` "26 times in 7 archives". That was a **substring** count. The exact
field value occurs **zero** times, in every IDXD record and every non-IDXD
payload. Expanding the surrounding characters gives what the disc really carries:
`rot_n001_break` ×14, `LOD_Frame_rot_n001_break` ×7, `GameModel_rot_n001_break`
×5. **`rot_n001` exact is not on this disc; `rot_n001_break` is** — and it is one
of the `Generic.Model` values. The image names the stem, the disc the `_break`
variant. **A prefix match is not an exact match**, and a raw byte sweep is exactly
the tool that breaks that rule — it is a cheap *existence* test only when the
match is anchored.
**`rou_e202` does exist**, in the other vocabulary: a **`Model` field of a
`Generic` record**, six times, one per `GP_MAIN_GAME_<lang>` pack, with no
`GameResourceID`. That is why the `GameResourceID` census called it absent.
**The roster is covered by two fields.** Exact-value sets over every IDXD record:
roster 40, **`Generic.Model` 46**, `GameResourceID` 480; roster ∩ Model **34**,
roster ∩ GID **38**, roster ∩ both **33**. `38 + 34 33 = 39` — **39 of 40 are one
or the other**, the sole exception being `rot_n001`. The six that are GID but not
Model explain themselves: `mob_n040``mob_n043` are the four
**`AsteroidGroup_00N.AsteroidModelName`** values (18 each, one per pack — asteroid
models, not units) and `rou_e004` is a `Level_0.Model`.
🟡 **What selects the 40 is still open — but two candidate answers are now dead.**
Not the `Generic.Model` set (34 of 46), not the `GameResourceID` set (38 of 480).
The 12 `Generic.Model` values outside the roster are `mob_n050`, `rob_e005`,
`rot_n001_break`, `rou_e001`, `rou_e002`, `rou_e016`, `rou_e017`, `rou_e018`,
**`rou_f002`, `rou_f004`**, an empty string, and a Shift-JIS `文字列` placeholder
(the `_Test` pattern). **`rou_f002` and `rou_f004` are the player's own craft** for
S7S16 + S2427,29 and for S28, and the roster omits both while keeping
`rou_f001` — so "the playable or most-used models" is dead too.
[[unit-substructure-records]] mentions `Generic.Model` in passing as "the mesh the
corpus already decodes"; what it does not say is that there are only **46
distinct** values disc-wide. `AsteroidGroup_00N` / `AsteroidModelName` are new to
the corpus. Written up in `docs/re/structures/player-tuning-tables.md`.

View File

@@ -489,3 +489,58 @@ exactly one per `GP_MAIN_GAME_<lang>` pack, with none in `DefTables`. Controls o
the same sweep: `rou_e201` 151 / 8 archives, `rou_e901` 917 / 8, `mob_n500` 46 / 8.
So neither is an image-only name; **`rou_e202` is simply the rarest member of the
roster**, carried once per language pack. 🟡 Which field holds them is not settled.
## 🔴✅ The roster's two vocabularies — and a prefix match I mistook for a hit (2026-08-28)
🔴 **Correction first.** Last iteration's raw byte sweep reported `rot_n001` "26
times in 7 archives". That was a **substring** count. Matching the *exact* field
value gives **zero**, in every IDXD record and every non-IDXD payload. Expanding
the surrounding characters shows what the disc actually carries:
```
rot_n001_break x14
LOD_Frame_rot_n001_break x7
GameModel_rot_n001_break x5
```
**`rot_n001` exact does not exist on this disc; `rot_n001_break` does**, and it is
itself one of the `Generic.Model` values. The image names the stem, the disc names
the `_break` variant. **A prefix match is not an exact match** — the corpus's own
rule, and the byte sweep is exactly the tool that breaks it.
**`rou_e202` does exist**, in the *other* vocabulary: it is a **`Model` field of
a `Generic` record**, six times — one per `GP_MAIN_GAME_<lang>` pack — and it has
no `GameResourceID`. That is why the `GameResourceID` census called it absent.
**The roster is covered by two disjointly-populated fields.** Exact-value sets
across every IDXD record on the disc:
| set | size |
|---|---:|
| the compiled roster | 40 |
| `Generic.Model` values | **46** |
| `GameResourceID` values | 480 |
| roster ∩ `Generic.Model` | 34 |
| roster ∩ `GameResourceID` | 38 |
| roster ∩ **both** | 33 |
`38 + 34 33 = 39`**39 of the 40 are one or the other**, and the single
uncovered name is `rot_n001`, for the reason above. The six roster names that are
`GameResourceID` but not `Generic.Model` explain themselves:
`mob_n040``mob_n043` are the four **`AsteroidGroup_00N.AsteroidModelName`**
values (18 each, one per pack — asteroid models, not units), and `rou_e004` is a
`Level_0.Model`, not a `Generic` one.
🟡 **What selects the 40 is still open, and two candidate answers are now dead.**
It is not the `Generic.Model` set (34 of 46) and not the `GameResourceID` set
(38 of 480). The 12 `Generic.Model` values *outside* the roster are `mob_n050`,
`rob_e005`, `rot_n001_break`, `rou_e001`, `rou_e002`, `rou_e016`, `rou_e017`,
`rou_e018`, **`rou_f002`, `rou_f004`**, an empty string, and a Shift-JIS literal
`文字列` ("character string" — a template placeholder, the `_Test` pattern again).
**`rou_f002` and `rou_f004` are the player's own craft** for S7S16 + S2427,29 and
for S28 ([[stage-numbering-and-player-craft]]), and the roster omits both while
keeping `rou_f001` — so "the playable or most-used models" is dead too.
[[unit-substructure-records]] mentions `Generic.Model` as "the mesh the corpus
already decodes"; what it does not say is that there are only **46 distinct**
values of it disc-wide. `AsteroidGroup_00N` / `AsteroidModelName` are new nouns.