Syplheed-Reborn/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.