Sylpheed/docs/re/autopilot-knowledge-sources.md

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"

(lessons, descriptions)

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 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).

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.