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.

---

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.

---

🚧 BLOCKER: two of the schedule's entries are unreachable in one turn (2026-08-24)

This should have been computed several iterations ago instead of being approached one run at a time.

A turn's shell call is capped at 595 s. Boot costs ~220 s (a ~190 s title movie that cannot be tapped through plus ~35 s to flight) and probe startup ~25 s, leaving ~350 s of observation. At the measured ~55 % of real-time, that is ~193 game-seconds.

route entry	wall-clock needed	status
t = 90	164 s	✅ reachable — observed, no arrival
t = 120	218 s	✅ reachable — observed, no arrival
t = 170	309 s	✅ reachable, but only on a run that does not freeze
t = 210	382 s	❌ out of reach in one turn
t = 240	436 s	❌ out of reach in one turn

So the tail of Stage 02's phase-1 schedule cannot be tested under the current harness at all, however many runs are attempted. Recorded as a blocker rather than worked around.

What would unblock it, neither of which is mine to decide:

1. Skip the title movie. It is ~190 s of the 220 s boot — more than half the budget — and launch_mission.sh waits it out because tapping breaks the title. If there is a safe skip, the window roughly doubles to ~540 s ≈ 297 game-seconds, which covers every entry including t = 240.
2. A longer shell timeout, if the harness allows it.

This run: discarded

Frozen at t = 90 s, 15 stalled samples, 3 losses. Correctly flagged and not interpreted. Freeze tally is now 3 clean of 5 (210, 240, 300 clean; 60, 90 frozen), lower than the 3-of-4 quoted last iteration.

What stands

0 confirmed arrivals over 300 s of verified-live flight (~165 game-seconds), covering the t = 90 and t = 120 route entries. That is unchanged, and it is the strongest statement this harness can currently support.

---

✅ BLOCKER REMOVED: the emulator survives between calls (2026-08-24)

The previous entry declared t = 210 and t = 240 unreachable because a shell call is capped at 595 s. That was wrong, and it rested on an assumption I never tested: launch_mission.sh leaves the emulator running, and it survives between Bash calls within a turn — checked directly, 611 s elapsed and still running after the launching call had returned.

So observation is not capped by one call. tools/re-capture/attach_session.sh attaches a pilot and probe to an already-running mission, and attaches can be chained.

The result on one continuous mission

segment	window	stalls
initial run	300 s	none
attach	540 s, first stall at t = 135 s	frozen after

Cumulative verified-live: 435 s of wall-clock, during which the craft population fell 300 → 258 (42 destroyed) and deployed fell 41 → 38.

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

0 confirmed arrivals, across the longest verified-live observation yet.

route entry	wall needed	covered?
t = 90	164 s	✅
t = 120	218 s	✅
t = 170	309 s	✅
t = 210	382 s	✅
t = 240	436 s	✗ (one second short)

Four of five phase-1 arrival times passed with nothing arriving while 42 craft were destroyed.

🟡 The coverage claim is sensitive to an assumption

The wall→game conversion uses 55 %, from a ~16.5 /s frame rate against an assumed 30 Hz tick. But the witness has measured 8, 11, 11, 21 and 24 /s across runs — a 3× spread. At the low end the factor is 0.27, and the same 435 s covers only ~117 game-seconds, which would reach t = 90 only.

So the honest statement is: nothing arrived in 435 s of verified-live Stage 02 phase-1 flight with 42 kills, which covers the first four route entries if the game runs at ~55 % of real-time and only the first if it runs at the slowest rate observed. Pinning the tick rate is now the thing that would make this result sharp.

🔴 Refuted: the pilot's poll rate is not what limits frame rate

SYLPH_HZ=3 (down from 8) produced the lowest calibrated rate of any run, 8 /s, alongside the most kills (26). So the pilot's polling is not the throttle, and lowering it is not a way to buy game time. n = 1.

---

🟡 The route times are almost certainly FRAMES — and the "42 anomaly" was Stage 01

✅ The 42-record anomaly is solved: it is a different stage

The rescan-until-baseline retry settled it — five rescans over 50 s, stuck at 42, so not a load race. Inspecting the live mission instead of guessing:

