re: the stage numbering is consistent everywhere; the manifest still declares the cut S17

Correction first: the previous commit claimed the corpus 'did not know
the stage NUMBERS'.  It did -- structures/mission-script-ssb.md has
recorded S01-S16, S18-S29, S17 absent by a three-way convergence (hash
lookup, the table sweep, the loader's != 16 guard) since before that
pass.  What was actually new there is the player craft per stage and
ResourceID's ordinal tags; the numbering is a fourth independent route,
not a discovery.

The question this item asked: do the ISL StageNN.ssb files and the
UnitGroup_SNN.tbl tables use the same numbering, or is something
silently mis-labelled?  They are identical.  Stage\StageNN.ssb,
stage\UnitGroup_SNN.tbl and stage\Route_SNN.tbl all resolve for the
same 28 N with an EMPTY symmetric difference; AIParams is the same minus
18-23.  Nothing in the corpus is mis-keyed.  Formation_SNN and
Message_SNN resolve 0/40 -- those are field names, not files, and the
four families above are the controls that make that negative real.

New: Stage\script.tbl's SCRIPTS record lists 29 MISSION*.ssb fields --
MISSION1..MISSION29, including MISSION17 = Stage17.ssb -- and only 28 of
29 name a file that ships.  Control: MISSIONn -> Stage<n>.ssb with the
same n, 0/29 mismatched.  So S17 is a cut mission the shipping manifest
still names, which is why the loader carries an explicit != 16 guard
rather than just running 0..27.

Artefact +14 lines / 0 deletions; the other four regenerate
byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-27 13:27:19 +00:00
parent 28a59d839f
commit ccdc226022
4 changed files with 111 additions and 3 deletions

View File

@@ -827,6 +827,32 @@ unknown, what evidence exists, and what the first step would be. Move an item in
field; the stat keys in records not opened here (`MegaTons`, `BulletLimit`,
`CrewCount`, `HP_CLASS`); why the roster lists 59 of 131.
***(2026-08-27) THE STAGE NUMBERING IS CONSISTENT EVERYWHERE — and the
manifest still declares the cut S17.** Also a **correction to my own claim**
in the entry below.
[structures/stage-numbering-and-player-craft](structures/stage-numbering-and-player-craft.md),
artefact `data/stage-numbering.txt` (+14 lines, 0 deletions — purely additive).
**Correction first**: the entry below says the corpus "did not know the
stage NUMBERS". It did — `structures/mission-script-ssb.md` has recorded
**S01-S16, S18-S29, S17 absent** by a three-way convergence (hash lookup, the
table sweep, the loader's `!= 16` guard) since before that pass. What was
actually new there is the **player craft per stage** and `ResourceID`'s
ordinal tags. The numbering is a fourth independent route, not a discovery.
**The question this item asked** — do the ISL `StageNN.ssb` files and the
`UnitGroup_SNN.tbl` tables use the same numbering, or is something silently
mis-labelled? **They are identical**: `Stage\StageNN.ssb`,
`stage\UnitGroup_SNN.tbl` and `stage\Route_SNN.tbl` all resolve for the same
28 N, **symmetric difference EMPTY**; `AIParams` is the same minus 18-23.
Nothing in the corpus is mis-keyed. (`Formation_SNN`/`Message_SNN` resolve
0/40 — field names, not files; the four families above are the controls that
make that negative real.)
🔑 **New**: `Stage\script.tbl`'s `SCRIPTS` record lists **29** `MISSION*.ssb`
fields — `MISSION1`..`MISSION29`, **including `MISSION17 = Stage17.ssb`**
and only **28 of 29** name a file that ships. Control: `MISSIONn` ->
`Stage<n>.ssb` with the same `n`, **0/29 mismatched**. So S17 is a **cut
mission the shipping manifest still names**, which is why the loader carries
an explicit `!= 16` guard rather than just running 0..27.
* ✅✅ **(2026-08-27) THE DISC'S STAGE NUMBERS ARE NOT 1..28 — S01-S16, S17
ABSENT, S18-S23 the tutorials, S24-S29 — and the player's craft per stage
falls out with it.**