re: an embedded .prt part is a top-level RATC bundle, addressed by its element prefix
Read first: ui-rat-layout.md OWNS the RATC stack and already documents the 60-byte element declaration table and 'one bundle = one (context x language) build of that screen'. What it does not say is how a part is addressed when it is NOT a pak entry. The elements of one bundle share a common name prefix, and that prefix is the part name. GP_MAIN_GAME_E2D.pak has 130 bundles with 114 distinct element prefixes -- pgmenu_btn00, pghud_wing, pgface, pghud_range, pgmanuva_eff0 -- exactly the in-game part names. The 100 in-game-only .prt names match a 2D bundle prefix 68 times; the control, the 241 shipped parts, matches ZERO. The two families are disjoint on the test. 13 shipped parts match a bundle prefix in their own screen pak, which is the expected shape. Four of the five mission banners land here: pgmsg_start.prt is E2D bundle 0x89fac252, a one-element bundle declaring pgmsg_start_sub.rat; likewise _end_, _failed_, _restart_. pgmsg_update has no bundle at all, consistent with having no _sub.rat. 32 in-game names still have no 2D bundle. They cluster into families whose base name is a bundle, reading as a variant declared inside a parent bundle -- a reading, not adopted. Artefact +38 lines / 0 deletions; the other six regenerate byte-identical.
This commit is contained in:
@@ -827,6 +827,33 @@ unknown, what evidence exists, and what the first step would be. Move an item in
|
||||
field; the stat keys in records not opened here (`MegaTons`, `BulletLimit`,
|
||||
`CrewCount`, `HP_CLASS`); why the roster lists 59 of 131.
|
||||
|
||||
* ✅ **(2026-08-27) AN EMBEDDED PART IS A TOP-LEVEL RATC BUNDLE, ADDRESSED BY ITS
|
||||
ELEMENT PREFIX — 68 of 100, against 0 of 241 for the shipped parts.**
|
||||
[structures/mission-script-manifest](structures/mission-script-manifest.md),
|
||||
artefact `data/prt-parts.txt` (+38 lines, 0 deletions — purely additive).
|
||||
Read first: `ui-rat-layout.md` OWNS the RATC stack and already documents the
|
||||
60-byte element declaration table at `0x20` and "one bundle = one
|
||||
(context x language) build of that screen". What it does not say is how a part
|
||||
is addressed when it is NOT a pak entry.
|
||||
🔑 **The elements of one bundle share a common name prefix, and that prefix is
|
||||
the part name.** `GP_MAIN_GAME_E2D.pak` = **130 bundles, 114 distinct element
|
||||
prefixes** — `pgmenu_btn00`, `pghud_wing`, `pgface`, `pghud_range`,
|
||||
`pgmanuva_eff0`, i.e. exactly the in-game part names.
|
||||
🧪 **The 100 in-game-only `.prt` names match a 2D bundle prefix 68 times; the
|
||||
CONTROL — the 241 shipped parts — matches ZERO.** The two families are disjoint
|
||||
on the test. (13 shipped parts match a bundle prefix in their OWN screen pak,
|
||||
which is the expected shape.)
|
||||
Four of the five mission banners land here: `pgmsg_start.prt` is E2D bundle
|
||||
`0x89fac252`, a ONE-element bundle declaring `pgmsg_start_sub.rat`; likewise
|
||||
`_end_` `0x92239624`, `_failed_` `0xc01017fc`, `_restart_` `0x606fef65`.
|
||||
**`pgmsg_update` has no bundle at all**, consistent with having no `_sub.rat`.
|
||||
🟡 **32 in-game names still have no 2D bundle.** They cluster into families
|
||||
whose BASE name is a bundle — `pghud_wing_act_*` beside `pghud_wing`,
|
||||
`pghud_range_*` beside `pghud_range`, `pgmanuva_eff1..3` beside
|
||||
`pgmanuva_eff0`, `pgtarget_*` — reading as "a variant declared inside a parent
|
||||
bundle". **A reading, not adopted**; nothing here shows the variant mechanism.
|
||||
🟡 Still open: those 32, and `pgmsg_update`, absent from every route tried.
|
||||
|
||||
* ✅ **(2026-08-27) WHO REFERENCES A `.prt` DECIDES WHETHER IT SHIPS — menu parts
|
||||
are named and shipped, in-game parts are embedded. 0 counterexamples in 376.**
|
||||
[structures/mission-script-manifest](structures/mission-script-manifest.md),
|
||||
|
||||
Reference in New Issue
Block a user