From 454be7b0de51dfe341f3863f0cdbd864e7eb5a4a Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 19:30:21 +0000 Subject: [PATCH] re: the take-off sequence lands in the launch CUTSCENE, not a hang 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. --- docs/re/mission-freeze-signin-dialog.md | 37 +++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/docs/re/mission-freeze-signin-dialog.md b/docs/re/mission-freeze-signin-dialog.md index 261b742..97c92f4 100644 --- a/docs/re/mission-freeze-signin-dialog.md +++ b/docs/re/mission-freeze-signin-dialog.md @@ -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.