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

re: the mission DOES load -- DEF_VTABLE=0 was a stale constant, not an empty game

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-26 19:56:52 +00:00
parent 9e421b341c
commit 432cc43885
1 changed files with 50 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
docs/re/mission-freeze-signin-dialog.md
View File

@@ -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.