b7653216d6
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_<lang>.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.
103 lines
5.0 KiB
Markdown
103 lines
5.0 KiB
Markdown
# 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_<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.
|