418fbf30ed
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