a884c62098
Correction first. The sed used to derive each session script from the last stripped the probe's arguments, so wave5, census and wave6 sessions invoked their probes with no arguments and every derived probe has been running on its own defaults. The previous iteration's claim that the run was "cut at 240 s by the turn timeout, not the planned 330 s" is therefore wrong: the probe used its default of 240. The pilot got the requested duration while the probe watched for a different one, and the numbers were plausible enough that it went unnoticed. No earlier conclusion is invalidated -- the windows were real, just shorter than intended and misattributed. All three sessions now pass SECS and EVERY. First n -> 0 ever observed: the player's own record went 2 -> 0 at t=83 s and deployed fell 41 to 40. The signal does register elimination, not just damage. No arrival followed, which is weak evidence against the squadron-elimination trigger since the record eliminated was the player rather than an enemy squadron. Two other turret records dropped from 18 in the same sample; noted without interpretation. The important finding is what came after. For the remaining 220 seconds the mission was frozen -- exactly 288 craft, zero losses, zero arrivals, across 18 consecutive samples. So the usable observation window is not the probe duration but 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, and several earlier "nothing over 240 s" results may have been much shorter in practice than they look. That also explains why pilot.py was written to survive rather than to shoot. The SYLPH_HUNT mode added two iterations ago drops TURRET_KEEPOUT from 2500 to 600, buying kills at the cost of exactly the survival the run depends on. The elimination test itself did not run: the squadron reached 14, not 0, before the pilot died. What is needed is a pilot that kills and survives -- hunt turrets but keep the evade and retire behaviour, or a keep-out between the two extremes. That is tuning, not discovery.
9.2 KiB
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:
- The timetable's
tis 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. - 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.
- 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.