Syplheed-Reborn/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`](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.

## 🔴 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](captures/stage02-briefing-crash.png)).

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