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

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

Status: 🟡 HYPOTHESIS, assembled from existing measurements, NOT itself measured. 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.

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