fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: OB correlation method proven; turret tracking refuted

Browse Source 
With the value filter in place, an attach watching turret losses -- frequent,
unlike marked-fighter kills -- narrowed from 374 candidates to 2 to 0 across
three events. That is exactly how a correlation search should behave, and it
ends in a refutation rather than fizzling out: no plain u32 in the entity heap
decrements consistently with turret kills.

Witness checked first, per the rule adopted last iteration: 12 of 25 samples
stalled, but all four kill events fall in the early non-stalled stretch between
t=45 and t=177, so the events themselves are sound.

The negative fits the objective text rather than contradicting it. Stage 02
phase 1 asks to shoot down all invading enemy fighters, and turrets are not
fighters, so a counter of remaining marked targets should not move when a turret
dies. It also rules out the cheaper reading that REMAINING OB is a general kill
or enemy-remaining tally: it ignored ten turret deaths.

The method is proven and the search region is right, since 0xbdb59668 where the
counter was originally seen lies inside the scanned range. What is missing is
unchanged -- two or three e010 kill events in non-stalled samples -- against the
same two obstacles, the freeze rate and a pilot managing about two
marked-fighter kills per five minutes. One clean 220 s run this iteration
produced zero.
This commit is contained in:
Sylpheed RE agent
2026-08-24 22:39:59 +00:00
parent 3be3628468
commit 45f31d69bd
2 changed files with 55 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
docs/re/remaining-ob-hunt.md
View File

@@ -111,3 +111,48 @@ 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.
---
# ✅ The method narrows hard — and refutes turret tracking (2026-08-24)
With the value filter in place, an attach watching **turret** losses (which are
frequent, unlike marked-fighter kills):
```
t= 45s e007 losses=2 words falling by 2: 374 -> candidates 374
t=134s e007 losses=4 words falling by 4: 1001 -> candidates 2
t=156s e007 losses=2 words falling by 2: 526 -> candidates 0
```
**374 → 2 → 0.** That is exactly the behaviour a correlation search should show,
and it ends in a refutation rather than fizzling out:
> **No plain `u32` in `0xBD000000–0xBE000000` decrements consistently with turret
> kills.**
Witness first, as the rule now says: 12 of 25 samples stalled, but **all four kill
events fall in the early non-stalled stretch** (t = 45–177 s), so the events
themselves are sound.
## 🟡 The negative fits the objective text
This is what the objective text predicts. Stage 02 phase 1 asks to *"shoot down
all invading enemy **fighters**"*, and turrets are not fighters — so a counter of
remaining marked targets **should not** move when a turret dies. The refutation is
evidence *for* the reading in
[mission-phase-objectives.md](mission-phase-objectives.md), not against it.
It also rules out the cheaper alternative reading, that `REMAINING OB` is a
general kill or enemy-remaining tally. It is not: it ignored ten turret deaths.
## What this leaves
The method is proven and the search region is right — `0xbdb59668`, where the
counter was originally seen, is inside the scanned range. What is missing is
still **two or three `e010` kill events in non-stalled samples**, and the same
two obstacles: the freeze rate, and the pilot's ~2 marked-fighter kills per five
minutes.
One clean 220 s run this iteration produced **zero** `e010` kills, which is the
limit stated plainly.