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:
@@ -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.**
|
||||
|
||||
Reference in New Issue
Block a user