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.