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

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

---

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