Sylpheed/docs/re/mission-arrival-watch.md

Six runs, no arrival — and an accidental control

Status: ✅ the deployment structure reproduces exactly; ✅ losses require the player; 🔴 no arrival has ever been observed, across six runs; ❔ whether mission/phase time is advancing at all is now the prime suspect and is untested.

✅ The deployment structure reproduces byte-for-byte

tools/re-capture/wave6_probe.py refuses to interpret a run whose roster count is not the reproduced baseline of 116 (the discard rule from mission-per-record-strength.md). This run passed, and its first sample is identical to the earlier link run:

roster records: 116     craft=300     deployed=41/116
strengths [(2, 24), (4, 1), (8, 4), (18, 12)]

Same 41 deployed of 116, same discrete strength histogram, same total. The deployment is deterministic at mission start.

✅ Losses require the player — an accidental control run

The pilot failed to bind this run (BIND FAILED, no pilot), so the craft sat unattended. That is the control condition the kill-versus-no-kill experiment needed, and it arrived by accident:

condition	duration	losses
hunting pilot	168 s	300 → 288
hunting pilot	168 s	296 → 280
no pilot	240 s	300 → 300, zero

With nobody flying, not one craft was destroyed in four minutes — the count held at exactly 300 for all 22 samples. So the 16–20 losses in the piloted runs are attributable to the player being in the fight, and NPC crossfire does not by itself destroy anything. That was an open question two iterations ago and it is now answered.

🔴 No arrival, in either condition, in six runs

Zero 0 → n transitions. Not with a hunting pilot, not without one, across roughly fifteen minutes of cumulative Stage 02 flight and windows up to 240 s. The 75 records that hold no craft at mission start still hold none at the end.

Set against Route_S02.tbl, which schedules phase-1 arrivals at t = 90, 120, 170, 210, 240 in groups of 3, 3, 3, 2, 1, this is now a strong negative rather than a null result. Three readings survive:

1. The timetable's t is not seconds. At 30 Hz the whole phase-1 schedule completes inside 8 s — before any probe's first sample — and everything that was going to arrive already had.
2. Arrivals are event-gated and no run supplied the trigger. The control run supplied nothing at all; the piloted runs killed 16–20 craft, which may be below a threshold or of the wrong squadrons.
3. The mission is not advancing its phase clock, so no schedule ever fires.

❔ The prime suspect is now (3), and it is untested

Nothing in six runs has confirmed that mission or phase time is advancing at all. The craft count is frozen without a pilot; REMAINING OB has never read as a counter; no clock has been located. Every "no arrival" observation is consistent with a mission whose scheduler is simply not running under these conditions — and that possibility has never been checked, which makes it the cheapest thing to eliminate next.

Next: find the mission timer. The HUD shows elapsed mission time, so a digit-recognition read of the clock region, or a memory scan for a counter that advances at a fixed rate, would settle whether phase time moves. If it does not, every arrival conclusion so far is measuring a stopped clock.

---

Long run: a squadron ground 18 → 2, still no arrival (2026-08-24)

Status: ✅ per-record tracking works and resolves individual squadrons; 🔴 the frame-rate "runs were too short" explanation is weakened; 🟡 a sharper event-gating hypothesis now has a specific test.

✅ The instrument works — one squadron watched down to 2

240 s with the hunting pilot, sampling every ~15 s:

t= 54s  loss  UN_e007_ADAN_Turret  18 -> 14
t= 89s  loss  UN_e007_ADAN_Turret  14 -> 12
t=106s  loss  UN_e007_ADAN_Turret  12 -> 10
t=124s  loss  UN_e007_ADAN_Turret  10 ->  8
t=139s  loss  UN_e007_ADAN_Turret   8 ->  6
t=172s  loss  UN_e007_ADAN_Turret   6 ->  4
t=209s  loss  UN_e007_ADAN_Turret   4 ->  2

