Syplheed-Reborn/docs/re/ob-counts-marked-attackers.md

# 🟡 What `REMAINING OB` counts — the marked attackers, four per arriving squadron

**Status: ✅ CONFIRMED for the counter's RISES — the `A`-route arrival times
predict every step to the second (measured 2026-08-27, see below). 🟡 the
DECREMENT half is still untested: no run has yet killed a marked attacker under
observation.** 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 ❔.

---

# ✅ 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.