From 3e267ad4c4d39061dcd6c084fbb5d75b4a3845fc Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 19:56:52 +0000 Subject: [PATCH] re: the mission DOES load -- DEF_VTABLE=0 was a stale constant, not an empty game Three iterations concluded "no units are loaded" from scan_vtable(DEF_VTABLE) returning 0. Withdrawn: the scan was measuring the wrong thing. Counting unit-name strings in guest memory with the TITLE as a control (same boot recipe, no mission): string title after take-off DeltaSaber 0 81 rou_ 1,981 7,680 UN_ 19 167 e010 67 134 ADAN 1,450 1,921 DeltaSaber is the player's craft: absent at the title, present 81 times after take-off. Every other count rises several-fold. The stage content is unambiguously in memory. The control is what makes this a result. Raw counts prove nothing on their own -- rou_ and ADAN are numerous at the title too, because the unit tables load at boot. Only the title-vs-mission difference, and DeltaSaber's 0 -> 81 in particular, separates "tables loaded" from "mission loaded". My first reading skipped the control and over-claimed; the control was run before publishing. Withdrawn as a consequence: "no units are loaded"; and the inference that the take-off lands in a never-ending cutscene (the movie accesses are real, but the conclusion rested on DEF_VTABLE=0). gworld.py's DEF_VTABLE 0x820AF844 and INST_VTABLE 0x820AF030 do not locate entities in this build/state despite being genuine vtables in sylpheed.db. Next: derive the correct entity vtable. The UN_ strings reachable by search are UN_NOSE/UN_MOUNT attachment names in the XEX image, not runtime records -- so use a name that only exists at mission time. DeltaSaber is exactly that: find its heap occurrences, find what points at them, read the referencing object's vtable. --- docs/re/mission-freeze-signin-dialog.md | 50 +++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/docs/re/mission-freeze-signin-dialog.md b/docs/re/mission-freeze-signin-dialog.md index c5ebed1c..d6f37f4b 100644 --- a/docs/re/mission-freeze-signin-dialog.md +++ b/docs/re/mission-freeze-signin-dialog.md @@ -203,3 +203,53 @@ under `lavapipe`. **Status of the oracle overall: boot, menus and take-off are now reliable and reproducible; only the cutscene→mission step is unsolved.** That is a much smaller and better-defined gap than the freeze it replaced. + +--- + +# ✅✅ The mission **does** load — and `DEF_VTABLE = 0` was a stale constant, not an empty game + +**2026-08-26.** Three iterations concluded "no units are loaded" from +`gworld.scan_vtable(DEF_VTABLE)` returning 0. That inference is **withdrawn**. +The scan was measuring the wrong thing. + +Counting unit-name strings in guest memory, with the **title screen as a +control** (same boot recipe, no mission loaded): + +| string | title (control) | after take-off | +|---|---|---| +| **`DeltaSaber`** | **0** | **81** | +| `rou_` | 1 981 | **7 680** | +| `UN_` | 19 | **167** | +| `e010` | 67 | 134 | +| `ADAN` | 1 450 | 1 921 | + +`DeltaSaber` is the **player's craft**, and it is **absent** at the title and +present 81 times after take-off. Every other count rises several-fold. The stage +content is unambiguously in memory. + +⚠️ The control is what makes this a result. Raw counts alone prove nothing — +`rou_` and `ADAN` are numerous at the title too, because the unit *tables* load at +boot. Only the title-vs-mission **difference**, and `DeltaSaber`'s 0 → 81 in +particular, separates "the tables are loaded" from "the mission is loaded". My +first reading of these counts skipped the control and over-claimed; the control +was run before publishing. + +## 🔴 What this withdraws + +* **"No units are loaded"** — wrong. The mission loads. +* **"The take-off sequence lands in a cutscene that never ends"** — the movie + accesses are real, but the conclusion drawn from `DEF_VTABLE = 0` alongside them + does not follow. The game may well be *in* the mission. +* By extension, `gworld.py`'s `DEF_VTABLE = 0x820AF844` / `INST_VTABLE = + 0x820AF030` do **not** locate entities in this build/state, even though both are + genuine vtables in `sylpheed.db`. They are the wrong ones, or entities are + reached another way. + +## ❔ Next, and it is now concrete + +Derive the **correct** entity vtable rather than trusting the stored constant: +the `UN_` strings reachable this way turned out to be `UN_NOSE` / `UN_MOUNT` +attachment names living in the **XEX image** (`0x820A…`), not runtime definition +records — so the route in is a name that only exists at mission time. +**`DeltaSaber` is exactly that name**: find its occurrences in the heap, find what +points at them, and read the vtable pointer of the referencing object.