• records include UN_S01_Asteroid_cmesh_01a/01b/02a/… — Stage 01 asteroids;
• UnitGroup_S01.tbl is resident in guest RAM, UnitGroup_S02.tbl is not.

The launch sometimes loads Stage 01 instead of Stage 02. The discard rule caught every one of those runs, which is why they never contaminated a result.

✅ And that supplied the missing refutation test, for free

mission-liveness-probe.md recorded the roster identity as blocked: the obvious check — a different stage's record count against its member sum — needed a save we do not have. Stage 01 loading by accident provides it:

	static (disc)	live (RAM)
members / roster records	42	42
distinct unit types / definitions	13	13
UN_e007_ADAN_Turret	20	20
UN_f001_TCAF_DeltaSaber_T	6	6
UN_e010_ADAN_Attacker_S	5	5
UN_e106_ADAN_Destroyer	2	2

One record per roster member now holds on two independent stages with completely different rosters.

🟡 Stage 01's timetable says the unit is frames, not seconds

Stage 01 phase 1:  t=0:15, t=40:3, t=70:2, t=80:1, t=110:1, t=140:1
Stage 01 phase 2:  t=0:17, t=1500:1, t=1800:3, t=2100:4

t = 2100 as seconds is 35 minutes into a single phase, and 1500/1800/2100 would be three arrivals spread over the last ten minutes of it. That is not a plausible mission. At 30 Hz they are 50, 60 and 70 seconds, which is exactly the shape of a paced phase.

If the unit is frames at 30 Hz, then Stage 02's phase-1 entries at t = 90/120/170/210/240 are 3, 4, 5.7, 7 and 8 seconds — every one of them before the probe's first sample, which lands ~25 s after flight is detected.

That would explain every null result in this file at a stroke, and it is consistent with what the probe has always seen: deployed = 41 already at t = 0 and never changing.

Kept at 🟡: it is an inference from the implausibility of one reading, not a direct measurement. But it is now the leading explanation, ahead of event-gating.

The test that would settle it

Sample within the first seconds of flight, before startup costs, and compare deployed at flight+2 s against flight+30 s. Under the frames reading the count climbs during those seconds and is finished before the current probe ever looks; under any seconds reading it is flat there and climbs later.

That requires the probe's ~25 s of enumeration and calibration to happen after a first cheap sample, which is a reordering rather than new decoding.

---

Sampling from the first moment (2026-08-24)

✅ Setup cost cut from ~25 s to ~0.5 s

early_probe.py defers everything expensive: no witness calibration (two 32 MB reads), no per-record labelling, and the heap scan uses bytes.find. Setup completes in 0.5–0.8 s, so the first sample lands essentially at flight detection instead of 25 s after it.

🔴 Still flat: deployed is 41 at flight+0.8 s and never climbs

+  0.8s  deployed= 41  craft=298
+  2.1s  deployed= 41  craft=298
   … every sample to +252s …
+252.0s  deployed= 40  craft=282

The only change in 252 s is 41 → 40, one squadron wiped out. No climb at any point, so no arrival is observable from flight detection onward — which under the frames reading is expected, since the whole phase-1 schedule would be over within 8 s of mission start.

🔴 A flaw in the --wait variant: it caught the ready room

To get ahead of flight detection, a second run started the probe before the launch and waited for the roster to appear. It did appear — 116 records — but the numbers were deployed = 39, craft = 276, flat for the whole 200 s window.

That is not the mission. The roster is built before take-off, so waiting for it catches the READY ROOM, and the probe's window expired around the time flight actually began. Waiting for the roster is not the same as catching mission start, and the test as designed does not do what it claims.

🟡 But the two runs together suggest deployment happens at take-off

state	deployed	craft
ready room	39	276
in flight (from t+0.8 s onward)	41	300

Two more records and 24 more craft appear between the ready room and flight. These are different runs, so this is suggestive rather than measured — but it points at deployment being a single step at take-off rather than a schedule unfolding during the mission.

Next: one run with the probe waiting for the roster and sampling for ~400 s, long enough to span ready room → take-off → flight in a single continuous series. That would show the 39 → 41 step directly, or refute it.