fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

tools: launch_mission reaches Stage 02 flight unattended again - wait for screens, not seconds

Browse Source 
Two separate reasons the scripted route stopped, both measured rather than guessed:

* LOAD -> READY ROOM is not 28 s. Both runs on 2026-08-23 overran it, so the next
  press was eaten by the transition and the run ended up in OPTIONS once and
  BRIEFINGS once. wait_screen.sh now waits for the screen, with an optional
  --tap that clears a dialog the caller cannot know about (a freshly restored
  profile inserts "Auto-Save is active. OK?" here).
* The READY ROOM is DRAWN long before it is USABLE: it comes up with a
  "Preparing to Sortie" spinner and TAKE OFF greyed out. The two states differ by
  1.7 units of blue whole-image, so screen_id.py cannot separate them and should
  not try. take_off_armed.py tests the label instead: 0.0000 bright pixels while
  preparing, 0.1633 once armed, on three captures from two runs. It carries its
  own position check - the always-enabled BRIEFINGS label below reads 0.1027 in
  all three, to four decimals, so if that reference is dark the boxes are off the
  labels and the answer is "unknown", not a confident wrong one.

screen_id.py gains a "readyroom" class from the same measurements; nothing else
reclassifies.

Verified end to end and unattended: boot -> title -> LOAD GAME -> slot 01 ->
READY ROOM -> TAKE OFF -> "IN FLIGHT at 34s", pilot bound and engaging.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-23 18:02:00 +00:00
parent 37c3585f4f
commit 06d00d4529
4 changed files with 150 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
tools/re-capture/launch_mission.sh
View File

@@ -69,8 +69,33 @@ tap A; sleep 8 # save list, slot 01 preselected
tap A; sleep 4 # "Load game?" -- cursor starts on NO
step up
tap A
sleep 28 # -> READY ROOM
shot "lm-readyroom.png"
# NOT a fixed sleep. LOAD -> READY ROOM took longer than 28 s in both runs on
# 2026-08-23, so the next press was eaten by the transition and the run ended up
# in OPTIONS (once) and BRIEFINGS (once); and a freshly restored profile inserts
# an extra "Auto-Save is active. OK?" dialog here, which the `--tap A` clears
# without the script having to know whether it is there.
# KNOWN LIMIT, stated rather than hidden: those blind A taps are safe only
# because everything before this point still lands. If the save-list presses
# ever drift and the run is still sitting on the MAIN MENU here, a blind A would
# start a NEW GAME. The real fix is to wait for each screen on the route rather
# than only for this one; only this transition has actually been measured to
# overrun, so only this one is waited for.
"$SD/wait_screen.sh" readyroom 300 --tap A \
|| { echo "NEVER REACHED READY ROOM"; exit 1; }
# ...and the READY ROOM is DRAWN before it is usable: it comes up with a
# "Preparing to Sortie" spinner and TAKE OFF greyed out, for tens of seconds.
# Pressing during that does nothing, and the press after it then lands on the
# wrong item. The two states are the same image to within 1.7 units of blue, so
# they need the label test rather than screen_id.py.
armed=0
for _ in $(seq 1 60); do
shot "lm-readyroom.png"
if python3 "$SD/take_off_armed.py" "$SHOTS/lm-readyroom.png" >/dev/null; then
armed=1; break
fi
sleep 3
done
[ $armed -eq 1 ] || { echo "TAKE OFF NEVER ARMED"; exit 1; }
if [ "$MODE" = "--hangar" ]; then
step down; step down # BRIEFINGS -> HANGAR