1f17726526
The briefing map is cyan and satisfies every clause of the menu rule (b-r > 30, r < 45, little white), with no earlier rule claiming it -- so it was labelled `menu`. That made wait_screen.sh report NEVER REACHED READY ROOM on a run that had successfully done LOAD GAME -> slot 01 -> YES and was three screens further on: a working route scored as a failed one, pointing the next debugging step at an input path that was fine. Cyan has b and g nearly equal (b-g ~ 5) where the menu's blue leads its green (b-g ~ 32), so `r < 20 and g > 30 and b - g < 20` separates them; the r floor keeps the title screen out. The file's own docstring already carried the briefing's mean as an aside -- it just never had a class. Verified against all eight signatures the file documents (2 menu variants, title, ready room, flight, 3 briefing measurements): no regressions, and the captured briefing image now reads `briefing`.
2.6 KiB
✅ screen_id.py filed the mission briefing as menu — a successful route scored as a failure
Confidence: ✅ CONFIRMED and FIXED. Measured 2026-08-26.
Symptom
launch_mission.sh's nav ran to completion and wait_screen.sh readyroom 300
reported:
NO readyroom within 300s (last seen: menu)
NEVER REACHED READY ROOM
The obvious reading — and the one taken at first — is that the presses after the main menu never landed. That reading was wrong twice over:
- Pad input was landing. With the game's own cursor counter as the oracle, two
dpad downpresses moved it24 → 26 → 28. - The run was not on the main menu. It was on the mission briefing map
("Glasner Training Area", Ⓐ:Continue / Ⓑ:Back / START:Skip) — three screens
past the menu, i.e.
LOAD GAME → slot 01 → YEShad all worked.
Cause
The briefing is cyan; the menu rule tests for dark and blue and the
briefing satisfies every clause of it — b - r > 30, r < 45, white < 0.075.
With no earlier rule claiming it (the ready-room rule needs b > 110, the flight
rule needs green), it fell through and was labelled menu.
Ironically the file's own docstring already recorded the distinguishing number: it notes the briefing as "cyan rather than blue at (4.6, 47.7, 54.5)" — as an aside justifying the ready-room threshold, never as a class of its own.
Fix
Cyan has blue and green nearly equal; the menu's blue runs far ahead of its green:
| screen | measured means | b - g |
|---|---|---|
| briefing | (1.4, 45.2, 49.6), (5.5, 49.1, 54.3), (4.6, 47.7, 54.5) | ~5 |
| main menu | (25, 38, 70), (13, 26, 59) | ~32 |
So r < 20 and g > 30 and b - g < 20 → briefing, placed above the menu rule.
The r < 20 floor keeps the title screen (52.8, 66.1, 74.5, b - g 8.4) out;
the ready room (b - g ~97) and flight (green rule) are already claimed above.
Verified against every signature the file documents — the two menu variants,
title, ready room, flight, and three briefing measurements: 8/8 classify as
intended, no regressions. The real capture above now reads briefing.
Why it mattered
This is the expensive failure mode, not a cosmetic one: a route that worked was reported as broken, and the conclusion drawn from it — "the presses are not landing" — would have sent the next iteration to debug an input path that was fine. Compare the same file's earlier note about a run that "sat on a plainly visible MAIN MENU for 300 s": same class of bug, second occurrence.