Files

sylph-decoder bbc167425f re: the .tbm submenu is not reached -- and the second tap was never delivered

Two runs, neither answering whether a .tbm draws pixels.

Run 1 TIMED the title->menu transition and was still on the title 8 s later
(glyph 714, the plate's pulse trough), so the second tap did the transition and
the 'submenu' capture is the menu. Void.

Run 2 DETECTED the menu instead -- glyph 327, matching live-main-menu.png
exactly -- tapped 0.8 s later, and 12 s after that was still on the menu. The
log says why: 2 file-pad vk=5800 lines, i.e. ONE press, and one RE-INPUT
delivery. The second tap was never delivered, with zero swallow lines so it is
not the sign-in path. A 0.12 s press issued while the guest is still loading a
screen is missed outright.

So 'the press did nothing' and 'there was no press' look identical from the
screen, and only the log separates them.

Worth more than the run: this is the third time in one iteration that timing was
used where detection was required -- the title->menu wait, the menu->submenu
wait, and the press itself. Each fix is the same substitution, and each was
written only after the timed version had produced a confident wrong answer.

Also records that no focus detector is needed for this question, since every
main-menu destination except EXTRAS carries a .tbm decider.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

2026-08-30 10:30:49 +00:00

3.5 KiB

Raw Blame History

🟡 Does a `.tbm` draw pixels? Still open — two runs, and the third timing bug in a row

Classification: not an answer. Recorded per "do not improvise around a blocker", and because the reason both runs failed is the same mistake three times over.

The question

ui-forced-backdrop.md has 24 of its 62 deciding verdicts on .tbm elements. compose draws nothing for a .tbm — no resolvable sprite — so those verdicts are "correct or inert" and the two cannot be separated. A capture of a screen carrying one would separate them.

✅ And no focus detector is needed, which is what makes this cheap now. s00a-drive-blocked-by-focus.md records that a per-row brightness statistic failed its own control, and that wrap-around makes counting presses useless. But every main-menu destination except EXTRAS lands on an archive holding a .tbm decider — GP_SYSTEM (pqbase), GP_TUTORIAL (pubase), GP_SAVE_LOAD (px_replay_base), GP_DIALOG (pcbase). So press Ⓐ on whatever is focused and identify the screen from the capture.

What happened

run	approach	result
1	timed the title→menu transition (tap, wait 8 s)	8 s later still the title — glyph 714, the plate's pulse trough. The second tap did the transition; the "submenu" capture is the menu. Void.
2	detected the menu (glyph 250–420 for 6 samples; menu is 327, plate is 714–1520)	menu found at 357.2 s, glyph 327 exactly. Tapped at 358.0 s. 12 s later: still the menu.

🔴 The second tap was never delivered


`[file-pad] vk=5800` lines	2 — that is one press, down and up
`[RE-INPUT] -> user=0 vk=5800`	one down, one up
`swallowed by IsUIActive`	0 — not the sign-in path

The tap came 0.8 s after the menu appeared, while the guest was still loading it. A 0.12 s press is missed outright if the guest does not poll during that window. The pad driver reports what it emitted; the guest never asked.

⚠️ So "the press did nothing" and "there was no press" look identical from the screen, and only the log separates them. Any driven run that presses and waits must confirm delivery in the log before interpreting the result — otherwise a missed press reads as a screen that did not respond.

The pattern worth more than the run

This is the third time in one iteration that timing was used where detection was required — the title→menu wait, the menu→submenu wait, and the press itself (assumed delivered rather than confirmed). The first two were caught because the screen was recognisable; the third only because the log records deliveries.

📌 Each fix has the same shape: replace "wait long enough" with "watch for the thing". The title detector, the menu detector and the delivery check are all that substitution, and each was written only after the timed version had already produced a confident wrong answer.

What is now validated, and what the next run needs

✅ Working: the plate-pulse title detector (three runs); the menu detector, glyph 327, matching live-main-menu.png exactly; and delivery confirmation from [RE-INPUT].

Next run: hold Ⓐ longer than 0.12 s, confirm the [RE-INPUT] line appears, retry if it does not, then detect the submenu by change rather than by timer — a submenu load may also pass through a pgloading_* screen, so "different from the menu" is the signal, not a fixed wait.

3.5 KiB Raw Blame History Unescape Escape

🟡 Does a .tbm draw pixels? Still open — two runs, and the third timing bug in a row