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