re: the executable's own PG* HUD roster; the disc side was already owned

Took the biggest of the five unowned base-solver blocks, sub_822215D0 (205/206).

Grep-and-READ first, and it paid.  PGHUD* pointed at mission-script-manifest.md,
which documents HudResource's 24 fields -- but hud-config.md owns the whole
family: all 16 records in the six GP_MAIN_GAME_*2D paks, 419 distinct asset
paths.  Stopping at the first grep hit would have "discovered" a documented table
for the second time in three iterations.

Control: counting PG* field names straight off the paks reproduces that
document's own numbers exactly -- Sight 35, Radar 29, Marker 27, Wing 23,
Manuva 15; HudResource 23 PG* + HUD_RES_FONT = its stated 24.

The increment: the executable carries its own roster.  sub_822215D0 reads a
205-name block at base 0x820A0000, 205/205 PG*-prefixed, zero partials -- PGHUD
77, PGTARGET 31, PGGAUGE 25, PGMANUVA 16, PGMARK 12, PGWARNING 10, PGMARKTGT 9.
The disc has 228 distinct PG* names; 200 are in both, 5 code-only, 28 disc-only.
200 + 5 = 205 and 200 + 28 = 228, closing both ways.

Four of the five code-only names are printf families whose stem is a disc field
(PGHUD_HIT_NUM_EFF%d, PGHUD_HIT_NUM_RED%d, PGREMAIN_NUM%d, PGTIMER_NUM%d) and all
four stems sit in the disc-only 28: the code builds indexed instance names from a
base name the table declares.  After pairing, the residual is one code-only name
(PGMANUVA_EFF0) and 24 disc-only ones, listed in the doc.

Not settled: what the block is for -- the function body was not read.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

docs/re/structures/hud-config.md

@@ -109,3 +109,42 @@ the namespace finding, not a missing asset.
 * 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` and `Enumerate_ObjectiveMarkers` unread.~~ **Opened above.**
+
+## ✅ The executable's own `PG*` block — `sub_822215D0` (2026-08-27)
+
+Found by the base-solver ([[player-tuning-tables]]); reproduce from
+[`../data/name-block-bases.txt`](../data/name-block-bases.txt) (the
+`sub_822215D0` section) against `hud_config.py`'s record dump.
+
+✅ **The disc side above is confirmed independently.** Counting `PG*`-prefixed
+field names straight off the paks gives `Sight` 35, `Radar` 29, `Marker` 27,
+`Wing` 23, `Manuva` 15 — **the same numbers this document already states**, and
+`HudResource` 23 `PG*` + `HUD_RES_FONT` = its documented 24. A re-derivation
+that lands on the same counts is the control for what follows.
+
+🔑 **What this document did not say: the executable carries its own roster.**
+`sub_822215D0` reads a **205-name** block at base `0x820A0000` — **205/205 are
+`PG*`-prefixed, zero partials** — led by `PGHUD` 77, `PGTARGET` 31, `PGGAUGE` 25,
+`PGMANUVA` 16, `PGMARK` 12, `PGWARNING` 10, `PGMARKTGT` 9.
+
+| | |
+|---|---:|
+| distinct `PG*` names **on the disc** (across all 16 records) | **228** |
+| the code block | **205** |
+| in both | **200** |
+| code-only | **5** |
+| disc-only | **28** |
+
+`200 + 5 = 205` and `200 + 28 = 228` — the arithmetic closes both ways.
+
+⚠️ **Four of the five "code-only" names are printf families whose stem is a disc
+field**: `PGHUD_HIT_NUM_EFF%d`, `PGHUD_HIT_NUM_RED%d`, `PGREMAIN_NUM%d`,
+`PGTIMER_NUM%d` — and `PGHUD_HIT_NUM_EFF`, `PGHUD_HIT_NUM_RED`, `PGREMAIN_NUM`,
+`PGTIMER_NUM` are all four sitting in the disc-only 28. **The code builds indexed
+instance names from a base name the table declares.** Pair them off and the real
+residual is **one** code-only name — `PGMANUVA_EFF0` — and **24** disc-only ones
+(`PGHUD_LOCATOR`, `PGHUD_CAMERA`, `PGHUD_PITCH_*`, `PGHUD_YAW*`, `PGLOCKON`, …),
+i.e. elements the table names that this particular function never mentions.
+
+🟡 What the block is *for* is not settled: whether it is a lookup table, a
+registration order, or a paint list. The function was not read.