d1368c12db
Correction first. stage-numbering-and-player-craft.md called S24-S29 'story' and reported 22 story stages. challenge-mission-gate.md OWNS that split and already had it: S01-S16 story, S18-S23 tutorials, S24-S29 challenge. A third confirmation fell out of this iteration: AUTO_SETTINGS names stage01..16_settings.tbl, tutorial01..06 and challenge01..06, and its field tags are 1-16, 18-23, 24-29 -- the shipped stage numbers exactly. The campaign is 16 story missions, not 22. AUTO_SETTINGS and IGNORE are likewise already owned by isl-condition-builtins.md, so nothing there was new either. What is new: the 11 marker records hud-config.md listed as unread. 12 named fields each, portable HUD data. Colour is ARGB, three per marker -- objectives red 0xFFFF0000, guard/waypoint green 0xFF20FF20, Acropolis/tanker cyan 0xFF00FFFF, sub-objective yellow 0xFFFFFF00, and every TutorialMarker_* amber 0xFFFFA010. Each carries a Normal sprite and an Emphasis part with optional Sub companions; HPGauge 0/1/2; RadarCursorType Circle/Rectangle/blank; BlinkCycle 0x800 on all eleven. TutorialTarget is Yes on exactly the five TutorialMarker_* and No on the six ObjectiveMarker_*. Parameters binds the roles: TargetMarker -> ObjectiveMarker_Target, HelpMarker -> ObjectiveMarker_SubObjective, TutoTargetMarker -> TutorialMarker_Target, plus ReloadDispTime 0.1. Enumerate_ObjectiveMarkers is the 11-name roster. Artefact +13 lines / 0 deletions; the other nine regenerate byte-identical.
112 lines
5.7 KiB
Markdown
112 lines
5.7 KiB
Markdown
# ✅ 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](mission-script-manifest.md)); 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` / `.tbl` values; 0 resolve as a pak entry**
|
||
> under 10 prefixes. The four config FILENAMES (`HudResource.tbl`,
|
||
> `HudMarkerResource.tbl`, and their `_S26` overrides) 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](mission-script-manifest.md#-the-other-six-values-do-not-resolve--with-a-working-control):
|
||
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](stage-numbering-and-player-craft.md)),
|
||
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**.
|
||
|
||
## ✅ The objective / tutorial MARKER records
|
||
|
||
`hud-config.md` listed these as "in the artefact but unread". Opened now — and
|
||
they are portable HUD data, 11 records of **12 named fields** each:
|
||
|
||
```
|
||
ObjectiveMarker_Target ColorNormal 0xFFFF0000 Emph1 0xFFFF0000 Emph2 0xFF800000
|
||
Normal pgmark_ob.t32 NormalSub pgmark_ob_s.t32
|
||
Emphasis pgmark_em_ob.prt EmphasisSub pgmark_em_ob_s.prt
|
||
HPGauge 2 HPGaugeSub 0 BlinkCycle 0x800
|
||
RadarCursorType (blank) TutorialTarget No
|
||
```
|
||
|
||
* **Colour is ARGB**, three per marker: `ColorNormal`, `ColorEmphasis1`,
|
||
`ColorEmphasis2`. Objectives are **red** `0xFFFF0000`, guard/waypoint **green**
|
||
`0xFF20FF20`, Acropolis/tanker **cyan** `0xFF00FFFF`, sub-objective **yellow**
|
||
`0xFFFFFF00`, and every `TutorialMarker_*` is **amber** `0xFFFFA010`.
|
||
* Each marker carries a `Normal` sprite and an `Emphasis` part, optionally with
|
||
`…Sub` companions; `HPGauge` is 0 / 1 / 2; `RadarCursorType` is `Circle`
|
||
(Acropolis, tanker), `Rectangle` (guard) or blank; `BlinkCycle` is `0x800`
|
||
on all eleven.
|
||
* `TutorialTarget` is `Yes` on exactly the five `TutorialMarker_*` records and
|
||
`No` on the six `ObjectiveMarker_*` — the two families are otherwise the same
|
||
shape.
|
||
|
||
**`Parameters` (4 fields) binds the roles**:
|
||
|
||
```
|
||
TargetMarker ObjectiveMarker_Target
|
||
HelpMarker ObjectiveMarker_SubObjective
|
||
TutoTargetMarker TutorialMarker_Target
|
||
ReloadDispTime 0.1
|
||
```
|
||
|
||
**`Enumerate_ObjectiveMarkers`** is the 11-name roster of the set — the same
|
||
shape as the `Enumerate_Squadrons` record [unit-group-table](unit-group-table.md)
|
||
uses.
|
||
|
||
⚠️ `pgmark_em_ob_s.prt` here is one of the 28 names
|
||
[archive-naming](archive-naming.md) shows resolving nowhere — consistent with
|
||
the namespace finding, not a missing asset.
|
||
|
||
## 🟡 Not settled
|
||
|
||
* How the 2D pak's 574 T8aD and 130 RATC entries *are* addressed, if not by
|
||
`name_hash` of the config path. That is now the question.
|
||
* What `HudMarkerResource.tbl` is — presumably the 13-record marker entry, but
|
||
the filename does not resolve, so the pairing is by content, not by hash.
|
||
* ~~`Parameters` and `Enumerate_ObjectiveMarkers` unread.~~ **Opened above.**
|