# 🟡 What `REMAINING OB` counts — the marked attackers, four per arriving squadron **Status: ✅ CONFIRMED, both halves (2026-08-27).** The `A`-route arrival times predict every rise to the second, and a marked attacker's death was finally observed: the counter fell by **exactly one**, and the next arrival then raised it by four from the *reduced* value. See the final section. 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.tbl` names routes **`Route__p`** ([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__p`) 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` 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 ❔. --- # ✅ MEASURED — the arrival times predict the counter's steps exactly Stage 02, guarded route, stage asserted, mission clock sampled beside the counter throughout ([capture](captures/ob-arrival-timing-confirmed.png)). The prediction, made from the disc alone before this run: the three `A`-route squadrons `ADT102` / `ADT107` / `ADT113`, each `n = 4`, arrive at **t = 0 / 120 / 210**, so the counter should read `004`, step to `008` at **t = 120** and to `012` at **t = 210**, and go no higher in phase 1. Observed: | mission `TIME` | `REMAINING OB` | | |---|---|---| | 00:12.33 → 01:45.44 | `004` | six samples | | **02:00.87** | **`008`** | step bracketed in **(105.4 s, 120.9 s]** | | 02:16.59 → 03:17.55 | `008` | five samples | | **03:30.66** | **`012`** | step bracketed in **(197.6 s, 210.7 s]** | | 03:47.19 → 04:36.95 | `012` | four samples, **no `016`** | **Both steps land on the predicted second.** 120 lies inside the first bracket and 210 inside the second, and the ceiling holds at `012` for a further 86 s of mission time. Three independent features — the starting value, the two step *times*, and the ceiling — were all derived from `Route_S02.tbl` and `UnitGroup_S02.tbl` with nothing fitted to the runtime data. ✅ The counter's rises **are** the `A`-route attacker squadrons arriving. (The digits render highlighted on exactly the two samples where they change, which is the game flashing the counter on update — a free extra confirmation that those two frames are the transitions.) ## 🟡 What is still not measured: the decrement Everything above concerns the counter going **up**. That the counter goes *down* by one per marked attacker killed remains untested — the single observed decrement (`12 → 11`) came from a run whose pilot killed attackers, which is suggestive but is one sample, and this run killed nothing. The kill test is unchanged and is now the only open half: 1. Kill ONE `e010` and nothing else → the counter must fall by exactly **1**. 2. Kill a turret → it must not move. --- # 2026-08-27 — the kill run: rises reproduced (n=2), decrement still not shown `pilot.py` with `SYLPH_PREFER=e010`, 300 s, Stage 02, mission clock sampled throughout ([capture](captures/ob-kill-run-timeline.png)). ## ✅ The arrival timing reproduces exactly — second independent run | mission `TIME` | `OB` | |---|---| | 01:35.20, 01:54.77 | `004` | | **02:14.67** | **`008`** — step in (114.8 s, 134.7 s] | | 02:28 → 03:16.39 | `008` | | **03:33.32** | **`012`** — step in (196.4 s, 213.3 s] | | 03:47 → 05:11.56 | `012` | Both brackets contain the predicted **120** and **210**. The arrival half is now confirmed on **two independent runs**. ## 🟡 The decrement: INCONCLUSIVE, and the reason is specific The pilot flew and fought properly this time — **424 `fire=1` samples**, 865 of them with the target inside 1500 units, closest approach **79** units, target `e010_ADAN_Attacker_S` throughout, hull never scratched (1500/1500). And the hostile population **fell 129 → 116**: thirteen ADAN died. **The counter did not move**, holding `012` for 98 s across that. ❌ **But this is not evidence against the decrement**, and saying so would repeat the exact error this corpus has logged twice. To read a null result I must show the thing that would produce it happened — *a **marked** attacker dying* — and I cannot: * The thirteen dead were not identified by class. The corpus's own history is that this pilot's kills skew overwhelmingly to `e007` turrets, which are seven times more numerous and much closer. * The live `e010` count **rose** over the run rather than fell, so attacker deaths cannot be inferred from it either. ## ✅ One thing the run does establish: the counter is NOT "live attackers" Measured at `TIME 05:56.85`, both arms at the same instant: | | | |---|---| | `REMAINING OB` | **012** | | live `UN_e010_ADAN_Attacker_S` (definition-pointer enumeration, deduped by position) | **23** | **23 ≠ 12.** So the counter tracks a *subset* of the attackers, not all of them — and 12 is exactly the membership of the three `A`-route squadrons (3 × n=4). Phase 1 fields only 16 `e010` in total, so 23 live means later-phase or `F`-route squadrons have joined the scene without touching the counter. That kills the simplest competing reading ("the counter is the live attacker head-count") and is a positive result for the *marked-subset* interpretation, independent of the decrement question. ⚠️ One anomaly, recorded not explained: the same enumeration reports **2** `UN_f001_TCAF_DeltaSaber_T_Player`. Deduplication is by position value, so two distinct positions carry the player definition. Not investigated. ## What the decrement test still needs A run in which a **marked** attacker demonstrably dies — which means logging the per-class roster before and after each kill, not just the ADAN total. The pilot already prefers `e010`; what is missing is the bookkeeping to prove it hit one. --- # 2026-08-27 (third run) — ✅ the turret CONTROL passes, arrival timing at n=3 `pilot.py` with `SYLPH_PREFER=e010` for 320 s (312 `fire=1` samples), with a per-class live count logged every 11 s beside the HUD ([`class_count.py`](../../tools/re-capture/class_count.py)) and the mission clock sampled throughout ([capture](captures/ob-turret-control-timeline.png)). ## ✅ Killing turrets does NOT move the counter — control confirmed The live turret population fell monotonically while the counter only ever rose: ``` sample 0: e007=108 e010=16 OB 004 sample 9: e007=105 e010=16 OB 008 sample 21: e007=102 e010=16 OB 012 sample 25: e007=101 e010=16 OB 012 ``` **Seven `e007` turrets died and `REMAINING OB` never decremented once.** This was previously only *weakly* supported — inferred from a run whose kill log happened to be turrets. It is now a measured control with the classes counted directly. ## ✅ Arrival timing reproduces a third time | mission `TIME` | `OB` | | |---|---|---| | 01:48.73 → **02:05.54** | `004` → **`008`** | step in (108.7 s, 125.5 s] ∋ **120** | | 03:24.16 → **03:41.70** | `008` → **`012`** | step in (204.2 s, 221.7 s] ∋ **210** | **n = 3.** Both predicted times are inside their brackets on every run so far. ## ✅ The live `e010` baseline is exactly phase 1's roster The count sat at **16** in 20 of 26 samples — precisely the phase-1 `e010` roster (`ADT102`, `ADT107`, `ADT113`, `ADS151`, each n=4). That is an independent runtime corroboration of the static roster, and it locates the counter's 12 as the three `A`-route squadrons within that 16. ⚠️ **Measurement artifact, stated:** six samples read 17–28. The spikes are always *upward* and never persist, and the counter dedups by a position triple read a moment after the pattern scan, so an entity written between the two reads can be counted twice. The stable floor of 16 is the signal; the spikes are noise in my tool, not arrivals. ## 🟡 The decrement is STILL unproven No marked attacker died in this run either: the `e010` floor never dropped below 16 despite 312 `fire=1` samples. So the counter had no opportunity to decrement, and its stillness says nothing about the claim. Three runs have now failed to kill one `e010`. The blocker is combat effectiveness, not instrumentation — `pilot-never-fires.md` and the `SYLPH_PREFER` notes already record that this pilot lands few attacker kills because turrets are nearer and far more numerous. ❔ Options not yet tried: pick a lone attacker while the squadron is still inbound, or wait for the wingmen/ACROPOLIS guns to kill one (which counts just as well). --- # 2026-08-27 (fourth run) — why the kill test keeps failing, quantified 520 s of `pilot.py` with `SYLPH_PREFER=e010` (198 `fire=1`), per-class counts every 10 s, OB+TIME sampled throughout ([capture](captures/ob-fourth-run-timeline.png)). ## ✅ Arrival timing, n=4 `008` first at **02:05.00** (step ∈ (111.1 s, 125.0 s] ∋ **120**); `012` first at **03:45.47** (step ∈ (209.7 s, 225.5 s] ∋ **210**); `012` then held for a further **3.5 minutes** to 07:07.21 — no fall, no `016`. ## ✅ The blocker is a DAMAGE RATE, and it is now measured The obvious reading of four failed runs is "the pilot cannot hit attackers". That is **wrong**. Reading `hull` at `pos+0x154` for every live `e010` at the end of the run: ``` live e010: 16 hulls: 360 365 395 405 407 410 420 445 470 475 480 490 495 495 500 500 damaged: 14 of 16 ; lowest 360/500 = 28 % gone ``` **Fourteen of sixteen marked attackers are damaged.** The shots land. What they do not do is finish: after ~8 minutes of combat the worst-hurt attacker has lost 28 % of its hull, so a kill needs roughly **3–4× longer on a single target**. The contrast with the control makes the mechanism plain — it is simply hit points: | class | HP | deaths this run | live-count change | |---|---|---|---| | `UN_e007_ADAN_Turret` | **100** | ~9 | 106 → 97 | | `UN_e010_ADAN_Attacker_S` | **500** | **0** | 16 → 16 (floor never moved) | Turrets die because they have a fifth of the hull; attackers absorb everything the player, the wingmen and the ACROPOLIS's guns produce in a run and survive. ## 🟡 So the decrement remains unproven after four runs — and the test needs redesigning The `e010` floor has never once dropped, so the counter has never had the chance to decrement, and its stillness continues to say nothing about the claim. But the reason is no longer mysterious, and "fly longer" is not a fix: ~half of Stage 02 runs end early, so a 30-minute engagement on one target is not reachable. ❔ Options for a next attempt, none tried: * **Concentrate on an already-damaged attacker** — one is at 360/500, and hull is readable per entity, so the pilot could be pointed at the weakest rather than the nearest. * **Missiles.** The pilot logs a missile counter (`msl=73` in an earlier run) and they were never deliberately used. * **Accept it as a long-run experiment** and check the counter after a scripted event kills an attacker, rather than trying to force one. --- # ✅✅ THE DECREMENT, MEASURED — the hypothesis is confirmed in full The four previous attempts failed because fire was spread across the squadron: 14 of 16 attackers damaged, none killed. `pilot.py` gained `SYLPH_WEAKEST=1` (commit `00052b0`), which scales a target's score by its remaining hull so the pilot finishes what is already hurt. It worked on the first live run. All gates enforced first: `FLIGHT` confirmed, stage asserted, mission clock shown advancing (00:10.12 → 00:23.14 → 00:36.30) before the experiment began. ## The measurement Live `e010` count, logged every 10 s — the floor drops **once**, at sample 12, and stays down: ``` 0..11 e010=16 (spikes to 18/20 are the known tool artifact) 12..39 e010=15 one marked attacker dead ``` The counter, sampled beside the mission clock ([capture](captures/ob-decrement-confirmed.png)): | mission `TIME` | `OB` | | |---|---|---| | 01:45.65 | `004` | | | **02:06.33** | **`008`** | the t=120 arrival, +4 | | 02:51.19 | `008` | | | **03:10.28** | **`007`** | **← DECREMENT, in (171.2 s, 190.3 s]** | | 03:29.66 | `007` | | | **03:48.40** | **`011`** | the t=210 arrival, +4 **from 7, not from 8** | | 04:07 → 06:50.30 | `011` | holds; ceiling is 11, not 12 | ## Why this is conclusive and not a coincidence * **It fell by exactly 1**, not by 4. So the counter tracks *craft*, not squadrons — the competing reading is dead. * **Exactly one attacker died and exactly one decrement occurred**, in the same window. * **The ceiling moved with it.** The t=210 arrival added its four to **7**, giving **011** — where every previous run reached **012**. A counter that merely read arrivals would have shown 012 regardless. The reduced ceiling is the kill still being remembered 3 minutes later. * **The control held throughout.** Turrets fell **109 → 92** — seventeen deaths — across the same run, and not one of them moved the counter. ## The settled reading `REMAINING OB` = **the number of objective-marked craft still alive**, where the marked craft are exactly the members of the phase's `A`-route squadrons (Stage 02 phase 1: `ADT102`, `ADT107`, `ADT113`, each `n = 4`). It rises by a squadron's membership as each arrives on its route's first-keyframe time, and falls by one for each marked craft destroyed. Turret and other non-marked deaths do not affect it. Every number in that sentence was predicted from `Route_S02.tbl` and `UnitGroup_S02.tbl` before being measured.