f6f8930ee7
The objective text settles what the counter is, so the hunt can be a correlation rather than a value scan: keep every word in the 32 MB heap that fell by the same amount, in the same interval, as a named e010 loss. One event cut roughly eight million words to 1056, so two or three more should leave a handful. The run did not get them. 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 and the follow-up attach started from nothing. That is the same mistake already recorded in guest-stalls.md, where an earlier probe deferred all analysis to the end and a timeout killed it with 240 s of data in memory and nothing written. The lesson was written down and then repeated in a new script four iterations later. The attach had a second gap: 535 s with zero losses of any kind, which is indistinguishable from a freeze, and ob_probe2 carried no stall witness so the run cannot say which it was. Both are fixed. Candidates are written after every event and SYLPH_OB_RESUME=1 reloads them so a chained attach keeps intersecting on the same mission, and the witness from wave7_probe is carried here. The underlying pattern is worth naming: each new probe starts from scratch and re-earns the same lessons about saving incrementally and validating liveness. A shared probe harness would stick where written-down lessons have not. The hunt itself is unfinished. No address is identified, and finishing needs a run that catches two or three marked-fighter kills, which is the same combat-effectiveness limit already recorded -- about two per five minutes against a dozen turrets.
64 lines
2.8 KiB
Markdown
64 lines
2.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.
|