aac791e0e9
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.
3.1 KiB
Enemies come into play per PHASE, deployed at phase start
Status: 🟡 strongly supported and internally consistent, one unexplained off-by-one; ❔ what advances a phase is now the single open question.
This is the answer the wave line of work has been converging on, and it is not the one the route timetable first suggested.
The evidence
Static, from Route_S02.tbl cross-referenced with UnitGroup_S02.tbl:
| phase | squadrons with routes | members |
|---|---|---|
| 1 | 37 | 42 |
| 2 | 34 | 36 |
| 3 | 44 | 49 |
| no route | 3 | 3 |
(Squadrons appear in more than one phase — 37+34+44 = 115 against 111 squadrons — so the member totals overlap and do not sum to 116.)
Dynamic, measured repeatedly across many runs:
deployed = 41 of 116 records, from the first observable instant, never changing
41 deployed against 42 phase-1 members. The deployed set is the phase-1 roster, to within one record.
What this makes coherent
Every previously puzzling observation falls into place:
- All 116 records exist at mission load — confirmed on two stages — but only the current phase's squadrons hold craft.
deployedis 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 are where the other 85 members are.
- The route times are within-phase fly-in timings, not release times, which fits the frames reading (Stage 01 phase 2's t = 1500/1800/2100 → 50/60/70 s at 30 Hz).
So: enemies come into play per phase, deployed together at phase start. The route entry gives each squadron its entrance path and the moment it flies in.
The off-by-one is not explained
41 observed against 42 expected. Candidates, none tested: the player's own 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. It is recorded rather than rounded away — a one-record gap is exactly the size of the errors that have misled this corpus before.
❔ The single open question: what advances a phase
This is now the whole remaining question, and it is the same one raised many
iterations ago in
structures/stage-mission-tables.md — the
stage record declares Phase_1..3 but nothing found says what ends one.
What is now known that was not then:
- a phase advance is directly observable —
deployedwould jump from 41 toward the phase-2 roster, which is unmissable with the current probe; - it did not happen in any run, including 435 s of verified-live flight with 42 craft destroyed, so it is not a short timer and not a small kill count;
- the likely gate is an objective, and
SUBObjectiveSettings_S02.tblnames nine of them but carries only rewards and HUD strings — no trigger.
Places not yet looked: StageMessageSet_S02.tbl (never resolved in
GP_MAIN_GAME_E.pak), and the executable, whose decrypted image is only
available in guest RAM.