tools: repair launch_mission.sh; Stage 02 now reaches the briefing and stops there

Finding REMAINING OB in RAM means getting to the escort stage, and
launch_mission.sh exists for exactly that. It carried three of the dead patterns
this session has been clearing: six vgamepad calls (the command no longer exists,
so the entire scripted route pressed nothing), the XUID E0300000EFBEA3D4 which
has no profile behind it and therefore opens the sign-in dialog that swallows
every keystroke, and the emulator's stdout going to /dev/null. wait_flight.sh had
a fourth, in the tap that skips the launch cinematic.

Fixed, the route works far past where it used to stop: boot -> title -> LOAD GAME
-> slot 01 -> READY ROOM -> TAKE OFF -> the Stage 02 briefing map, with ACROPOLIS
labelled on it.

And it stops there: 384 dumps at PC 0x82307128 and no flight HUD within 300s. The
briefing is still animating (two shots a minute apart differ by RMSE 2986), so
the emulator is not frozen - flight simply never starts.

One discriminator worth recording: the TUTORIAL reaches flight and has run
completely crash-free, while this path crashes during the briefing, which is
where the stage content loads. That is consistent with the cache-flush shape the
crash has always had, and points at WHAT is being loaded rather than at how far
the navigation gets.

REMAINING OB is therefore still not found - the mission was never entered.
This commit is contained in:
Sylpheed RE agent
2026-08-19 13:27:46 +00:00
parent dac9fbef62
commit 800af73dde
3 changed files with 50 additions and 9 deletions

View File

@@ -91,6 +91,36 @@ the pilot is making progress; and the four unused taught capabilities — radio
orders, resupply, special moves, advanced maneuvers — are the levers it currently
does not pull.
## 🔴 The runtime counter needs Stage 02, and Stage 02 stops at the briefing
`REMAINING OB` was measured in the escort stage, so finding it in RAM means
getting there. `launch_mission.sh` exists for exactly that — "drive into the
Stage 02 mission from save slot 01" — and it had **three** of the dead patterns
this session has been clearing out:
* six `vgamepad` calls (the command no longer exists, so the whole scripted route
pressed nothing);
* `--logged_profile_slot_0_xuid=E0300000EFBEA3D4`, a XUID with no profile behind
it, which opens the sign-in dialog that swallows every keystroke;
* the emulator's stdout to `/dev/null`.
Plus one more in `wait_flight.sh`, which taps Ⓐ through the launch cinematic.
With those fixed the route works far past where it used to stop: boot → title →
LOAD GAME → slot 01 → READY ROOM → TAKE OFF → the **Stage 02 briefing map**, with
ACROPOLIS labelled on it ([capture](captures/stage02-briefing-crash.png)).
**And it stops there.** 384 dumps at `PC: 0x82307128`, and `wait_flight.sh` times
out after 300 s without a flight HUD. The briefing keeps animating (two shots a
minute apart differ, RMSE 2986), so the emulator is not frozen — flight simply
never starts.
Worth noting as a discriminator: the **tutorial** reaches flight and has run
completely crash-free, while this path crashes during the briefing — which is
where the stage content loads. That is consistent with the cache-flush shape the
crash has always had, and it says the difference between the two paths is *what
is being loaded*, not how far the navigation gets.
## Not settled
* ❔ The button→action mapping. `tables.pak` has an `ID=Control` object but it is