fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Claude (auto)
2026-08-27 22:25:40 +00:00
parent 9e2524d028
commit 418fbf30ed
2 changed files with 85 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
docs/re/BACKLOG.md
View File

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

39
docs/re/structures/hud-config.md
View File

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