5149c7be5d
LOAD GAME, TUTORIAL and OPTIONS all reset on re-entry, joining EXTRAS. With the main menu persisting, the rule is four of four submenus resetting and one exception -- the opposite of what a single screen had suggested. Fourth attempt, and every control in it is a previous failure: the decision uses the cursor's own region so no per-screen geometry is assumed (sweep 1 read the main menu's gutter on screens whose cursors are elsewhere); the back-on-the-menu test is the narrow ring row (sweep 2 died when a crash dialog defeated whole-frame comparison); absolute row checks after every press (a constant offset passes a differential control); and a two-sided self-test that constructs both verdicts, which had already caught a rule I broke myself. Screens confirmed by eye and committed as evidence, because an earlier run was fooled about which screen it was on. LOAD GAME's 21.6 is explained by its list scrolling rather than moving a ring. Still not separated: resets-to-named-item vs resets-to-top-item. None of these three has an opening item that is not its first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
63 lines
3.8 KiB
Plaintext
63 lines
3.8 KiB
Plaintext
# Do LOAD GAME, TUTORIAL and OPTIONS remember their cursors? ✅ NO -- ALL RESET.
|
|
# MEASURED 2026-08-31, one boot, fourth attempt.
|
|
#
|
|
# The main menu PERSISTS its cursor across menu -> title -> menu
|
|
# (focus-persists-across-title.txt). EXTRAS RESETS (extras-focus-resets.txt).
|
|
# Two screens disagreeing means no menu-wide rule and every screen must be
|
|
# measured. These are the three that were left. ❔ NEW GAME stays deliberately
|
|
# untested -- it starts a game.
|
|
#
|
|
# LOAD GAME RESETS in-cursor 21.6 from opened vs 86.3 from where left
|
|
# TUTORIAL RESETS in-cursor 2.3 from opened vs 113.2 from where left
|
|
# OPTIONS RESETS in-cursor 1.9 from opened vs 102.6 from where left
|
|
#
|
|
# ✅ SO: FOUR OF FOUR MEASURED SUBMENUS RESET. Only the MAIN MENU persists, and
|
|
# it is the exception rather than the rule.
|
|
#
|
|
################################################################################
|
|
# WHY THIS RUN WORKED WHERE THREE DID NOT -- every control here is a previous
|
|
# failure:
|
|
#
|
|
# * DECISION ON THE CURSOR'S OWN REGION. The pixels that change when the cursor
|
|
# moves ARE the cursor, so no per-screen geometry is assumed. Sweep 1 voided
|
|
# all three because ring_row.py scans the MAIN MENU's gutter (x 500:542) and
|
|
# these screens put their cursors at x 97..231, 338..1099 and 153..479 -- it
|
|
# was reading a static element and reporting no motion.
|
|
# * NARROW back-on-the-menu test, by ring row. Sweep 2 died when a crash dialog
|
|
# covered the screen centre: a whole-frame identity test can never match again
|
|
# once anything overlays the frame, while the narrow column kept reading.
|
|
# * ABSOLUTE row check after EVERY navigation press, not just the total -- a
|
|
# constant offset passes a differential control exactly, which is how an
|
|
# earlier run walked to OPTIONS believing it was EXTRAS.
|
|
# * A TWO-SIDED SELF-TEST that constructs BOTH verdicts from known frames and
|
|
# exits 3 if either is wrong. It passed here; it had already caught a rule I
|
|
# broke myself in sweep 3, which would otherwise have reported RESETS for all
|
|
# three screens -- the same answer, fabricated.
|
|
# * Every press confirmed from the guest's own [RE-INPUT] log.
|
|
# * The tool COMMITTED BEFORE RUNNING, and nothing else run during the boot.
|
|
#
|
|
# ✅ AND THE SCREENS ARE CONFIRMED BY EYE, because a previous run was fooled about
|
|
# which screen it was on:
|
|
# captures/menu-nav/live-tutorial-submenu.png -- TUTORIAL: BASIC CONTROLS /
|
|
# HEADS-UP DISPLAY / RADAR under "Level 1", SUPPLY AND SPECIAL MOVES / RADIO
|
|
# ORDERS / ADVANCED CONTROLS under "Level 2", then BACK. Seven items in two
|
|
# groups, with a description panel on the left.
|
|
# captures/menu-nav/live-load-game-slots.png -- LOAD GAME: a SCROLLING slot
|
|
# list with the selection held at the vertical CENTRE, Details panel at right.
|
|
#
|
|
# 📌 LOAD GAME's 21.6 is the one number that is not near zero, and the capture
|
|
# explains it: the list SCROLLS rather than moving a ring, so a DOWN redraws the
|
|
# whole list and re-entry restores the scroll position rather than a cursor sprite.
|
|
# 4x separation, same verdict, different mechanism.
|
|
#
|
|
# ❔ STILL NOT SEPARATED: "resets to the named item" vs "resets to the TOP item".
|
|
# sylpheed-port asked for a submenu whose opening item is not its first, which
|
|
# would decide it. None of these is one. TUTORIAL opens on BASIC CONTROLS (first),
|
|
# OPTIONS on GAME SETTINGS (first), and LOAD GAME on slot 01 -- which LOOKS
|
|
# non-first because slots 19 and 20 are drawn above it, but that is the list
|
|
# wrapping around a centred selection, and 01 is still the first slot.
|
|
#
|
|
# ⚠️ REACH: one boot, one round trip per screen, one direction (DOWN), and one
|
|
# entry each. Not tested: a second re-entry, a reset after a reboot, or whether
|
|
# any submenu behaves differently when entered from a different parent focus.
|