From afc33ea1093836b9eb20ef7d32a9a49d0e6f1ef6 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 25 Aug 2026 10:45:24 +0000 Subject: [PATCH] re: phase membership is in the Route record names; the ~300 craft are ~150 Route_S.tbl names every route Route__p -- 120/120 for S02 -- so the squadron-to-phase map was on the disc all along, in a table read until now only for fly-in geometry. 108/111 S02 squadrons map; the 3 misses are typos in the route table and all are phase 2. That resolves the 387-vs-300 gap after four failed attempts, by refuting its premise: there were never 300 craft. Phase 1's member-level n multiset {1x25, 2x1, 4x4, 9x12} matches the measured craft-per-record fan-in {2x24, 4x1, 8x4, 18x12} bucket for bucket at exactly 2x, so 300 = 2*(151-1), the -1 being the documented 41-vs-42 off-by-one. The 2x is the probe double-counting, not real units: a 2x reading needs 16 Delta Sabers for 8 named pilots, and breaks the formation capacity bound in 20 of 37 phase-1 squadrons (16 of them on Formation_1_only, one slot) where the 1x reading has 0 violations. All three measured craft totals being even is a further tell. Refuted: UnitGroup has no phase/spawn/delay field (1019 = sum(Count)*4 + 5*111, every slot accounted for); DisableInterval is No for all 111 S02 squadrons; stage\EnumSquadron_Test.tbl does not exist. Confirms tag_hash independently: UnitGroup record key == tag_hash(squadron id), 1160/1160. Still open: what advances a phase -- no static table encodes a trigger. --- docs/re/mission-phase-membership.md | 135 ++++++++++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 docs/re/mission-phase-membership.md diff --git a/docs/re/mission-phase-membership.md b/docs/re/mission-phase-membership.md new file mode 100644 index 00000000..dccb4d65 --- /dev/null +++ b/docs/re/mission-phase-membership.md @@ -0,0 +1,135 @@ +# Which squadrons fly in which phase — and the ~300 craft are ~150 + +Status: ✅ the phase map, read out of `Route_S.tbl` record names; +✅ the 387-vs-300 gap explained — **the live-craft probe double-counts**; +❔ what *advances* a phase (nothing static encodes it). + +## ✅ The phase map is in the route names + +`stage\Route_S02.tbl` has **121 records: 120 routes + 1 roster**, and every route +name matches `Route__p` — **120/120**: + +``` +Route_ADN101_p1F Route_TCN003_p2S Route_ADS351_p3M +``` + +The phase lives **in the name and nowhere else**; a route record's only named +field is `FrameCount`. So the squadron→phase mapping was on the disc all along, +one string-parse away, in a table that was being read for fly-in geometry. + +**108 of 111** S02 squadrons match a route name exactly. The three that do not — +`TCN207`, `TCN208`, `TCS252` — are **typos in the route table** (`Route_TCT207_p2S`, +`Route_TCT208_p2S`, `Route_TCN252_p2F`), plus two orphan routes naming no +squadron (`Route_ADS352_p3F`, `Route_kichi_p3F`). All three near-misses are +**phase 2**, so phase 1 is unaffected. + +Phase partition of Stage 02 (Σ`n` = 387 overall): + +| phase set | squadrons | Σ`n` | +|---|---|---| +| {1} | 33 | 142 | +| {2} | 31 | 110 | +| {3} | 39 | 118 | +| {1,3} | 2 | 5 | +| {2,3} | 1 | 1 | +| {1,2,3} | 2 | 4 | +| none (the 3 typos) | 3 | 7 | +| **per phase** | 37 / 34 / 44 | **151 / 115 / 128** | + +## ✅ The 387-vs-~300 gap: the probe counts each craft TWICE + +[roster-to-craft-link](roster-to-craft-link.md) records four failed attempts to +explain how the roster becomes "~300 live craft". The premise was wrong — **there +were never 300 craft.** + +Phase 1's **member-level** `n` multiset against the measured craft-per-record +fan-in (41 records, 300 craft): + +``` +phase-1 members (42): n=1 x25 n=2 x1 n=4 x4 n=9 x12 sum 151 +observed craft/record: 2 x24 4 x1 8 x4 18 x12 sum 300 +observed / 2: 1 x24 2 x1 4 x4 9 x12 sum 150 +``` + +Every bucket matches shape for shape. The only discrepancy is 24 vs 25 records +at the bottom — **the already-documented 41-vs-42 off-by-one, and it is an `n=1` +record.** So `300 = 2 × (151 − 1)`. Unit type corroborates independently: the 12 +records showing 18 craft are all `UN_e007_ADAN_Turret`, and phase 1 has exactly +12 turret squadrons at `n=9`. + +### ✅ The factor of 2 is an artifact of the probe, not real units + +Two static arguments, and the second is decisive because it is a hard capacity +bound: + +1. **Named pilots.** Phase 1's eight `f001` members all have `n=1` and carry + distinct identities — `Character_Player_Test, ELLEN, RAYMOND, GENE, SANDRA, + BILLY, ANTONIUS, CARL`. A 2× reading means 16 Delta Sabers for 8 named people. +2. **Formation slots.** Squadrons cannot exceed their formation's `FrameCount` + (see [unit-group-table](structures/unit-group-table.md)): + + | reading | violations among the 37 phase-1 squadrons | + |---|---| + | `Σn ≤ FrameCount` (1×) | **0** | + | `2·Σn ≤ FrameCount` (2×) | **20** | + + Including 16 squadrons on `Formation_1_only` — one slot, `n=1` — which a 2× + reading would have placing two craft in a one-slot formation. + +So the true phase-1 population is **~150**, and the 296 / 298 / 300 spread is +2 × a 148 / 149 / 150 population after kills. That all three measurements are +**even** is a further tell a 1:1 count would not produce half the time. + +**Best explanation of the missing 42nd record:** the player's own tuple +(`TCN001` member 0, `Character_Player_Test`), which plausibly is not in the +AI-craft pool the `+0x130` def-pointer scan walks. That makes the chain exact: +`300 = 2 × (151 − 1 player)`. + +⚠️ **This is a static argument about a dynamic measurement.** It says the probe's +number cannot mean what it was taken to mean; it does **not** identify *what* the +probe is double-counting. That needs a run — the counting rule in the craft scan +is the place to look, not the game. + +## 🔴 Refuted along the way + +* **`UnitGroup` carries no phase, spawn time or arrival delay.** The raw field + dump accounts for every slot: `1019 = sum(Count)·4 + 5·111`, with positional + entries tagged by sequential index (`0x0,0x1,0x2,…`), not hashes. There is no + spare field. +* **`DisableInterval` cannot explain Stage 02** — it is `No` for all 111 + squadrons. Corpus-wide its 31 `Yes` records sit in just two stages, S04 (5) and + S14 (26), all on `GNN***` squadrons. +* **`stage\EnumSquadron_Test.tbl` does not exist** (`0x213f4a7e` is not in the + TOC). It was listed as a candidate for the arrival-interval values; it is dead. +* `AIParams_S02.tbl` is keyed by AI profile, not squadron, and carries only + combat tuning. `SUBObjectiveSettings_S02.tbl` is keyed `SUBOBJ_005..014` with + only points/unlock/HUD strings — no squadron, phase or trigger. + +## ✅ Bonus: the `UnitGroup` record key, confirmed corpus-wide + +A squadron record's key is `tag_hash(squadron_id)` — **1160/1160 across all 28 +stages** (`ADN101` → `0x659aff47`). Same hash as +[idxd-tag-hash](structures/idxd-tag-hash.md); this is an independent +confirmation of it on a second kind of table. + +## ❔ Still open: what advances a phase + +Nothing static encodes a trigger. Swept the stage record and every table it +names — `Route`, `AIParams`, `SUBObjectiveSettings`, `FormationSet`, `nameplate`, +`EnumUnit`, `EnumCharacter`, `EnumLocalString`, `EnumWeapon` — plus the +`message\` family, for field names matching +`interval|time|phase|delay|wave|spawn|arrival|trigger|start|appear|event|condition`. +The only hits anywhere are `FrameCount` and `PresetMessage_Phase1/2/3` in +`message\UnitMessageSet_S02.tbl`. The trigger is almost certainly in the +executable, not the data. + +## Falsifiable predictions for the next run + +* Per-record craft counts, **in probe units (2×)**: 4 records at 8 = + `ADS151, ADT102, ADT107, ADT113` (all `UN_e010_ADAN_Attacker_S`); 1 record at + 4 = `TCN105` (`UN_f106_TCAF_Destroyer`); 24 records at 2 = the remaining + phase-1 `n=1` members. +* A phase advance should move the deployed set toward phase 2: 34 squadrons, + 36 members, Σ`n` 115 (≈230 in probe units). +* `TCN207`, `TCN208` and `TCS252` may **fail to arrive** in phase 2, because + their routes are misnamed.