From 418fbf30ed6bd210f56f13d076a5e5b43b7d7bd0 Mon Sep 17 00:00:00 2001 From: "Claude (auto)" Date: Thu, 27 Aug 2026 22:25:40 +0000 Subject: [PATCH] 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) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- docs/re/BACKLOG.md | 46 ++++++++++++++++++++++++++++++++ docs/re/structures/hud-config.md | 39 +++++++++++++++++++++++++++ 2 files changed, 85 insertions(+) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index d42adbd..bd83a34 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -5198,3 +5198,49 @@ rule, but a consistent one. 🟡 Not settled: what consumes an `AIID` at runtime (unchanged — the link from `UnitGroup.AIID` to a profile record is documented, the code that acts on the 20 parameters is not). + +--- + +## ✅ 2026-08-27 — the executable's own `PG*` HUD roster; the disc side was already owned + +Item (a), the five unowned base-solver blocks. Took the biggest, `sub_822215D0` +(205/206). Static only; no artefact changed. + +⚠️ **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. Had I stopped at the first +grep hit I 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. + +| | | +|---|---:| +| distinct `PG*` on the disc | **228** | +| the code block | **205** | +| in both | **200** | +| code-only | **5** | +| disc-only | **28** | + +`200 + 5 = 205`, `200 + 28 = 228` — 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 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* — lookup table, registration order or paint +list. The function body was not read. And four of the five surfaced blocks are +still unopened (`STAGE_RESULT`/`EX_OVERVIEW`; `g_mWorldViewProjection`/ +`NormalMap`; `Boss16Collision*`; `roh_n001_menu1_cam_pos`) — each grepped this +iteration and each appearing in **no** document but my own. diff --git a/docs/re/structures/hud-config.md b/docs/re/structures/hud-config.md index c1dc644..e12b7ca 100644 --- a/docs/re/structures/hud-config.md +++ b/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.