fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

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

43
docs/re/structures/stage-numbering-and-player-craft.md
View File

@@ -1,8 +1,16 @@
# ✅✅ The disc's stage NUMBERING, and which craft the player flies in each
The corpus has known "the disc has 28 stages" and "the six tutorials have no
`AIParams`" for a while. **It did not know the stage NUMBERS.** They are not
1…28:
> ## ❌ CORRECTION (2026-08-27, same day) — the NUMBERING was already known
>
> This page first claimed the corpus "did not know the stage NUMBERS". Wrong:
> [mission-script-ssb](mission-script-ssb.md) has recorded **S01–S16, S18–S29,
> S17 absent** by a three-way convergence (hash lookup, the table sweep, and the
> loader's `!= 16` guard) since before this pass. What is new here is the
> **player craft per stage** and `ResourceID`'s ordinal tags; the numbering
> below is a re-derivation, not a discovery. Kept because it is the fourth
> independent route and because the craft mapping is keyed on it.
The disc's stage numbers are not 1…28:
```
S01 … S16 story (16)
@@ -63,6 +71,35 @@ Every number closes against `ResourceID`, from a different file:
🔑 So **the player flies the DeltaSaber A in exactly one mission — S28** — and
the DeltaSaber T only for the first six.
## ✅ Every per-stage file family uses the SAME numbering
Checked because a mismatch would have silently mis-labelled stages across the
corpus. It does not exist:
| family | count | N |
|---|---:|---|
| `Stage\StageNN.ssb` | 28 | 1–16, 18–29 |
| `stage\UnitGroup_SNN.tbl` | 28 | identical |
| `stage\Route_SNN.tbl` | 28 | identical |
| `stage\AIParams_SNN.tbl` | 22 | the same minus 18–23 |
**`ssb == UnitGroup == Route`, symmetric difference empty.** (`Formation_SNN` and
`Message_SNN` resolve 0/40 — those are field names, not files; the four families
above are the positive controls that make that a real negative.)
## 🔑 The manifest declares a stage the disc does not ship
`Stage\script.tbl`'s `SCRIPTS` record lists **29** `MISSION*.ssb` fields —
`MISSION1` … `MISSION29`, **including `MISSION17 = Stage17.ssb`**. Only **28 of
the 29** name a file that is actually in the pak; the one missing is
`MISSION17`. Control: `MISSIONn` → `Stage<n>.ssb` with the same `n`, **0/29
mismatched**.
So S17 is not a numbering quirk — it is a **cut mission that the shipping
manifest still names**, which is why the loader carries an explicit `!= 16`
guard ([isl-condition-builtins](isl-condition-builtins.md)) rather than simply
running 0…27.
## 🟡 Not settled
* The Arsenal entry FILENAMES are still unrecovered, so *which* of the 168