From dac9fbef626d586c570b274418a62a11742a2704 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 19 Aug 2026 13:13:33 +0000 Subject: [PATCH] docs: map where the autopilot's objective and action knowledge lives on the disc The autopilot doc's own problem #2 is that the pilot ignores the mission objective - its 300s run took no damage, killed one fighter, and watched REMAINING OB RISE from 004 to 011. So this surveys where that knowledge is. GP_TUTORIAL.pak yields the game's own list of what a player can do: BASIC CONTROLS, HEADS-UP DISPLAY, RADAR, SUPPLY AND SPECIAL MOVES, RADIO ORDERS, ADVANCED CONTROLS, with descriptions. Worth stating against what the pilot actually does: pilot.py and navigator.py use move and attack only. Resupply, special moves, radio orders to wingmen and advanced maneuvers are all unused, and two of them bear directly on open problems - resupply is the untested RETIRE mode, radio orders is an escort lever that flying skill does not substitute for. tables.pak is a name-resolved config seam: 79 IDXD objects, 6275 distinct field names, including DLG_MISSION_OBJECTIVE and DLG_STAGE_TITLE01..16 (so 16 stages). GP_MAIN_GAME_.pak holds 131 weapon\ tables, 113 unit\ and 64 message\ - the weapon ones being what problem #1 wants for real projectile speed and range. But the objective TEXT is not text: DLG_MISSION_OBJECTIVE = pdscr099.prt, a screen part, and the message tables resolve to face textures. All human-readable text in this game is rendered sprite art, which is why the UI work has been reading pixels all along. A per-mission objective table is an OCR job, not a table dump - so the cheaper and more actionable route is the runtime REMAINING OB counter, which is on the HUD and therefore in RAM. --- docs/re/autopilot-knowledge-sources.md | 102 +++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 docs/re/autopilot-knowledge-sources.md diff --git a/docs/re/autopilot-knowledge-sources.md b/docs/re/autopilot-knowledge-sources.md new file mode 100644 index 00000000..d0c142d6 --- /dev/null +++ b/docs/re/autopilot-knowledge-sources.md @@ -0,0 +1,102 @@ +# 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. + +## 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.