8ebe4edff2
Swept every Route_*_p<n><kind> in every stage table, resolving each squadron to its unit via that stage's own UnitGroup, with F/S/M routes as the control: A/B routes : 23 of 67 resolved are attacker/bomber = 34.3% F/S/M control: 27 of 928 = 2.9% A ~12x enrichment, so the signal is real and not a one-stage accident. But "A means the marked attackers" remains too strong: of the 67 resolved A/B routes, 35 carry UN_mn040_Asteroid_Big and 9 carry UN_n001_TTRL_Box (TTRL = tutorial). A reading covering all four is "things the mission wants shot" -- attackers in a combat stage, asteroids in an asteroid stage, boxes in a tutorial -- which keeps A as an objective marker rather than a unit-class marker, but that is a reading of four unit types, not a measurement. Records a near-miss: a truncated listing showed the first ~26 rows, dominated by early stages, in which every resolved row was an attacker. I nearly wrote "23/23, unanimous". The full set is 23/67 -- the tail of a sorted listing is not the distribution. The Stage 02 derivation is unaffected: its three A routes are still exactly the three n=4 attacker squadrons.
227 lines
10 KiB
Markdown
227 lines
10 KiB
Markdown
# 🟡 What `REMAINING OB` counts — the marked attackers, four per arriving squadron
|
||
|
||
**Status: 🟡 HYPOTHESIS, assembled from existing measurements, NOT itself
|
||
measured.** It is recorded because it is the first reading that fits *every*
|
||
number this corpus has taken, and because it makes sharp predictions that one
|
||
run can kill.
|
||
|
||
## The reading
|
||
|
||
`REMAINING OB` counts the **objective-marked `UN_e010_ADAN_Attacker_S` craft
|
||
still alive**, and it *rises* because those craft arrive in squadrons on the
|
||
mission's timetable rather than being present from the start.
|
||
|
||
## The arithmetic that suggested it
|
||
|
||
[`mission-objectives-text.md`](mission-objectives-text.md) gives phase 1's roster
|
||
two ways — by unit group and by craft:
|
||
|
||
| unit | groups | craft |
|
||
|---|---|---|
|
||
| `UN_e007_ADAN_Turret` | 12 | 108 |
|
||
| `UN_e106_ADAN_Destroyer` | 7 | 7 |
|
||
| `UN_f001_TCAF_DeltaSaber_T` | 7 | 7 |
|
||
| **`UN_e010_ADAN_Attacker_S`** | **4** | **16** |
|
||
|
||
**16 craft across 4 groups — four per squadron.** The counter moves in steps of
|
||
exactly **four**: `004 → 008 → 012`. And the phase-1 objective is stated outright
|
||
in the mission dialogue: *"The attackers with the orange markers"* — the `e010`s,
|
||
not the turrets that outnumber them seven to one.
|
||
|
||
[`mission-wave-arrivals.md`](mission-wave-arrivals.md) supplies the timing: the
|
||
three squadrons the phase-1 clear condition polls (ADN110, ADN111, ADN112) all
|
||
have first-keyframe time **170**, confirmed live as **seconds**. Objective craft
|
||
therefore *arrive* minutes into the flight, which is exactly when the counter is
|
||
observed to climb.
|
||
|
||
## Every measured fact it accounts for
|
||
|
||
| measurement | this reading |
|
||
|---|---|
|
||
| reads `004` with ~118 hostiles live | the 118 are overwhelmingly turrets; only the marked attackers count |
|
||
| **rises** `004 → 008 → 012` | one squadron of four arriving at each step |
|
||
| **held at `012`** while hostiles fell 132 → 93 | the pilot's kill logs are almost entirely `e007_Turret` — the wrong 42 kills, in that file's own words |
|
||
| **decremented `12 → 11`** exactly once when the player really fired | that run's preference knob produced its only `e010` kills |
|
||
| no class head-count ever equals the counter | the live `e010` population includes squadrons not yet released — 16 live against a counter of 12 in tonight's sample |
|
||
|
||
The fourth row is the one that turns this from arithmetic into an explanation:
|
||
every earlier "the counter ignores kills" result came from runs killing turrets,
|
||
and the single decrement came from the single run that killed attackers.
|
||
|
||
## What would refute it — one run, cheap
|
||
|
||
1. **Kill one `e010` and nothing else.** The counter must fall by exactly 1. If it
|
||
falls by 4, it counts squadrons; if it does not move, this is dead.
|
||
2. **Kill a turret.** The counter must not move at all.
|
||
3. **Watch for `016`.** With four squadrons of four, phase 1 should cap at 16. A
|
||
counter that climbs past 16 kills the "marked attackers" reading outright.
|
||
4. **Compare the counter against the count of `e010` in the `active` state**, not
|
||
the raw live count — `phase-watch` already reads squadron state 1 (not
|
||
deployed) → 2 (active), so the prediction is `counter == 4 × (active e010
|
||
squadrons) − (marked attackers killed)`.
|
||
|
||
## ✅ The weak point, tested statically — and it holds for phase 1
|
||
|
||
The caveat below said "four per squadron" was `16 / 4`, a **mean**, and that
|
||
5/5/3/3 would make the step-of-four a coincidence. That is now measured, from the
|
||
disc, with no emulator: `tools/re-capture/unitgroup.py S02` decodes
|
||
`stage\UnitGroup_S02.tbl` (111 squadrons, 116 members, roster self-check
|
||
111/111).
|
||
|
||
Every `UN_e010_ADAN_Attacker_S` squadron in Stage 02:
|
||
|
||
| squadron | n | | squadron | n |
|
||
|---|---|---|---|---|
|
||
| `ADN204` | **4** | | `ADN209` | 6 |
|
||
| `ADN206` | **4** | | `ADS151` | **4** |
|
||
| `ADT102` | **4** | | `ADS251` | 9 |
|
||
| `ADN208` | 6 | | `ADT107` | **4** |
|
||
| `ADT113` | **4** | | | |
|
||
|
||
**9 groups, 45 members** — so the sizes are *not* uniform across the stage.
|
||
|
||
### ✅ And phase 1's four are measured, not inferred
|
||
|
||
`Route_S<NN>.tbl` names routes **`Route_<squadron>_p<phase><kind>`**
|
||
([stage-mission-tables.md](structures/stage-mission-tables.md)), so the
|
||
squadron → phase link is readable straight off the disc. Stage 02 has **37**
|
||
phase-1 squadrons, and intersecting them with the `e010` roster gives:
|
||
|
||
| phase-1 `e010` squadron | n |
|
||
|---|---|
|
||
| `ADS151` | **4** |
|
||
| `ADT102` | **4** |
|
||
| `ADT107` | **4** |
|
||
| `ADT113` | **4** |
|
||
| **total** | **16** |
|
||
|
||
**Exactly four groups, every one of size four, summing to sixteen.** The five
|
||
remaining `e010` groups — `ADN204`, `ADN206`, `ADN208`, `ADN209`, `ADS251`, which
|
||
include *both* `n = 6` groups and the `n = 9` group — are **not** in phase 1.
|
||
|
||
So the stage-wide mean was misleading precisely because the odd-sized squadrons
|
||
belong to later phases. Restricted to phase 1 the size is uniform, and the
|
||
counter's step of four is a real per-squadron member count. ✅ on that point: the
|
||
`16 / 4` mean is replaced by a measured per-group fact, and the coincidence the
|
||
caveat feared (5/5/3/3) is ruled out.
|
||
|
||
## ✅✅ The `A` route kind names the objective squadrons — and it predicts the whole trajectory
|
||
|
||
Route names carry a **kind** suffix (`Route_<sq>_p<phase><kind>`) whose meaning
|
||
[stage-mission-tables.md](structures/stage-mission-tables.md) lists as ❔. In
|
||
Stage 02 the distribution is lopsided:
|
||
|
||
| phase | A | B | F | M | S |
|
||
|---|---|---|---|---|---|
|
||
| 1 | **3** | — | 16 | — | 18 |
|
||
| 2 | — | — | 15 | — | 22 |
|
||
| 3 | — | — | 13 | 11 | 22 |
|
||
|
||
**Only three routes in the whole stage are kind `A`, all in phase 1** —
|
||
`ADT102`, `ADT107`, `ADT113`. Every one is a `UN_e010_ADAN_Attacker_S` squadron
|
||
of **n = 4**. (The fourth phase-1 `e010` squadron, `ADS151`, is kind `F`.)
|
||
|
||
Their first-keyframe times, read from the same table:
|
||
|
||
| squadron | kind | n | arrival |
|
||
|---|---|---|---|
|
||
| `ADT102` | **A** | 4 | **t = 0** |
|
||
| `ADT107` | **A** | 4 | **t = 120** |
|
||
| `ADT113` | **A** | 4 | **t = 210** |
|
||
| `ADS151` | F | 4 | t = 0 |
|
||
|
||
Counting only the `A` squadrons gives a complete predicted trajectory:
|
||
|
||
| mission time | arrived `A` craft | predicted counter |
|
||
|---|---|---|
|
||
| 0 | 4 | **004** |
|
||
| 120 | 8 | **008** |
|
||
| 210 | 12 | **012** |
|
||
| — | — | **never exceeds 012 in phase 1** |
|
||
|
||
**That is exactly what every run has shown**: the counter is `004` at flight
|
||
entry, steps to `008` and then `012` within the first three to four minutes, and
|
||
has never been observed above `012`. All three features — the starting value, the
|
||
step size, and the ceiling — fall out of the disc with nothing fitted.
|
||
|
||
It also explains the two results that looked like problems:
|
||
|
||
* The **fifteen-minute hold at `012`** — after t = 210 every `A` squadron has
|
||
arrived, so the counter can only fall, and that run's kills were turrets.
|
||
* **`016` never appeared.** An earlier version of this note predicted a cap of 16
|
||
from four squadrons; that prediction is **withdrawn**. `ADS151` is an `F` route
|
||
and is not counted, so the ceiling is 12.
|
||
|
||
### 🟡 What `A` means, tested across all 28 stages — enriched, but not "attackers"
|
||
|
||
The three-route sample in one stage was too small to read a meaning off, so the
|
||
sweep was run corpus-wide: every `Route_*_p<n><kind>` in every stage table,
|
||
resolving each squadron to its unit through that stage's own `UnitGroup`.
|
||
|
||
| route kind | resolved | attacker/bomber |
|
||
|---|---|---|
|
||
| **`A`/`B`** | 67 | **23 = 34.3 %** |
|
||
| `F`/`S`/`M` (control) | 928 | 27 = **2.9 %** |
|
||
|
||
A **~12× enrichment** for attacker/bomber units on `A`/`B` routes — the signal is
|
||
real and it is not a one-stage accident.
|
||
|
||
❌ **But "A means the marked attackers" is still too strong**, and the full
|
||
distribution says why:
|
||
|
||
| unit on a resolved `A`/`B` route | n |
|
||
|---|---|
|
||
| `UN_mn040_Asteroid_Big` | **35** |
|
||
| `UN_e010_ADAN_Attacker_S` | 12 |
|
||
| `UN_e011_ADAN_Attacker_B` | 11 |
|
||
| `UN_n001_TTRL_Box` | 9 |
|
||
|
||
Most `A` routes carry **asteroids**, and nine carry `TTRL_Box` — `TTRL` being the
|
||
tutorial prefix. 🟡 A reading that covers all four is *"things the mission wants
|
||
shot"*: attackers in a combat stage, asteroids in an asteroid stage, boxes in a
|
||
tutorial. That is consistent, and it keeps `A` as an objective marker rather than
|
||
a unit-class marker — but it is a reading of four unit types, not a measurement.
|
||
|
||
⚠️ **Correction to my own first look at this data.** A truncated listing showed
|
||
the first ~26 rows, which are dominated by early stages, and every resolved row in
|
||
it was an attacker — I nearly recorded "23/23, unanimous". The full set is 23/67.
|
||
The tail of a sorted listing is not the distribution.
|
||
|
||
None of this disturbs the Stage 02 derivation above: S02's three `A` routes are
|
||
still exactly the three `n = 4` attacker squadrons, and the predicted trajectory
|
||
is unchanged.
|
||
|
||
## ❌ A premise of this note was WRONG — ADN110/111/112 are TURRETS
|
||
|
||
This note said the polled squadrons ADN110, ADN111 and ADN112 arrive at t=170 and
|
||
implied they are the marked attackers. The roster says otherwise:
|
||
|
||
```
|
||
ADN110 unit=UN_e007_ADAN_Turret n=9
|
||
ADN111 unit=UN_e007_ADAN_Turret n=9
|
||
ADN112 unit=UN_e007_ADAN_Turret n=9
|
||
```
|
||
|
||
All three are **turret** squadrons of **nine**. So the arrival-time evidence I
|
||
quoted is about turrets, not about the objective craft, and it does **not**
|
||
support this reading. It has to be withdrawn from the argument.
|
||
|
||
❔ **And it leaves a genuine tension in the corpus**, worth stating rather than
|
||
smoothing: [`mission-wave-arrivals.md`](mission-wave-arrivals.md) calls
|
||
ADN110/111/112 "the three squadrons the phase-1 clear condition polls", while
|
||
[`mission-objectives-text.md`](mission-objectives-text.md) has the phase-1
|
||
objective as the *marked attackers*. Those cannot both be the clear condition
|
||
unless the poll covers more than the objective. Unresolved here.
|
||
|
||
## ❌ What this is NOT
|
||
|
||
* Not measured. No run was made for this note; every number in it is quoted from
|
||
an existing capture in this corpus.
|
||
* ⚠️ "Four craft per squadron" is `16 / 4` — a **mean**, not a per-squadron count.
|
||
If the squadrons are 5/5/3/3 the step-of-four pattern is a coincidence and the
|
||
reading is wrong. `Route_ADN11x_p1F` `FrameCount` values (3, 3, 2) are *route*
|
||
keyframes, not member counts, and must not be confused for them.
|
||
* It does not explain the mechanism, only the arithmetic. The counter itself is
|
||
the **HUD widget's value** ([`structures/mission-objective-counter.md`](structures/mission-objective-counter.md));
|
||
where the mission keeps its own tally is still ❔.
|