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

re: the working entity captures came from a SAVE SLOT, not mission select

Browse Source 
Before deriving a new vtable I checked where gworld.py's constants came from.
They cite structures/unit-struct-runtime.md, which states its provenance:
"Captured 2026-07-29 ... all six tutorials and Stage 02 'Declaration of War'
loaded from save slot 01."

Loaded from a save slot -- not through MISSION SELECT, which is the route every
run this session has taken, and which needs the cleared-stage mask poke to offer
a stage at all.  So the constants may not be stale; they may just need the state
that route produces.  That is a cheaper question than writing a new vtable
finder, and it should be answered first.

First attempt inconclusive: driving the main menu's first item blind, five
presses deep, advanced the progress counter every time (3 -> 5 -> 6 -> 8 -> 10 ->
12, so the game responds) but left DEF_VTABLE / INST_VTABLE at 0/0 throughout.
Without a screen identity this is dead reckoning, and the first item may not be
the load-game entry -- newgame_path.sh documents it as NEW GAME with SELECT DATA
two screens further in.

Next: reach the save-slot screen deliberately rather than by counting presses,
and load slot 01.
This commit is contained in:
Sylpheed RE agent
2026-08-26 20:13:33 +00:00
parent b56a4ab9f9
commit 1bada3ba4c
1 changed files with 30 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -287,3 +287,33 @@ statement is:
the constructor that writes a vtable pointer, via `sylpheed.db`'s `vptr_writes`
table, which exists precisely for this); or find the entity list from the mission
update function rather than from data.
## ✅ The corpus records how the working entity captures were made — and it is a different route
Before deriving a new vtable, I checked where `gworld.py`'s constants came from.
They cite [`structures/unit-struct-runtime.md`](structures/unit-struct-runtime.md),
which states its provenance plainly:
> Captured 2026-07-29 from Xenia Canary running the retail disc in the sylph-re
> container: **all six tutorials** and **Stage 02 "Declaration of War" loaded from
> save slot 01.**
**Loaded from a save slot** — not through `MISSION SELECT`, which is the route
every run in this session has taken (and which needs the cleared-stage mask poke
to offer a stage at all). So the constants are not necessarily stale: they may
simply require the state that route produces.
That reframes the entity hunt. Before writing a new vtable finder, the cheaper
question is whether the *save* route reaches a state the *mission-select* route
does not.
🟡 First attempt inconclusive: driving the main menu's **first** item blind, five
presses deep, advanced the progress counter every time (`3 → 5 → 6 → 8 → 10 →
12`, so the game is responding) but left `DEF_VTABLE` / `INST_VTABLE` at **0 / 0**
throughout. Without a screen identity the route is dead reckoning, and the first
item may not be the load-game entry at all — `newgame_path.sh` documents it as
NEW GAME, with `SELECT DATA` two screens further in.
❔ Next: reach the save-slot screen deliberately rather than by counting presses,
and load slot 01. `newgame_path.sh` already encodes NEW GAME → DIFFICULTY →
SELECT DATA and is the closest existing script to that path.