re: the variant reading is refuted; HudResource is the in-game screen config

Censused the 32 bundle-less in-game .prt names with the 68 as control:
4 of 32 appear as an element of some 2D bundle, against 58 of 68.
Being an element is normal for a part that exists; these are not
elements either.  Last iteration's 'not adopted' reading is refuted.
28 names are neither a bundle nor an element.

They are not unreferenced: a HudResource record inside the 2D paks' own
IDXD entries names them -- the in-game screen config, parallel to
tables.pak for menus.  GP_MAIN_GAME_E2D.pak has 6 IDXD entries; two
carry HudResource (24 named fields) beside ArmsStatus, Map, ArmsItem,
RangeFinder, Marker, Manuva, Number; two more carry the
ObjectiveMarker_*/TutorialMarker_* set.

Its values carry subdirectory prefixes -- Hitmark\, Lockon\ -- which my
hand-written prefix list never had.  So I rebuilt the negative the right
way round: harvested every IDXD field value containing a backslash, kept
the 60 commonest directories, and re-swept.  241/376 with the hand list;
241 with hand + harvested -- zero new resolutions.  After the language\
miss, this is the closure that counts: the prefix list came from the
disc, not from me.

Still open: whether the 28 are cut features or assembled at runtime from
sprites.  Nothing static separates those two.

Artefact +45 lines / 0 deletions; the other six regenerate
byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-27 14:42:20 +00:00
parent 1132d95227
commit dcf4945db5
4 changed files with 160 additions and 4 deletions

View File

@@ -191,8 +191,55 @@ beside `pgmanuva_eff0`, `pgtarget_*` — which reads as "a variant declared insi
a parent bundle rather than a bundle of its own". **A reading, not adopted**;
nothing here shows the variant mechanism.
**Still not settled**: those 32, and `pgmsg_update`, which is absent from every
route tried. What is
### ❌ The "variant inside a parent bundle" reading is REFUTED
Censused the 32, with the 68 as the control:
| | appear as an ELEMENT of some 2D bundle |
|---|---:|
| the 32 **without** their own bundle | **4** |
| **control** — the 68 **with** one | **58** |
Being an element is normal for a part that exists (58/68); the bundle-less ones
are not elements either. **28 names are neither a bundle nor an element.**
### 🔑 `HudResource` — the in-game counterpart of `tables.pak`
The 28 are not unreferenced: they are named by a **`HudResource`** record inside
the 2D paks' *own* IDXD entries — the in-game screen config, exactly parallel to
`tables.pak` for menus. `GP_MAIN_GAME_E2D.pak` has 6 IDXD entries; two carry
`HudResource` (24 named fields) beside `ArmsStatus`, `Map`, `ArmsItem`,
`RangeFinder`, `Marker`, `Manuva`, `Number`, and two more carry the
`ObjectiveMarker_*` / `TutorialMarker_*` set.
```
HUD_RES_FONT DFSOGE5.TTC PGHUD_LOCATOR pghud_target_locator.prt
PGHUD_HITMARK Hitmark\pghud_hitmark.prt PGLOCKON Lockon\pglockon.t32
PGHUD_OBREMAINDER Hitmark\pghud_OBremainder.prt PGTIMER pgtimer.prt
PGHUD_SUBTARGET pghud_subtarget.prt PGREMAINING pgremaining.prt
… plus the pitch ladder / yaw / cockpit `.t32` sprites
```
🔑 Its values carry **subdirectory prefixes**`Hitmark\`, `Lockon\` — which my
hand-written prefix list never had.
### 🧪 Control — a prefix list harvested from the data adds nothing
Took every `IDXD` field value containing a backslash, kept the 60 commonest
directories (`Sight\`, `Radar\`, `Marker\`, `Wing\`, `ArmsSt\`, `Manuva\`,
`Hitmark\`, `Lockon\`, the `<lang>\Voice\` and `<lang>\etc\` trees …) and
re-ran the sweep. **241 of 376 with the hand list; 241 with hand + harvested.**
Zero new resolutions. After the `language\` miss, this is the negative built the
right way round: the prefix list came from the disc, not from me.
**So 28 `.prt` names are referenced by the in-game configs and exist nowhere on
the disc** — not an entry, not a bundle, not an element, under any prefix the
data itself supplies. A coherent HUD family: `pghud_range_*`, `pghud_wing_*`,
`pghud_arms_active*`, `pgtarget_*`, `pgmanuva_eff2/3`, `pggauge_*_eff1`,
`pgtimer`, `pgremaining`, `pgmsg_update`.
**Still not settled**: whether the 28 are cut features or built at runtime from
sprites. Nothing static can separate those two. What is
now settled is that they are **not** pak entries while 241 of their siblings are,
and that `pgmsg_update` is the odd one out even among them.