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

re: the take-off sequence lands in the launch CUTSCENE, not a hang

Browse Source 
Logging file and kernel activity through the whole navigation and counting names:

    12  \dat\movie      <- heavy, repeated movie access
     3  \dat\sound
     2  Stage_S01       <- the stage resource is referenced
     1  XamShowDeviceSelectorUI

So after take-off the game plays the launch cutscene.  Under software rendering a
720p decode is very slow -- this corpus already raised INSTRUCTIONS_PER_MS 100x
because the movie handler has a 2000 ms software-decode deadline -- which is why
the state persists for minutes.

It is unambiguously live, by the widest margin yet measured:

                     frozen   menus   this state
    screen liveness  0.00%    0.22%   11.00%
    guest churn      0.000%   0.190%  0.671%

and the progress counter advances on input (17 -> 101 across the skip attempts),
so the pad reaches the game.

But it does not skip: four rounds of START / A / B advanced the counter every
time and left DEF_VTABLE / INST_VTABLE at 0/0.  The input registers, it just does
not end the sequence.

The remaining gap is now narrow and named: the take-off cutscene runs and is not
skippable by the obvious buttons.  Either it must play out, or the right skip
input is unknown, or it waits on something the movie path never delivers.
This commit is contained in:
Sylpheed RE agent
2026-08-26 19:30:21 +00:00
parent 926cee6ba0
commit 9031c2510a
1 changed files with 37 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -134,3 +134,40 @@ So the run reaches a **live, animating state that is not a mission with spawned
units** — most likely the launch cinematic or a post-take-off screen. The freeze
is gone; identifying where the sequence actually lands, and what still separates
it from unit spawn, is the remaining work.
## ✅ Where the take-off sequence lands: the **cutscene**, not a hang
Logging file and kernel activity through the whole navigation
(`--log_level=3 --log_mask=0`) and counting the names that appear:
12 \dat\movie <- heavy, repeated movie access
3 \dat\sound
2 Stage_S01 <- the stage resource IS referenced
1 XamShowDeviceSelectorUI
So after take-off the game is **playing the launch cutscene**. Under software
rendering a 720p movie decode is very slow — this corpus already had to raise
`INSTRUCTIONS_PER_MS` 100× because the movie handler has a 2 000 ms
software-decode deadline — which is exactly why this state persists for minutes.
The state is unambiguously **live**, and by the widest margin measured so far:
| | frozen | menus | **this state** |
|---|---|---|---|
| screen liveness | 0.00 % | 0.22 % | **11.00 %** |
| guest churn | 0.000 % | 0.190 % | **0.671 %** |
and the progress counter advances on input — `17 → 101` across the skip attempts
— so the pad is reaching the game.
## ❔ But the cutscene does not skip, and units never spawn
Four rounds of START / Ⓐ / Ⓑ advanced the counter every time yet left
`DEF_VTABLE` / `INST_VTABLE` at **0 / 0**. The input registers; it just does not
end the sequence.
So the remaining gap is narrow and well-defined: **the take-off cutscene runs and
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.