Sylpheed/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 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 e010s, not the turrets that outnumber them seven to one.

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), 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 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 calls ADN110/111/112 "the three squadrons the phase-1 clear condition polls", while 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); 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).

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

✅ 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) and the mission clock sampled throughout (capture).

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