Seven loss events, all on the same record, tracking one squadron's strength from 18 down to 2 while deployed held at 41 and the global craft count fell 300 → 284. This is the squadron-resolved signal the last several iterations were building toward, and it behaves exactly as the link predicts.

Losses come in steps of 2 (after an opening −4), which is unexplained and worth noting rather than smoothing over.

🔴 The frame-rate explanation is weakened

mission-clock-advances.md proposed that six empty runs were simply too short: at ~16.5 fps against a 30 Hz tick, game time runs at about 55 % of wall-clock, so t = 90 and t = 120 of the route timetable would land at roughly 163 s and 218 s wall.

This run reached 234 s wall ≈ 129 game-seconds, passing both. No arrival occurred at either point. So "the runs were too short" no longer covers t = 90 and t = 120, though it still covers t = 170, 210 and 240.

The run was cut at 240 s rather than the planned 330 s — the turn's timeout fired first. Stated plainly because it means t = 170 was never reached.

🟡 A sharper hypothesis, with a clean test

The squadron ended the run at 2 craft, not 0. If arrivals are event-gated as the user proposed, the trigger may be a squadron being eliminated rather than merely damaged — and no squadron has ever reached zero in any run. That fits every observation so far: seven kills produced no arrival because they never finished anything off.

Test: run long enough for that turret squadron to reach 0 and watch whether a 0 → n follows within the next samples. It fell 18 → 2 in 240 s, so roughly another 60–90 s of the same pilot behaviour should finish it. This is now the cheapest decisive experiment available, and it is a direct test of the event-gated model rather than another null result.

The binding constraint remains the ~210 s title movie at boot, which leaves only about 350 s of observation per turn.

---

Player death bounds every run — and a harness bug (2026-08-24)

Status: 🔴 a harness bug means earlier windows were shorter than reported; ✅ a record reaching 0 was observed for the first time; ✅ after the player dies the mission is completely static, so observation is bounded by survival, not by probe duration; 🔴 the elimination test did not complete.

🔴 Correction: the previous run was not "cut by the turn timeout"

The sed used to derive each session script from the last stripped the probe's arguments, so line 14 of wave5/census/wave6_session.sh invoked the probe with no arguments at all. Every derived probe has been running on its own defaults, ignoring the durations passed on the command line.

So the previous iteration's claim that the run "was cut at 240 s by the turn timeout, not the planned 330 s" is wrong: the probe simply used its default of 240 s. The pilot received the requested 330 s while the probe watched for 240, a mismatch that went unnoticed because the numbers were plausible.

No earlier conclusion is invalidated — the windows were real, just shorter than intended and misattributed. Fixed: all three sessions now pass "$SECS" "$EVERY".

✅ First observed n → 0: the player

t= 83s  loss  UN_f001_TCAF_DeltaSaber_T_Player  2 -> 0
        loss  UN_e007_ADAN_Turret               18 -> 16
        loss  UN_e007_ADAN_Turret               18 -> 14

deployed fell 41 → 40. This is the first time in eight runs that any record has reached zero, and it confirms the signal registers elimination, not just damage.

No arrival followed. That is weak evidence at best against the squadron-elimination trigger, since the record eliminated was the player, not an enemy squadron.

Two other turret records dropped from 18 in the same sample, which is noted without interpretation — it may be the death explosion, or simply three changes landing in one 13 s bucket.

✅ The real constraint: nothing happens after the player dies

For the remaining 220 seconds the mission was frozen: craft held at exactly 288, zero losses, zero arrivals, across 18 consecutive samples.

That reframes every run in this file. The usable observation window is not the probe duration — it is however long the player survives. A 340 s probe that loses its pilot at 83 s yields 83 s of evidence and 257 s of nothing. Several earlier "no arrivals over 240 s" results may have been much shorter in practice than they appear.

It also explains why pilot.py was written to survive rather than to shoot: the SYLPH_HUNT=1 mode added two iterations ago drops TURRET_KEEPOUT from 2500 to 600, which buys kills at the cost of exactly the survival the run depends on.

