152704afeb
Checked first: no docs/re file mentions ArmsStatus, RangeFinder, Radar, Sight, Wing, NamePlate or ResourceTable. Only HudResource had been opened; the other fifteen records had not. The six IDXD entries of GP_MAIN_GAME_E2D.pak: two carry the 16-record HUD config, two the 13-record ObjectiveMarker_*/TutorialMarker_* set, one Face (52 portrait sprites), one ResourceTable. Between them they name 419 distinct asset paths -- the whole flight HUD -- with new subdirectory prefixes throughout (ArmsSt, ActvArm, RangeF, Marker, Manuva, Map, Speed, Radar, Sight, Wing, Hitmark, Lockon, Info). The decisive control uses the config's own exact path strings, so no guessing is left in the loop: 419 distinct .prt/.t32/.tbl values, ZERO resolve as a pak entry under 10 prefixes, and the four config filenames resolve to nothing either. The .t32 sprites certainly exist -- 574 T8aD in that pak. So the 2D pak is not addressed by name_hash of the name its config uses. This supersedes the earlier framing: the 28 'dangling' .prt names were never a missing-asset story; they are 28 of a set where none of the 419 resolves. ResourceTable is 58 positional fields = 29 pairs, alternating HudResource.tbl / HudMarkerResource.tbl, identical in all six language paks, with exactly one override at pair index 25 -- HudResource_S26.tbl. Reading: indexed by stage number minus 1, so index 25 is S26, the one stage with its own HUD config. Arithmetic exact, indexing unproven, not adopted. New structure doc, artefact and regenerator; the other seven regenerate byte-identical.
3.9 KiB
✅ 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); 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/.tblvalues; 0 resolve as a pak entry under 10 prefixes. The four config FILENAMES (HudResource.tbl,HudMarkerResource.tbl, and their_S26overrides) 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: 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),
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_hashof the config path. That is now the question. - What
HudMarkerResource.tblis — presumably the 13-record marker entry, but the filename does not resolve, so the pairing is by content, not by hash. Parameters(4 fields) andEnumerate_ObjectiveMarkers(11) are in the artefact but unread here.