# 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. * **`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 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](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** — `deployed` would 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.tbl` names 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. --- # Hunting the phase trigger in the message tables (2026-08-24) ## ✅ `StageMessageSet_S.tbl` resolved — the prefix is `message\` [structures/stage-mission-tables.md](structures/stage-mission-tables.md) recorded this table as ❔, "not in `GP_MAIN_GAME_E.pak` under that name". It is there; the archive prefix is **`message\`**, not `stage\` like its siblings. Sweeping the prefix candidates over the full 16 630-entry TOC found it immediately. It holds three records — `VoiceID2SndID`, `UnitMessageSetTable`, and a `Files` list of 31 message tables: `ScriptMessage_S02_msg.tbl`, `ScriptMessage_S02guide_msg.tbl`, `DemoMessage_S02_msg.tbl`, and per-character `PresetMessage_*` sets. ## ✅ Phases are a first-class runtime concept, confirmed independently `message\UnitMessageSet_S02.tbl` (26 records) has exactly four named fields: ``` CrewCount, PresetMessage_Phase1, PresetMessage_Phase2, PresetMessage_Phase3 ``` Every message set carries a **different preset message table per phase**. That is a third, independent table family organised around `Phase_1..3`, after the stage record and the route names. Phases are not a quirk of one file. ## 🔴 Refuted: the script-message trigger field is not a phase trigger `ScriptMessage_S02_msg.tbl` has 149 records whose third positional field looked promising — values like `Killed` alongside `None`. Enumerated across the corpus it is a small closed vocabulary: | value | S02 | S01 | |---|---|---| | `None` | 105 | 72 | | `Emergency` | 33 | 5 | | `Killed` | 5 | 2 | | `Noise` | 5 | 8 | These are **delivery categories for radio chatter** — how a line is played (urgent, over static, on a death) — not mission control flow. The fourth field is `1` in every single record, so it is not an argument either. Rejected. ## ❔ No table carries a phase-advance condition Phases now appear in the stage record, in route names, and in message sets, and **not one of those files says what ends a phase.** Everything found is a *consequence* of the phase, never its cause. That points at the advance logic living in code rather than data. The only place left is the executable, and `default.xex` is encrypted on disc — the decrypted image exists only in guest RAM, which means a run plus function-level work. Recorded as the honest end of the static search rather than continuing to guess at table names.