95535d09da
The incremental-save fix is verified. A fresh mission caught one e010 event at t=241 s and wrote 1187 candidates to disk immediately; the turn timeout then fired exactly as before, but this time the data survived. The session also clears the candidate file at launch, since candidate offsets are only meaningful within one emulator instance and resuming across launches would intersect unrelated addresses. The correlation itself was wrong though. It matched on the delta alone, so any two float bit patterns whose integer representations differ by the loss count qualified, and in a heap full of positions and velocities that is thousands of words. The 1187 survivors were things like 1044450858, about 0.1f, and 3212461993, a negative float. Candidates must now also look like a counter -- a small non-negative integer in both samples -- which removes the noise by construction instead of hoping the intersection washes it out. The follow-up attach logged zero events across 520 s, which reads like the combat-effectiveness limit again. It was not: 25 of its 26 samples were flagged GUEST STALLED, so the guest was frozen for essentially the whole window. The witness added last iteration did its job, and the lesson is about reading it -- the run summary quoted "0 events" first and the stall count only surfaced on a deliberate check. A run's witness result should be the first thing looked at, before any interpretation of what the run showed. Still unfinished, with no address identified. What is needed is unchanged, two or three e010 kill events in non-stalled samples, and the two obstacles are now clearly separate: the freeze rate, and a pilot that manages about two marked-fighter kills per five minutes.
6.6 KiB
Executable File
6.6 KiB
Executable File