fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: CONFIRMED -- the A-route arrival times predict the OB counter's steps exactly

Browse Source 
Predicted from the disc alone, before the run: ADT102/ADT107/ADT113, each n=4,
arrive at t=0/120/210, so the counter reads 004, steps to 008 at t=120 and 012 at
t=210, and goes no higher in phase 1.

Measured with the mission clock sampled beside the counter throughout:

  004 held over six samples to 01:45.44
  008 first seen at 02:00.87  -> step bracketed in (105.4s, 120.9s]
  008 held over five samples to 03:17.55
  012 first seen at 03:30.66  -> step bracketed in (197.6s, 210.7s]
  012 held four more samples to 04:36.95, no 016

Both steps land on the predicted second, and the ceiling holds.  Three independent
features -- starting value, both step TIMES, and the ceiling -- came from
Route_S02.tbl and UnitGroup_S02.tbl with nothing fitted to runtime data.  So the
counter's rises ARE the A-route attacker squadrons arriving.

Status upgraded to CONFIRMED for the rises.  The DECREMENT half stays 🟡 and is
now the only open part: this run killed nothing, and the single observed 12 -> 11
remains one sample.
This commit is contained in:
Sylpheed RE agent
2026-08-27 01:55:07 +00:00
parent 0feadc4205
commit 054bd0794c
1 changed files with 51 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
docs/re/ob-counts-marked-attackers.md
View File

@@ -1,7 +1,9 @@
# 🟡 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*
**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.
@@ -224,3 +226,50 @@ unless the poll covers more than the objective. Unresolved here.
* 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.