# ✅ The in-game HUD configuration — 16 records, and a per-stage resource table

The `GP_MAIN_GAME_*2D.pak` archives carry **six IDXD entries** that are the
in-game counterpart of `tables.pak`'s menu configs. Only `HudResource` had been
opened ([mission-script-manifest](mission-script-manifest.md)); the other
**fifteen** records had not. No `docs/re/` file mentions `ArmsStatus`,
`RangeFinder`, `Radar`, `Sight`, `Wing`, `NamePlate` or `ResourceTable` —
checked before writing this. Artefact `../data/hud-config.txt` (697 lines),
regenerator `tools/re-capture/hud_config.py`.

| entry | records |
|---|---|
| `0x10b9d584`, `0x4abcfc43` | **16** — `ArmsStatus`, `Map`, `ArmsItem`, `RangeFinder`, `Marker`, `Manuva`, `Number`, `HudResource`, `NamePlate`, `ActiveArm`, `Information`, `Wing`, `ArmsItemFile`, `Radar`, `Speed`, `Sight` |
| `0x927b29f8`, `0xccb12a6b` | **13** — `ObjectiveMarker_{Acropolis,SubObjective,Guard,WayPoint,Tanker,Target}`, `TutorialMarker_{…}`, `Enumerate_ObjectiveMarkers`, `Parameters` |
| `0x59ecbedd` | `Face` — 52 positional `pjf001_*.t32` portrait sprites |
| `0x87fd28c0` | `ResourceTable` — 58 positional entries |

Between them these name **419** distinct asset paths. That is the whole flight
HUD: the arms panel (`ArmsStatus` 16, `ActiveArm` 13, `ArmsItemFile` 59), the
range finder (10), the target/lock markers and their HP-gauge strips (`Marker`
27), the manoeuvre gauge (`Manuva` 15), the radar (29), the reticle (`Sight`
35), the wingman panel (`Wing` 23), nameplates (60), speed (9), and the digit
strips (`Number`, `%d`-templated: `pghud_speed_num%d.t32`, `pgtimer_num%d.t32`,
`pglockon_%d.t32`).

🔑 The values carry **subdirectory prefixes** the corpus had not seen —
`ArmsSt\`, `ActvArm\`, `RangeF\`, `Marker\`, `Manuva\`, `Map\`, `Speed\`,
`Radar\`, `Sight\`, `Wing\`, `Hitmark\`, `Lockon\`, `Info\`.

## 🧪 The whole in-game HUD is NOT name-hash addressed

Taking the config's **own exact path strings** — no guessing left in the loop:

> **419 distinct `.prt` / `.t32` / `.tbl` values; 0 resolve as a pak entry**
> under 10 prefixes. The four config FILENAMES (`HudResource.tbl`,
> `HudMarkerResource.tbl`, and their `_S26` overrides) resolve to nothing
> either.

The `.t32` sprites certainly exist — the E2D pak holds **574 T8aD** entries. So
the 2D pak's contents are simply **not addressed by `name_hash` of the name the
config uses**, and that closes the previous iteration's puzzle properly: the 28
"dangling" `.prt` names were never a missing-asset story, they are 28 of a set
where **none** of the 419 resolves.

⚠️ This supersedes the framing in
[mission-script-manifest](mission-script-manifest.md#-the-other-six-values-do-not-resolve--with-a-working-control):
the right statement is not "these five/28 are absent" but "**the in-game asset
namespace is not the archive namespace**".

## ✅ `ResourceTable` — a per-stage HUD config table

58 positional fields = **29 pairs**, alternating
`HudResource.tbl` / `HudMarkerResource.tbl`. Exactly one pair differs — index
**25**, which reads `HudResource_S26.tbl` / `HudMarkerResource_S26.tbl`.
**Identical in all six language paks.**

🟡 The reading: the table is indexed by **stage number − 1**, so 29 entries
cover S1…S29 (the numbering [that runs to S29 with S17 absent](stage-numbering-and-player-craft.md)),
and index 25 is **S26 — the one stage with its own HUD configuration**. The
arithmetic is exact and the `_S26` suffix names the same stage, but nothing here
proves the indexing, so this is **a reading, not adopted**.

## 🟡 Not settled

* How the 2D pak's 574 T8aD and 130 RATC entries *are* addressed, if not by
  `name_hash` of the config path. That is now the question.
* What `HudMarkerResource.tbl` is — presumably the 13-record marker entry, but
  the filename does not resolve, so the pairing is by content, not by hash.
* `Parameters` (4 fields) and `Enumerate_ObjectiveMarkers` (11) are in the
  artefact but unread here.