222f35a7a7
The previous iteration declared route entries 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 checked: launch_mission.sh leaves the emulator running and it survives between Bash calls within a turn. Verified directly -- 611 s elapsed and still running after the launching call had returned. attach_session.sh attaches a pilot and probe to an already-running mission, and attaches chain, so the window is bounded by the turn rather than by one call. On one continuous mission: 300 s of clean observation followed by an attach that ran 135 s before freezing, giving 435 s of cumulative verified-live wall-clock. The craft population fell from 300 to 258, so 42 were destroyed, and deployed fell 41 to 38. Zero confirmed arrivals throughout -- the longest verified-live observation so far. That covers the first four phase-1 route entries, t=90, 120, 170 and 210; t=240 needs 436 s and was missed by a second. The coverage claim is qualified rather than asserted. The wall-to-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 per second across runs. At the low end the factor is 0.27 and the same 435 s covers only about 117 game-seconds, reaching t=90 alone. So what is established is that nothing arrived in 435 s of verified-live phase-1 flight with 42 kills; how many scheduled arrival times that spans depends on a tick rate that is not yet pinned, and pinning it is what would make the result sharp. Also refuted: SYLPH_HZ=3, a lower pilot poll rate, produced the lowest calibrated frame rate of any run at 8/s while landing the most kills at 26. The pilot's polling is not the throttle and lowering it does not buy game time.
1.2 KiB
Executable File
1.2 KiB
Executable File