Sylpheed/docs/re/structures/mission-script-manifest.md

✅ Stage\script.tbl — the 11 non-MISSION fields, and where they point

mission-script-ssb owns this manifest and names its 40 fields; it never read the 11 that are not MISSION<n> = StageNN.ssb. This does, and follows each value into the archives. Artefact ../data/script-manifest.txt, regenerator tools/re-capture/script_manifest.py.

DIALOG_MESSAGE        MissionDialogMessage.tbl
DIALOG_LOCAL_STRING   MissionDialog_local_string.tbl
FONT                  dat\fonts.pak+HGRGE00.TTF     FONT_SIZE 15
TEXT_POS              128,128,16                    TEXT_LINES 30
MISSION_START_PRT     pgmsg_start.prt      MISSION_END_PRT      pgmsg_end.prt
MISSION_UPDATE_PRT    pgmsg_update.prt     MISSION_FAILED_PRT   pgmsg_failed.prt
MISSION_RESTART_PRT   pgmsg_restart.prt

Two sibling records in the same file, also unread until now: GP_TEST (PATH = dat\GP_TEST\ — a debug archive that is not on the disc) and TEXTS (FONT_SIZE 33, TEXT_LINES 3, TEXT_POS 296,565,39 — a second, larger text style beside SCRIPTS's own 15/30/128,128,16).

❌ CORRECTION (2026-08-27, same day) — the dialogue table was ALREADY KNOWN,

and one "not found" was a FALSE NEGATIVE

This page announced message\MissionDialogMessage.tbl as a find. ixud-localised-text owns it and already states that S02_P1_OBJECTIVE and friends "are record names in an IDXD map, message\MissionDialogMessage.tbl, whose positional fields list the lowercase per-line IXUD names", and that "*_GRAPH is the odd one: a single named field holding a texture, pgmsg_stg02_1.t32". I grepped the manifest doc and not the text doc. Third overclaim in four days.

Worse, the sweep's headline negative was wrong. MissionDialog_local_string.tbl DOES resolve — as language\MissionDialog_local_string.tbl, IXUD, in all six GP_MAIN_GAME_* paks. My 33 prefixes omitted language\, which is exactly the convention ixud-localised-text.md records for language paks. A prefix sweep is only as good as its prefix list, and the list should have come from the corpus.

Also wrong here: "LOSE has exactly one entry". Per kind the shapes are HINT_PAUSE 4, HINT 3, LOSE 4, OBJECTIVE 4 positional fields, and GRAPH 1 NAMED field — the .t32 texture. The single-field bucket was GRAPH, not LOSE.

What survives as new: the 11 field VALUES read as a block, the GP_TEST and TEXTS sibling records, the per-stage phase census, and the five pgmsg_*.prt still resolving nowhere.

message\MissionDialogMessage.tbl — keyed by stage AND phase

Probed 7 values × 34 prefixes × 41 archives. Two resolve: message\MissionDialogMessage.tbl (IDXD) and language\MissionDialog_local_string.tbl (IXUD), each in all six GP_MAIN_GAME_* paks. 200 records, 25 280 bytes, every name of the form S<NN>_P<n>_<KIND> with five kinds, 40 each:

kind	fields	reading
HINT_PAUSE	4	the pause menu's hint lines
HINT	3	🟡 in-mission hint
OBJECTIVE	4	🟡 the objective text
LOSE	4	🟡 the failure lines
GRAPH	1 NAMED	✅ a .t32 texture — S10_P1_GRAPH → pgmsg_stg10_1.t32

The fields are positional, tagged 0…3, and each value is a message key: S10_P1_HINT_PAUSE → S10_P1_Hint_Pause_00 … _03. So this is an index from (stage, phase, kind) to the localised strings — the same S<NN>_P<n> keying the ISL corpus uses for mission phases.

🧪 Control — the 22 stages are exactly the STORY stages. The 40 stage-phases span stages 1–16 and 24–29; that is a subset of the 28 shipped, and the six with no hints at all are 18–23, the tutorials (stage-numbering-and-player-craft). A fifth independent route to the same story/tutorial split, and it also gives the phase count per stage — 1 to 3, e.g. S02 and S03 have 3, S10 and S13 have 1.

🟡 Five values still do not resolve — with two working controls

All five pgmsg_*.prt are not a pak entry under any of the 34 prefixes tried. Two controls sit in the same sweep and both resolve in 6 archives: message\MissionDialogMessage.tbl and language\MissionDialog_local_string.tbl — the second only after the correction above added language\.

This is the same wall mission-phase-advance hit for the manifest's KEYS — but that sweep probed MISSION1..33 and MISSION_*_PRT as names. This one probes the values, which had never been read, and closes them the same way.

⚠️ name_hash is CASE-INSENSITIVE

name_hash("message\\a.tbl") == name_hash("Message\\A.TBL"). tag_hash is not (tag_hash("Abc") != tag_hash("abc")). Already noted for archive lookup in sound-pak-contents; worth repeating because it doubles the apparent hit count of any prefix sweep.

🔎 Where .prt parts live — and why these five are the exception

Followed up the next iteration. Read first: ui-prm-primitives.md, ui-rat-layout.md, ui-screen-runtime.md — they own the .prt/RATC/T8aD UI stack and describe element names inside bundles, not where the parts live. Artefact ../data/prt-parts.txt, regenerator tools/re-capture/prt_parts.py.

A .prt IS a pak entry — under a LANGUAGE directory. Of the 376 distinct .prt names referenced anywhere on the disc, 241 resolve as an archive entry: 220 under eng\ and jpn\, 38 under each of the other four. My earlier sweep had eng\…esp\ in the list, so this is not the missing-prefix mistake again — the five simply are not there.

name	resolves under
prbase.prt	all six language dirs
palogo1.prt	eng\, jpn\
all five pgmsg_*.prt	nothing, under any of 15 prefixes

🟡 A partial lead, and its own refutation. Four of the five have a same-stem _sub.rat sub-bundle inside every per-language 2D pak (pgmsg_start_sub.rat, _end_, _failed_, _restart_ — 6 archives each); pgmsg_update has none. Tempting as "the parts live as RATC sub-bundles", but the control kills the generalisation: only 4 of 376 .prt stems have a _sub.rat at all (the other 7 belong to GP_BUNK, GP_SYSTEM, GP_MISSION_LOG), and prbase.prt — which does ship as an entry — has no _sub.rat. So _sub.rat is not the container convention; it is something these four happen to have.

✅ Who REFERENCES a part decides whether it ships as an entry

Censused the whole 135, not the five. The cross-tab over all 376 names:

referenced by tables.pak	resolves as an entry	count
yes	yes	241
no	no	100
yes	no	35
no	yes	0

Resolving implies being referenced by tables.pak — 0 counterexamples in 376. tables.pak holds the menu screen configs; every part it names ships as <lang3>\<name>.prt. The 100 names that appear only inside the GP_MAIN_GAME_*2D.pak bundles never ship as entries at all — they are the in-flight HUD, authored into the bundles rather than loaded by name.

🔑 So the five pgmsg_*.prt are not a special case of their own: they belong to the 135, and the real split is menu parts (named, shipped) vs in-game parts (embedded). It is not a prefix rule — 6 of the 135 pg* names do resolve (pgloading, pgloading2, pgmsg_scr, pgpause, pgpause_ttrl, pgpbase), because tables.pak names them.

🟡 The 35-name residual is one coherent family: referenced by tables.pak yet absent — pgmenu_btn* / pgmenu_item* / pgmenu_pad, pgfacewin*, pgtextwin, phinfo1-3, 02d, 02d_scr, psview_release. That is the in-game pause menu and squadron-order overlay: named by a menu config but drawn from the in-game bundles. Consistent with the split above; not separately proved.

✅ An embedded part IS a top-level RATC bundle, named by its element prefix

ui-rat-layout owns this stack and already says a top-level RATC bundle is "one (context × language) build of that screen" with a 60-byte element declaration table at 0x20. What it does not say is how a part is addressed when it is not a pak entry. It is addressed by the bundle itself: the elements of one bundle share a common name prefix, and that prefix is the part name.

GP_MAIN_GAME_E2D.pak holds 130 bundles with 114 distinct element prefixes — pgmenu_btn00, pghud_wing, pgface, pghud_range, pgmanuva_eff0, … i.e. exactly the in-game part names.

	matches a 2D bundle prefix	matches any bundle prefix
the 100 in-game-only .prt	68	68
CONTROL the 241 shipped .prt	0	13

0 of 241 is what makes this a result rather than a coincidence: the two families are disjoint on the test. (The 13 are shipped parts matching a bundle in their own screen pak, which is expected.)

Four of the five mission banners land here: pgmsg_start.prt is the 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 it having no _sub.rat either.

🟡 32 in-game names still have no 2D bundle (listed in the artefact). They visibly 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_* — which reads as "a variant declared inside a parent bundle rather than a bundle of its own". A reading, not adopted; nothing here shows the variant mechanism.

❌ 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.

🟡 Not settled

• Where the five pgmsg_*.prt screen parts live — see the section above for how far that got.
• dat\GP_TEST\ is named by the manifest and is not on the disc — a debug path left in, not a missing asset. Not chased.