From 15e58d93b14a2637a39957377dc9391e60b3d841 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 18:51:25 +0000 Subject: [PATCH] re: correct the "screen id" -- they are monotonic counters, not identities The names in menu-state-in-memory.md are wrong for at least two of the three words, and the test that shows it is going backwards. Driving deep into the menus, then three presses of B: 0x828F38AC "cursor" 36 -> 38 -> 40 -> 41 0x828F37B4 "misc" 971 -> 1067 -> 1068 -> 1068 0x828A690C "screen" 56 -> 56, 56, 56 A cursor returns when you go back. These only ever increase -- monotonic counters, with 0x828F38AC advancing about 2 per input. Driving forward produced 1,3,4,5,6,8,10,12,25,29,32,33,50,53,56 for the "screen id", which is an identity sequence only if the game has 56+ screens and never revisits one -- exactly what a counter also looks like. Withdrawn: 0x828A690C as a screen IDENTITY (1 title, 3 main menu, 4 extras). The values are path-dependent; they matched across runs because the same key sequence produces the same count, not because 3 means main menu. Survives: all three advance if and only if the game responds, and are stable when it does not. That is a real input-progress signal, reproducible across runs and both GPU backends, and it is what made blind navigation work. Read it as "did the game react?", never "which screen is this?". It also retro-confirms the freeze diagnosis: with the sign-in fix the sequence runs 3 -> 5, skipping 4 entirely, so "4 = extras" was never a screen -- it was the count at which the game stopped responding. The counter reading explains both observations. Open: no mission reached. Counters at 56/41/1068, guest churn 0.190% (alive; frozen is 0.000%), DEF_VTABLE and INST_VTABLE still 0. Without a real screen identity, navigation is dead reckoning; finding a genuine state enum is next, and the snapshot-and-diff method can be repeated with these counters excluded. --- docs/re/menu-state-in-memory.md | 46 +++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/docs/re/menu-state-in-memory.md b/docs/re/menu-state-in-memory.md index 25fb458..7cdcf67 100644 --- a/docs/re/menu-state-in-memory.md +++ b/docs/re/menu-state-in-memory.md @@ -53,3 +53,49 @@ MISSION SELECT needs a cursor move first. The screen ids beyond 4 are unmapped; the same snapshot-and-diff method extends to them, but it must be done on a rendered run, and the rendered run **freezes on entering that screen**. The way through is to map the ids up to the freeze and step blind past it. + +--- + +# 🔴 Correction: these are **counters**, not a screen id and a cursor + +**2026-08-26, same day.** The names above are wrong for at least two of the three +words, and the test that shows it is going **backwards**. + +Driving deep into the menus and then pressing Ⓑ (back) three times: + +| | before | after 3× Ⓑ | +|---|---|---| +| `0x828F38AC` ("cursor") | 36 | **38 → 40 → 41** | +| `0x828F37B4` ("misc") | 971 | **1067 → 1068 → 1068** | +| `0x828A690C` ("screen id") | 56 | **56, 56, 56** | + +A cursor returns when you go back. These **only ever increase** — they are +**monotonic counters**, and `0x828F38AC` advances by ~2 per input. Driving +forward gave `1, 3, 4, 5, 6, 8, 10, 12, 25, 29, 32, 33, 50, 53, 56` for the +"screen id": that is a plausible identity sequence *only* if the game has 56+ +screens and you never revisit one, which is precisely what a counter also looks +like. + +🔴 **Withdrawn**: "`0x828A690C` = screen id (1 title, 3 main menu, 4 extras)" as +an *identity*. The values are path-dependent — they match across runs because the +same key sequence produces the same count, not because 3 *means* main menu. +`0x828F38AC` is not a cursor and `0x828F37B4` is not a per-menu value. + +✅ **What survives, and is still useful**: all three advance **if and only if the +game responds**, and they are stable when it does not. That is a genuine +input-progress signal, reproducible across runs and both GPU backends, and it is +what made blind navigation work. Read it as *"did the game react?"*, never as +*"which screen is this?"*. + +✅ **And it retro-confirms the freeze diagnosis.** With the sign-in fix the +sequence runs `3 → 5`, **skipping 4 entirely** — so the old "4 = extras" was never +a screen at all: it was the count at which the game stopped responding, i.e. the +blocked state. Two readings of the same number, and the counter reading explains +both. + +❔ Still open: a mission is not reached. After a dozen presses the counters are at +`56 / 41 / 1068`, guest churn is **0.190 %** (alive — frozen is 0.000 %), and +`DEF_VTABLE` / `INST_VTABLE` scans are still **0 / 0**. Without a real screen +identity, navigation is dead reckoning; finding an actual screen/state *enum* is +the next job, and the snapshot-and-diff method that found these counters can be +repeated with the counters themselves excluded.