conco/OpenMaidEngine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Reverse opcode 0x1ad save resume boundary

Browse Source
This commit is contained in:
gamer147
2026-07-20 12:06:02 -04:00
parent e3b2cbed83
commit 26b6c2137c
9 changed files with 166 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/scjump-progression.md
View File

@@ -41,9 +41,10 @@ Run: `py -3.11 -X utf8 tools/scjump_decode.py --verify`.
## The native decision→scene boundary (deferred)
A FIELD snippet does `lookup-array(ptr, 0x5f0ed, 0x62ccf)` then `u00428010(ptr)`, which the spec
guessed was the scene resolver. **Correction (2026-07-07, via Ghidra):** `u00428010` (op `0x1a2`) is a
**graphics command-buffer op** (its real handler `FUN_0042d360` sets gfx cmd-type 3 and builds a
`"%c%8.8x"` key) — not save, not scene-load. So that snippet is a **graphics/UI operation, not the
guessed was the scene resolver. **Correction (refined 2026-07-20, via Ghidra):** `u00428010` (op `0x1a2`)
registers an operand's current value under a `"%c%8.8x"` key derived from its lvalue descriptor in a
separate open-addressing table. Its write of 3 at `ctx+0x53d88` is the instruction length, not a gfx
command type. So that snippet is a **value-registration operation, not the
decision→scene dispatch**. The real decision→scene mechanism is **still unidentified** and belongs with
the call-script / script-load dispatch (`name-resolution.md §1`). See `docs/engine-re.md` for the
verified handler analysis and the opcode-dispatch table that will crack call-script next.