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.

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.