From f041de8636dabdfe79dcf5565528f6db91373c65 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Thu, 27 Aug 2026 00:48:52 +0000 Subject: [PATCH] re: hypothesis for what REMAINING OB counts -- marked attackers, 4 per squadron MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Assembled from existing captures, not newly measured, and marked 🟡 accordingly. mission-objectives-text.md gives phase 1's roster as 4 e010_Attacker_S GROUPS totalling 16 CRAFT -- four per squadron -- and the counter moves in steps of exactly four (004 -> 008 -> 012). The phase-1 objective is stated in the mission dialogue as "the attackers with the orange markers", i.e. the e010s, not the turrets that outnumber them 7:1. mission-wave-arrivals.md pins the arrival of the three polled squadrons at t=170 SECONDS, which is when the counter is seen to climb. That accounts for every number taken so far, including the two that looked contradictory: the counter held at 012 while the hostile population fell by a third because those kills were almost all turrets, and it decremented 12 -> 11 in the one run whose pilot actually killed attackers. Recorded with its own refutation tests (kill one e010 -> must fall by exactly 1; kill a turret -> must not move; phase 1 should cap at 016) and with the weak point stated: "four per squadron" is 16/4, a MEAN, and if the squadrons are 5/5/3/3 the step-of-four pattern is coincidence. --- docs/re/ob-counts-marked-attackers.md | 73 +++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 docs/re/ob-counts-marked-attackers.md diff --git a/docs/re/ob-counts-marked-attackers.md b/docs/re/ob-counts-marked-attackers.md new file mode 100644 index 0000000..18ea1a2 --- /dev/null +++ b/docs/re/ob-counts-marked-attackers.md @@ -0,0 +1,73 @@ +# 🟡 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`](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)`. + +## ❌ 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 ❔.