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.
114 lines
4.8 KiB
Markdown
114 lines
4.8 KiB
Markdown
# Hunting REMAINING OB by correlation — method works, run did not finish
|
|
|
|
Status: ✅ the correlation method is sound and demonstrated; 🔴 the hunt is
|
|
**unfinished**; 🔴 two self-inflicted defects, one a repeat.
|
|
|
|
## The method
|
|
|
|
[mission-phase-objectives.md](mission-phase-objectives.md) settles what the
|
|
counter is: Stage 02 phase 1 asks to *"shoot down all invading enemy fighters"*
|
|
and the hints say red **[OB]** markers indicate the targets. So `REMAINING OB`
|
|
must fall when a marked fighter dies — and the per-record craft strength already
|
|
says exactly when that happens, for a *named* unit.
|
|
|
|
So instead of scanning for a value, intersect: keep every word in the 32 MB heap
|
|
that fell by the same amount, in the same interval, as an `e010` loss. Each kill
|
|
event should cut the survivor set hard.
|
|
|
|
`tools/re-capture/ob_probe2.py`.
|
|
|
|
## ✅ It works — one event cut 8 million words to 1056
|
|
|
|
```
|
|
t= 219s e010 losses=2 (all=4) words falling by 2: 1056 -> candidates 1056
|
|
```
|
|
|
|
From ~8 M candidate words to **1056** on a single event. Two or three more should
|
|
leave a handful.
|
|
|
|
## 🔴 The run did not finish, and the candidates were lost
|
|
|
|
The turn's timeout fired at t = 219 s, and the probe saved its candidate set
|
|
**only at the end** — so the 1056 were discarded. The follow-up attach then
|
|
started from nothing.
|
|
|
|
**This is the same mistake already recorded in
|
|
[guest-stalls.md](guest-stalls.md)**: "the first attempt deferred all analysis to
|
|
the end of the run, and the turn's timeout killed it with 240 s of collected data
|
|
still in memory and nothing written." I wrote that lesson down and then repeated
|
|
it in a new script four iterations later.
|
|
|
|
Fixed: candidates are now written to `/tmp/ob_candidates.json` **after every
|
|
event**, and `SYLPH_OB_RESUME=1` loads them so a chained attach keeps
|
|
intersecting on the same mission.
|
|
|
|
## 🔴 The attach could not tell a quiet mission from a frozen one
|
|
|
|
The follow-up attach logged **535 s with zero losses of any kind**. That is
|
|
exactly what a freeze looks like, and `ob_probe2` had no stall witness, so the
|
|
run cannot say which it was. Also fixed — the witness from `wave7_probe` is now
|
|
carried here.
|
|
|
|
Two defects in one iteration, both of them things this corpus had already
|
|
learned. The pattern is that each new probe starts from scratch and re-earns the
|
|
same lessons; the fix that would actually stick is a shared probe harness rather
|
|
than a family of one-off scripts.
|
|
|
|
## What is still open
|
|
|
|
The hunt itself. The method is demonstrated but no address is identified. What it
|
|
needs is a run that catches **two or three** `e010` kill events, which is the same
|
|
combat-effectiveness limit recorded in
|
|
[mission-objectives-text.md](mission-objectives-text.md) — the preference knob
|
|
gets about two marked-fighter kills per five minutes against a dozen turrets.
|
|
|
|
---
|
|
|
|
# Second attempt: saving works, the filter was wrong (2026-08-24)
|
|
|
|
## ✅ Incremental saving works
|
|
|
|
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 it. The fix from the previous iteration is verified.
|
|
|
|
The session also now clears `/tmp/ob_candidates.json` at launch: candidate
|
|
*offsets* are only meaningful within one emulator instance, so resuming across
|
|
launches would intersect unrelated addresses.
|
|
|
|
## 🔴 The correlation had no value filter, and the survivors were floats
|
|
|
|
The 1187 survivors are not counters:
|
|
|
|
```
|
|
va 0xbd0a42b8 value 1044450858 (~0.1f)
|
|
va 0xbd140bc0 value 3200164558 (a negative float)
|
|
va 0xbd14a120 value 3212461993
|
|
```
|
|
|
|
The filter matched on the **delta** alone, so any two float bit patterns whose
|
|
integer representations differ by exactly `lost` qualified. In a 32 MB heap full
|
|
of positions and velocities that is thousands of words.
|
|
|
|
Fixed: candidates must also *look like a counter* — a small non-negative integer
|
|
(`0 ≤ v < 1000`) in both samples. That removes float noise by construction rather
|
|
than hoping the intersection washes it out.
|
|
|
|
## 🔴 The attach was frozen, and the witness said so
|
|
|
|
The follow-up attach logged **0 events across 520 s**, which reads like the
|
|
combat-effectiveness limit again. It was not: **25 of its 26 samples were flagged
|
|
`GUEST STALLED`**. The guest was frozen for essentially the whole window.
|
|
|
|
The witness added last iteration did its job. The lesson is about reading it —
|
|
the run summary quoted "0 events" first and the stall count only turned up 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
|
|
|
|
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 the pilot managing roughly two marked-fighter kills per five
|
|
minutes.
|