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:
Sylpheed RE agent
2026-08-27 14:27:38 +00:00
parent dc868e14c3
commit 4d9f7ce563
4 changed files with 135 additions and 2 deletions

View File

@@ -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),