🔴 The elimination test did not complete

The target squadron reached 14, not 0, before the pilot died. The test — does wiping out an enemy squadron release a wave — remains unrun.

What is needed

A pilot that kills and survives. The two existing modes sit at opposite extremes: survival mode kills nothing in 240 s, hunt mode kills steadily and dies at 83 s. A middle setting — hunt turrets but keep the evade/retire behaviour, or a keep-out between 600 and 2500 — is the obvious next step, and it is a tuning change rather than a new discovery.

---

✅ The elimination test ran — and refutes the elimination trigger (2026-08-24)

Status: ✅ an enemy squadron was wiped out and observed; 🔴 no arrival followed, so "a wave is released when a squadron is eliminated" is refuted for this case; ✅ the keep-out tuning gave a surviving pilot that still kills; 🔴 the guest stalled late in the run, which bounds the valid window and is now detected automatically.

✅ The tuning worked

SYLPH_KEEPOUT makes the hunt keep-out a knob rather than a hard-coded 600. At 1400 the pilot both kills and survives — hull 1500 and escorted asset 100 % for the entire run, ENGAGE throughout, 8 loss events against 7 in the run where it died at t = 83 s.

✅ An enemy squadron reached zero

t= 30s  loss  UN_e007_ADAN_Turret       18 -> 10
t= 44s  loss  UN_e007_ADAN_Turret       10 ->  8
t= 96s  loss  UN_e007_ADAN_Turret        8 ->  4
t=124s  loss  UN_e007_ADAN_Turret        4 ->  2
t=150s  loss  UN_e010_ADAN_Attacker_S    8 ->  6
t=163s  loss  UN_e007_ADAN_Turret        2 ->  0     <-- ELIMINATED, deployed 41 -> 40
t=176s  loss  UN_f106_TCAF_Destroyer     4 ->  2
t=202s  loss  UN_e007_ADAN_Turret       18 -> 16

An enemy squadron destroyed outright, for the first time in nine runs.

🔴 No arrival followed — the elimination trigger is refuted

ARRIVALS=0 at every sample, including all of those after t = 163. The hypothesis from the previous iteration — that a wave is released when a squadron is wiped out rather than merely damaged — does not survive its first test.

The window matters and is smaller than it looks: valid observation after the elimination is about 90 seconds, not the 143 s the log appears to show, for the reason below. Within that 90 s two further losses occurred (t = 176, t = 202), so the mission was demonstrably still live and still processing kills — it simply produced no arrival.

This refutes elimination-of-one-squadron as the trigger. It does not refute event-gating generally: a threshold across several squadrons, an objective completion, or a specific squadron could all still be the gate.

🔴 The guest stalled at ~t = 255 s, and flat samples look identical to a quiet mission

The pilot's own telemetry gives it away: the last 400 log lines contain one distinct speed value, against 236 in the first 400, with no timestamp gaps. The process kept logging; the game stopped advancing.

Every sample after roughly t = 255 s is therefore a frozen guest, not a quiet mission — and nothing in the probe's output distinguished the two. The same ambiguity affects any earlier run's trailing flat samples.

Fixed: wave6_probe.py now locates a counter that advances at frame rate (the technique from mission-clock-advances.md), samples it every tick, and prints *** GUEST STALLED *** when it fails to advance. This makes every future run self-validating. It is implemented but has not yet run, so it is unverified.

What is still open

• Whether any event gates arrivals — elimination of a single squadron is out, but thresholds, objectives and specific squadrons are untested.
• Whether an arrival is observable at all. Nine runs, zero 0 → n.
• Re-examining earlier "flat" results now that a stall and a quiet mission are known to look the same.

---

The first apparent arrival is flicker, not a wave (2026-08-24)

Status: 🔴 the single 0 → 2 observed on the cheap probe is not accepted as an arrival; ✅ the reason is visible in the same log; ✅ the probe now requires persistence.

The first run with cheap sampling reported one arrival:

