# 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`](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" | ([lessons](captures/tutorial-lesson-list.png), [descriptions](captures/tutorial-lesson-descriptions.png)) 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`](../../MEMORY.md)) 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_.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 `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 a unit type (`HP_ID`, `HP_CLASS`, `Mine`), not an input map. What is known (`RT` accelerate, `LT` brake, `RB` fire) 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 OB` in RAM β€” the next item.