fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: the post-take-off state is measurably neither a menu nor flight

Browse Source 
wait_flight.sh carries the corpus's best discriminator, and it is a whole-image
statistic rather than a named pixel: the flight HUD paints green over the frame
at 1.3-1.5% green fraction, against <0.1% on every menu.

Measured on the post-take-off state: green=0.0022, mean (1.6, 45.6, 50.1).  That
is 0.22% -- an order of magnitude above a menu, an order of magnitude below
flight, on a dark blue-green frame.  screen_id.py files it under "menu" because
that is the closest bucket it has; the state is neither.

wait_flight.sh then tapped A for 280 seconds and never saw the HUD.

With the 12 \dat\movie accesses, the reading is consistent: this is the cutscene,
it does not end on A, and it does not reach the flight HUD within five minutes.

Open, cheapest first: how the movie path signals completion (the corpus already
decoded the movie handler for the intro video and found a software-decode
deadline); whether a mission can be started by a route that skips the launch
cinematic; or whether the cutscene simply needs far longer under lavapipe.

Oracle status overall: boot, menus and take-off are reliable and reproducible;
only the cutscene->mission step is unsolved -- a much smaller and better-defined
gap than the freeze it replaced.
This commit is contained in:
Sylpheed RE agent
2026-08-26 19:43:40 +00:00
parent 454be7b0de
commit 9e421b341c
1 changed files with 32 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/re/mission-freeze-signin-dialog.md
View File

@@ -171,3 +171,35 @@ is not skippable by the obvious buttons.** Either it must be played out (long,
under lavapipe), or the right skip input has not been found, or it is waiting on
something the movie path never delivers. That is the next question, and it is now
a question about *one* identified sequence rather than about a mysterious hang.
## 🟡 The post-take-off state is measurably neither a menu nor flight
`wait_flight.sh` carries the best discriminator in the corpus, and it is a
whole-image statistic rather than a named pixel: the flight HUD paints green over
the frame at **1.3–1.5 %** green fraction, against **< 0.1 %** on every menu.
Measured on the post-take-off state:
menu green=0.0022 white=0.0001 mean=(1.6, 45.6, 50.1)
**0.22 %** — an order of magnitude above a menu, an order of magnitude below
flight, and a dark blue-green frame. `screen_id.py` files that under `menu`,
which is simply the closest bucket it has; the state is neither.
`wait_flight.sh` then tapped Ⓐ for **280 seconds** and never saw the HUD:
`NO FLIGHT HUD within 280s (last: menu)`.
Taken with the 12 `\dat\movie` accesses, the reading is consistent: this is the
**cutscene**, it does not end on Ⓐ, and it does not reach the flight HUD within
five minutes of trying.
❔ What that leaves, in order of cheapness: (1) how the movie path signals
completion — the corpus already decoded the movie handler for the intro video and
found a software-decode deadline, so the same machinery may say what "done" looks
like; (2) whether a mission can be started by a route that skips the launch
cinematic; (3) whether the cutscene simply needs far longer than five minutes
under `lavapipe`.
**Status of the oracle overall: boot, menus and take-off are now reliable and
reproducible; only the cutscene→mission step is unsolved.** That is a much
smaller and better-defined gap than the freeze it replaced.