t=229s  loss  UN_e007_ADAN_Turret  1 -> 0
t=259s  ARRIVAL UN_e007_ADAN_Turret  0 -> 2
t=274s  loss  UN_e007_ADAN_Turret  2 -> 0

Two craft appearing and vanishing again within 15 s is not what a wave looks like. The same log contains the giveaway: at t = 60 s a record read 13, and at t = 75 s the same record read 14 — an increase — with no event printed, because the probe only surfaced decreases. The hull-based liveness read flickers, and a flicker that happens to straddle zero is indistinguishable from an arrival under the old rule.

So the count is 0 confirmed arrivals, in eleven runs.

The rule this produces

An increase from zero counts only if it persists across two consecutive samples, and every increase is now printed, not just those from zero. A candidate that returns to zero at the next sample is discarded as flicker. Both changes are in wave7_probe.py; neither has run yet.

Had the old rule stood, this run would have been written up as "first arrival observed" — the strongest-looking result of the whole line of work, and wrong.

---

Run 12: the persistence rule does its job (2026-08-24)

16 losses over 290 s with a bound pilot, and:

TOTAL candidate-up=0 down=16 CONFIRMED arrivals=0

One increase was surfaced — UN_e007_ADAN_Turret 13 -> 15 — and correctly not counted, because it does not start from zero. Under the pre-fix rule it would have been invisible; under the old arrival rule a similar flicker straddling zero was nearly written up as the first arrival. The new "print every increase" behaviour makes the flicker visible as flicker.

Still zero confirmed arrivals, now across twelve runs.

Caveat on this run: its 13 "stalled" flags are false positives from the single-word witness (see guest-stalls.md), so the run was healthy — but that also means the witness cannot yet certify it.

---

Run 16: the first trustworthy negative (2026-08-24)

Every previous "no arrival" result carried a caveat — a stalled guest, an unvalidated witness, a probe degrading the thing it measured. This one does not:

• the stall witness is validated (zero contradictions with loss data);
• it reported no stall on any sample;
• the guest was demonstrably live throughout — 8 losses spread across the run;
• the run ended on the turn timeout, not a freeze.

Result: 0 confirmed arrivals over 210 s of verified-live Stage 02 flight.

That is the first observation in this line of work that means what it says. It does not settle the question — 210 s of wall-clock is roughly 115 s of game time at the measured frame rate, so the route table's t = 170/210/240 entries are still out of reach — but it does establish that nothing arrives in the first ~115 game-seconds of Stage 02 phase 1 while the player kills eight craft.

One flicker up was surfaced and correctly not counted.

Sixteen runs, still no arrival. The difference is that this one is evidence.

---

Run 17: the clean result reproduces, and the window is being eaten by startup

✅ Reproduced (n = 2)

tick witnesses: 4584 candidates, using 32 at 11/s
t=  0s … t=240s   no stall flag on any sample
9 losses, 4 flicker `up` events (none from zero), 0 confirmed arrivals

Second consecutive run with no stalls, confirming that disabling the periodic rescan is what fixed the freezes. The trustworthy negative now extends to 240 s of verified-live flight ≈ 132 game-seconds, past the route table's t = 90 and t = 120 entries with nothing arriving.

Four increases were surfaced and all correctly rejected — the flicker rate is substantial, roughly one per minute, which is exactly why the persistence rule matters.

🔴 Startup costs ~100 s of a ~350 s budget

The arithmetic does not add up unless something slow sits between them: boot finished at 249 s, the probe ran 240 s, and the turn's 595 s cap fired. That leaves about 100 s unaccounted for — the witness calibration plus the initial craft enumeration.

enumerate_craft was iterating every 4-byte word of 32 MB in Python, 8 million steps, to find 14 fixed needles. Replaced with bytes.find() per definition VA, which is the same search at C speed and is what the vtable scan already did.

If that recovers most of the 100 s, the observation window grows from ~240 s to ~340 s — about 187 game-seconds, which would finally reach the t = 170 route entry. Not yet run.