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

re: the mission scripts were already found -- correct a stale 🔴 that cost three iterations

Browse Source 
mission-phase-advance.md still carried "🔴 Not settled: where the script bytecode
lives".  It was settled, in a sibling file I had never opened:
structures/mission-script-ssb.md, which says in its own opening that this file
"recorded the bytecode as not on the disc under any obvious name.  It is on the
disc."

Verified independently before correcting: name_hash resolves Stage\script.tbl (the
manifest, 838 B compressed) and 28 Stage\StageNN.ssb records -- S01-S16, S18-S29 --
all in dat/GP_MAIN_GAME_S.pak, with Stage\Stage17.ssb absent, matching the loader
guard sub_8225EC78 (n == 16 || n > 32).

Recorded WHY the last three iterations' searches could not have worked, since that
is the reusable part: MISSION1..33 and MISSION_*_PRT are manifest FIELD KEYS, not
record names.  The records are named Stage\StageNN.ssb and the manifest maps
between them, so probing the record namespace with field-key names cannot hit --
2148 hashes over 41 paks and 26443 records returned zero for that reason alone.

Two side findings survive: the .embsec_ sections hold PPC code, not bytecode; and
the archive lookup keys by tag_hash (0x00FFFFDF) while the pak record index uses
name_hash -- not interchangeable.
This commit is contained in:
Sylpheed RE agent
2026-08-27 04:22:25 +00:00
parent b3d146b758
commit b9dab5772a
1 changed files with 31 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/re/mission-phase-advance.md
View File

@@ -102,7 +102,37 @@ Nothing anywhere parses `Route_*_p<N>*` names either; the only three such
literals in the image (`0x820AEA38`) are debug defaults, not a parser. So the
route-name phase map is a *convention of the data*, read by us, not by the game.
## 🔴 Not settled: where the script bytecode lives
## ✅ SETTLED — the scripts ARE on the disc: `Stage\StageNN.ssb`
> ### ⚠️ 2026-08-27 — this section was STALE and cost three iterations
>
> Everything below said the bytecode had not been located. It **had**, in a
> sibling file: [`structures/mission-script-ssb.md`](structures/mission-script-ssb.md),
> which states plainly that this file "recorded the bytecode as *not on the disc
> under any obvious name*. **It is on the disc**".
>
> Verified independently here before correcting: `name_hash` resolves
> `Stage\script.tbl` (the manifest, 838 B compressed) and **28** `Stage\StageNN.ssb`
> records — S01–S16 and S18–S29 — all in `dat/GP_MAIN_GAME_S.pak`, with
> **`Stage\Stage17.ssb` absent**, matching the loader's own guard
> `sub_8225EC78: if (n == 16 || n > 32) return`.
>
> **Why the searches below failed**, which is the reusable part: `MISSION1` …
> `MISSION33` and `MISSION_*_PRT` are **manifest FIELD keys**, not record names.
> The record names are `Stage\StageNN.ssb`, and the manifest maps one to the
> other. Probing the record namespace with field-key names cannot hit, no matter
> how many prefixes, suffixes or hash functions are tried — 2 148 distinct hashes
> across 41 paks and 26 443 records returned zero for exactly that reason. Every
> pak entry is `Z1` + zlib, so no plaintext name is greppable either.
>
> Two findings from that search still stand on their own:
> * ❌ the seven `.embsec_` sections hold **PPC code**, not bytecode (129 472 B,
> all with standard prologues) — so they were never the answer;
> * the archive lookup keys by **`tag_hash`** (`0x00FFFFDF`, case-sensitive), not
> `name_hash` — while the pak record index uses `name_hash`. They are not
> interchangeable, and `Stage\StageNN.ssb` resolves under `name_hash`.
### (historical) Not settled: where the script bytecode lives
The loader `sub_8225EE20` matches section names `MISSION1`..`MISSION33` and the
five `MISSION_{START,END,UPDATE,FAILED,RESTART}_PRT`, and `sub_8225EC78` gates