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.
67 lines
3.5 KiB
Markdown
67 lines
3.5 KiB
Markdown
# ✅ 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](hud-config.md)). 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](sound-pak-contents.md)) |
|
||
|
||
🔑 **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_ROOM` TOCs 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 %) and `GP_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.
|