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.
6.6 KiB
Where the autopilot's missing knowledge lives on the disc
Status: 🟡 this is a map, not the knowledge itself — it says which files hold the mission objectives and the player's action set, and what form they take. ✅ the tutorial's capability list is extracted. 🔴 objective text is not stored as text anywhere, which is the finding that shapes the next step.
autopilot-memory-driven.md ranks its own open
problems, and #2 is "which targets count — REMAINING OB is the mission's own
objective counter". A pilot that flies well but ignores the objective cannot
finish a mission, and the 300 s run there proves it: no damage taken, one kill,
and REMAINING OB rising from 004 to 011 as waves spawned. So before more
control tuning, this is where the objective and action data actually is.
✅ The player's action set, from the tutorial
GP_TUTORIAL.pak is two RATC bundles (~5.7 MB each, one per language) holding
the lesson-select menu. Decoding its 74 textures gives the game's own list of
what a player can do:
| lesson | description |
|---|---|
| BASIC CONTROLS | "Learn how to move and attack" |
| HEADS-UP DISPLAY | "Learn how to use the HUD" |
| RADAR | "Learn how to use radar" |
| SUPPLY AND SPECIAL MOVES | "Learn how to resupply and execute special moves" |
| RADIO ORDERS | "Learn how to radio orders to your wingmen" |
| ADVANCED CONTROLS | "Learn advanced maneuvers for experienced players" |
That is worth stating plainly against what the pilot currently does. pilot.py
and navigator.py use move and attack only. Four of the six taught
capabilities — resupply, special moves, radio orders to wingmen, advanced
maneuvers — are unused, and two of them are directly relevant to open problems:
resupply is the untested RETIRE mode, and radio orders is a lever on
escort missions that no amount of flying skill substitutes for.
The _mnv* / _turn180 morph poses already decoded in the ship meshes
(saber-texture-investigation) are presumably the "special
moves" the tutorial names.
✅ tables.pak is the config seam, and it is name-resolved
79 IDXD objects, 6 275 distinct field names, all human-readable. Examples of what is in there:
DLG_MISSION_OBJECTIVE,DLG_STAGE_TITLE01…DLG_STAGE_TITLE16— so the game has 16 stages and a per-stage title, indexed;CLEAR_TIME_RANKING,ClearTimes,CLEARED,ConditionToDevelop;- whole screen layouts (
PATH/BASE/MAIN/FONT_*per screen); - a 5 801-field sound table (
BGM_001…,JNGL_001…,STAGES = Static.slb).
GP_MAIN_GAME_<lang>.pak is the other half: 1 119 objects, 308 name-resolved —
131 weapon\*.tbl, 113 unit\*.tbl, 64 message\*.tbl. The weapon
tables are the ones autopilot-memory-driven.md problem #1 wants for real
projectile speed and range instead of hard-coded constants.
🔴 The objective text is not text
The obvious hope — read each stage's objective string statically and hand the pilot a per-mission goal — does not work as stated:
DLG_MISSION_OBJECTIVE = pdscr099.prt
DLG_STAGE_TITLE03 = pzscr02.prt
Those are .prt screen parts, not strings. And the message\* tables are
not prose either — CharacterCONTROLLERA resolves to face textures
(pjf035_A01.t32), i.e. portraits.
That is consistent with everything else this project has found: all human-readable text in this game is rendered sprite art, which is why the UI work has been reading pixels rather than strings all along. A per-mission objective table is therefore an OCR job over screen parts, not a table dump.
What this implies for the next step
Reading the objective text statically is possible but expensive, and it only
yields strategy — a human-readable sentence. What actually closes a mission is
the runtime counter: REMAINING OB is on the HUD, so it is in guest RAM, and
finding it converts "shoot whatever is nearest" into "shoot what closes the
mission". That is autopilot-memory-driven.md problem #2 and it is the cheaper
and more actionable of the two.
Per-mission strategy then has a natural shape: the static tables say which stage and how many objective targets it has; the runtime counter says whether 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
vgamepadcalls (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).
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.pakhas anID=Controlobject but it is a unit type (HP_ID,HP_CLASS,Mine), not an input map. What is known (RTaccelerate,LTbrake,RBfire) came from measurement, not the disc. - ❔ Whether the in-flight tutorial lessons can be driven to demonstrate each action — they would be the cheapest ground truth for the remaining inputs, and the tutorial is now reliably reachable.
- ❔
REMAINING OBin RAM — the next item.