4e9d7deeb8
Chasing more prefixes for the 419 HUD config paths would have been the same mistake twice, so this censuses the whole disc: harvest every plausible asset-name string from every archive (6027), hash each under the 16 known path prefixes, and ask per archive what fraction of its TOC that explains. idxd-container.md and idxd-tag-hash.md own the hash; neither says which archives are reachable by it. The result is bimodal. GP_TITLE 16/16, GP_PAUSE_MENU 11/11, GP_STAGE_CLEAR 44/44, GP_CHALLENGE 151/151, GP_MOVIE_THEATER 56/56, MiscBin 40/40, GP_GAMEOVER, GP_BUNK, GP_SYSTEM, GP_TUTORIAL and fonts are at 100%; tables.pak 78/79, GP_DIALOG 139/140, the six language paks 115/117; GP_MAIN_GAME_* 751/1119. Then the cliff: the six GP_MAIN_GAME_*2D.pak at 0 of 711 each, and GP_READY_ROOM at 6 of 1106 -- the largest UI pak on the disc, not previously noted anywhere. Eleven paks at 100% in the same run is the control that makes 0.0% a finding rather than a failed guess. So the 419 HUD paths are not missing assets: nothing in the 2D paks is reachable by name from the disc's own strings at all. Those TOC keys hash names that are not written anywhere readable. Also refuted first: the 419 values under 13 name transformations, every one scoring 0 against the E2D 711 and against all 16630 entries. Not settled: what those names are. The lever left is the hash's shape -- the top byte is the character-sum checksum -- but that needs a name corpus the disc does not contain. New structure doc, artefact and regenerator; the other eight regenerate byte-identical.
3.5 KiB
✅ Which archives the disc can name — and the two it cannot
The previous pass found that 0 of 419 in-game HUD config paths hash to a pak entry (hud-config). Chasing more prefixes would have been the same mistake twice, so this censuses the whole disc instead: harvest every plausible asset-name string from every archive, hash each under the 16 known path prefixes, and ask per archive what fraction of its TOC that explains.
idxd-container.md and idxd-tag-hash.md own the hash (name_hash = a
checksum byte over a 24-bit modular value, case-insensitive, distinct from
tag_hash); neither says which archives are reachable by it. Artefact
../data/archive-naming.txt, regenerator tools/re-capture/archive_naming.py
(6 027 candidate names × 16 prefixes).
The result is bimodal
| archive | entries | named | |
|---|---|---|---|
GP_TITLE, GP_PAUSE_MENU, GP_STAGE_CLEAR, GP_CHALLENGE, GP_MOVIE_THEATER, GP_GAMEOVER, GP_BUNK, GP_SYSTEM, GP_TUTORIAL, MiscBin, fonts |
2–151 | all | 100 % |
tables.pak |
79 | 78 | 98.7 % |
GP_DIALOG |
140 | 139 | 99.3 % |
deu/eng/esp/fra/ita/jpn.pak |
117 | 115 | 98.3 % |
GP_SAVE_LOAD / GP_LEADERBOARD / GP_OPTIONS / GP_MISSION_LOG |
24–108 | 91–94 % | |
GP_MAIN_GAME_{D,E,F,I,J,S} |
1 119 | 751 | 67.1 % |
GP_DEBRIEFING_PILOTLOG |
234 | 78 | 33.3 % |
GP_HANGAR_ARSENAL |
1 538 | 347 | 22.6 % |
DefTables |
1 465 | 130 | 8.9 % |
GP_MISSION_SELECT |
88 | 22 | 25.0 % |
GP_READY_ROOM |
1 106 | 6 | 0.5 % |
GP_MAIN_GAME_{D,E,F,I,J,S}2D |
711 each | 0 | 0.0 % |
sound.pak |
9 519 | 1 | 0.0 % (a separate format — sound-pak-contents) |
🔑 The six 2D paks are at exactly 0.0 %, all six, 711 entries each — while eleven menu paks are at 100 % by the same method in the same run. That is the control that makes it a finding rather than a failed guess: the method works, and these archives are outside it.
🔑 GP_READY_ROOM is a second such archive — 1 106 entries, 6 named.
Not previously noted anywhere in docs/re/; it is the largest UI pak on the
disc and its names are as unreachable as the 2D paks'.
What that means for the 419
The in-game HUD's asset paths are not "missing". Nothing in the 2D paks is reachable by name from the disc's own strings, whatever the extension. So the 2D and READY_ROOM TOC keys are hashes of names that are not written anywhere we can read — built by the tool chain, or from a string the executable composes, or from a name list held outside these archives.
🧪 Also refuted here — 13 name transformations
Before the census, the 419 config values were re-hashed under 13 rewrites:
as-is, forward slashes, basename, basename without extension, without extension,
uppercased, .rat substituted, 2d\/eng\/hud\/GP_MAIN_GAME_2D\ prefixed,
and first-directory stripped. Every one scored 0, both against the E2D pak's
711 entries and against all 16 630 entries on the disc.
🟡 Not settled
- What names the 2D and
GP_READY_ROOMTOCs actually hash. The one lever left is the hash's own shape — the top byte is the character-sum checksum, so any candidate is cheap to reject — but that needs a name corpus this disc does not contain. - Why
DefTables(8.9 %) andGP_HANGAR_ARSENAL(22.6 %) sit in the middle; probably just that most of their entries are tables referenced by records this harvest does not treat as filenames. Not chased.