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

docs: propagate u00428010/op-0x1a2 correction into opcodes.toml + name-resolution

Browse Source 
op 0x1a2 resolve-handle? -> gfx-cmd-register (verified handler FUN_0042d360, gfx
command-buffer op). name-resolution: decision->scene hop is native+unidentified, not
u00428010 (disproven). Regenerated opcode-reference + shim.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
gamer147
2026-07-07 11:47:35 -04:00
parent 1323ec8852
commit 057a26a97a
4 changed files with 16 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/name-resolution.md
View File

@@ -46,8 +46,10 @@ on disk to read. Resolving it needs one of:
**Update (2026-07-07):** SCJUMP's *decision logic* is now decoded — `(chapter_mode, guards) →
decision value` — see `docs/scjump-progression.md` and `tools/scjump_decode.py`. That confirmed
SCJUMP is not the `call-script` registry (it produces a decision value, not a script id). The
decision→scene hop itself is a **native op (`u00428010`)**, engine-level, in the same bucket as
`call-script`; both await the engine dump / Frida.
decision→scene hop is **native and still unidentified** — an earlier guess that op `u00428010`
resolved it was **disproven via Ghidra** (that op is a graphics command-buffer op; see
`docs/engine-re.md`). It's the same engine-level bucket as `call-script`; the Ghidra + MCP loop (and
its recovered opcode-dispatch table) is now the tool to crack the `call-script`/script-load handler.
---