StageMessageSet_S02.tbl is resolved. stage-mission-tables.md had recorded it as
absent from the pak; it is present, and the archive prefix is message\ rather
than stage\ like its siblings. Sweeping prefix candidates over the full 16630
entry TOC found it immediately. It holds a voice mapping, a unit message set
pointer, and a list of 31 message tables including ScriptMessage_S02_msg.tbl and
the per-character PresetMessage sets.
message\UnitMessageSet_S02.tbl then gives an independent confirmation of the
phase structure. Its 26 records have exactly four named fields: CrewCount and
PresetMessage_Phase1, Phase2 and Phase3. Every message set carries a different
preset table per phase, so phases now appear in three unrelated table families --
the stage record, the route names, and the message sets. They are not a quirk of
one file.
The promising lead did not survive. ScriptMessage_S02_msg.tbl has 149 records
whose third positional field takes values like Killed and None, which looked
like a trigger. Enumerated across S01 and S02 it is a small closed vocabulary of
None, Emergency, Killed and Noise -- delivery categories for radio chatter,
meaning how a line is played rather than mission control flow -- and the fourth
field is 1 in every record, so it is not an argument either. Rejected.
That leaves no table anywhere carrying a phase-advance condition. Everything
found is a consequence of the phase and never its cause, which points at the
advance logic living in code. The only place left is the executable, and
default.xex is encrypted on disc, so the decrypted image exists only in guest
RAM and reaching it needs a run plus function-level work. Recorded as the honest
end of the static search rather than continuing to guess at table names.
Cross-referencing Route_S02 with UnitGroup_S02 gives per-phase membership: phase
1 has 37 squadrons and 42 members, phase 2 has 34 and 36, phase 3 has 44 and 49,
with squadrons appearing in more than one phase so the totals overlap. The
measured deployed count, stable across many runs and from the first observable
instant, is 41 of 116 records.
41 against 42. The deployed set is the phase-1 roster, to within one record.
That makes every previously puzzling observation coherent. All 116 records exist
at mission load, confirmed on two stages, but only the current phase's squadrons
hold craft. Deployed is 41 before the ready room ends and never moves because
phase 1 deploys as a unit at load rather than on a schedule. No arrival was ever
observed in up to 435 s of verified-live flight with 42 kills because phase 1
never completed in any run, and phases 2 and 3 hold the other 85 members. And
the route times are within-phase fly-in timings rather than release times, which
fits the frames reading where Stage 01 phase 2's 1500, 1800 and 2100 are 50, 60
and 70 seconds at 30 Hz.
So enemies come into play per phase, deployed together at phase start, with each
squadron's route giving its entrance path and the moment it flies in.
The off-by-one is not explained and is recorded rather than rounded away. The
player's record may be counted differently, one squadron may hold craft in a way
the liveness read misses, or one phase-1 member may genuinely not deploy. A
one-record gap is exactly the size of the errors that have misled this corpus
before.
What advances a phase is now the single remaining question. It is directly
observable, since deployed would jump toward the phase-2 roster. It did not
happen in 435 s of verified-live flight with 42 craft destroyed, so it is
neither a short timer nor a small kill count. SUBObjectiveSettings names nine
objectives but carries only rewards and HUD strings, no trigger. Not yet
searched: StageMessageSet_S02.tbl, which has never resolved in the pak, and the
executable, whose decrypted image exists only in guest RAM.
