924f16c2a1
DIFFICULTY is the screen that separates the readings: it opens on NORMAL, second of EASY/NORMAL/HARD/BACK. Reproduced on a fresh boot rather than inherited from the 2026-08-29 capture. After one confirmed DOWN to HARD, B out and A back in, it returns to NORMAL -- in-cursor 1.0 from opened against 93.9 from where left. So reset targets a per-screen opening default that need not be the first item. The other four submenus could not settle it because on each of them the opening item IS the first, so both readings predict the same observation. sylpheed-port's refusal to promote 4/4 to a rule was right on the evidence: a generalisation from those four would have got this fifth screen wrong. The probe never presses A inside a submenu, so it cannot reach SELECT DATA and the guest throw at PC 0x82307128 -- recorded in the tool's source. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
45 lines
2.4 KiB
Plaintext
45 lines
2.4 KiB
Plaintext
# Does a submenu reset to its NAMED opening item, or to its TOP item?
|
|
# ✅ TO THE NAMED ITEM. MEASURED 2026-08-31.
|
|
#
|
|
# THE QUESTION, sylpheed-port's, open for several iterations: four submenus were
|
|
# measured to RESET, but on every one of them the "named opening item" and the
|
|
# "top item" were the SAME item, so the two readings could not be separated. They
|
|
# asked for a submenu whose opening item is not its first.
|
|
#
|
|
# DIFFICULTY is one. Reached by Ⓐ on NEW GAME, it is
|
|
# EASY / NORMAL / HARD / BACK
|
|
# and it opens on NORMAL -- the SECOND of four, with EASY above it.
|
|
# ✅ Reproduced independently on a fresh boot today, not inherited from the
|
|
# 2026-08-29 capture: captures/menu-nav/live-difficulty-opens-normal.png
|
|
#
|
|
# THE RUN (tools/re-capture/submenu_focus_sweep.py, SWEEP_TARGETS=0):
|
|
# ✅ decision-rule self-test passed -- both verdicts constructible
|
|
# step 1: ring y 463.5 -> OPTIONS (want OPTIONS)
|
|
# step 2: ring y 544.5 -> EXTRAS (want EXTRAS)
|
|
# step 3: ring y 226.0 -> NEW GAME (want NEW GAME)
|
|
# S1 opened: glyph 321, 30.0 % from main
|
|
# S2 after 1 DOWN: 1.35 % of the frame changed
|
|
# ✅ CONTROL PASSED: a localised change (1.35 %)
|
|
# S3 re-entered: off-cursor p95 0.0; in-cursor |S3-S1| 1.0, |S3-S2| 93.9
|
|
# => RESETS
|
|
#
|
|
# ✅ SO THE ANSWER IS: **reset goes to the item the screen OPENS on, which is not
|
|
# necessarily the first item.** DIFFICULTY returns to NORMAL, not to EASY.
|
|
#
|
|
# 📌 WHY THE OTHER FOUR COULD NOT SETTLE IT: on EXTRAS (MISSION SELECT), TUTORIAL
|
|
# (BASIC CONTROLS), OPTIONS (GAME SETTINGS) and LOAD GAME (slot 01) the opening
|
|
# item IS the first item, so "resets to the named item" and "resets to the top
|
|
# item" predict the same observation. Five screens, and only the fifth carries the
|
|
# distinction.
|
|
#
|
|
# ⚠️ SAFETY, and it is why this run was possible at all: DIFFICULTY's FORWARD path
|
|
# crashes the guest -- Ⓐ on a difficulty opens SELECT DATA and the guest throws at
|
|
# PC 0x82307128 (title-crash-stl-tree.md). This probe presses Ⓐ to ENTER, one
|
|
# DOWN, then Ⓑ to LEAVE, and never presses Ⓐ inside a submenu, so it cannot reach
|
|
# SELECT DATA. That constraint is now recorded in the tool's source.
|
|
#
|
|
# ⚠️ REACH: one boot, one round trip, one direction, one entry. Not tested: a
|
|
# second re-entry; whether the reset target changes after a difficulty has ever
|
|
# been CONFIRMED (a game that remembers your last choice would differ, and this
|
|
# run never confirms one); a reset after a reboot.
|