From b9dab5772a47c9370324963197864cd669474f20 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Thu, 27 Aug 2026 04:22:25 +0000 Subject: [PATCH] =?UTF-8?q?re:=20the=20mission=20scripts=20were=20already?= =?UTF-8?q?=20found=20--=20correct=20a=20stale=20=F0=9F=94=B4=20that=20cos?= =?UTF-8?q?t=20three=20iterations?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- docs/re/mission-phase-advance.md | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/docs/re/mission-phase-advance.md b/docs/re/mission-phase-advance.md index 985f7b34..9436a54f 100644 --- a/docs/re/mission-phase-advance.md +++ b/docs/re/mission-phase-advance.md @@ -102,7 +102,37 @@ Nothing anywhere parses `Route_*_p*` 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