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

re: widen the OB scan to seven encodings; run inconclusive, probe lacked a witness

Browse Source 
ob_by_hud.py now scans seven readings of the same bytes and keeps a separate
candidate set for each, as byte offsets: u32 big and little endian, u16 both
endiannesses at both alignments, and u8. The big-endian u32 reading had been
refuted, so widening rather than assuming is the point.

u32le is much the tightest at 154 candidates against u32be's 4452. That is a
hint about the encoding rather than a result, since a rarer bit pattern narrows
faster regardless of meaning.

The run is inconclusive. The HUD read 4 at every sample, so there was no second
value to collapse the sets against, and from t=136 the candidate counts are
byte-identical across five samples in all seven encodings, which is what a
frozen guest looks like -- nothing in 32 MB changed at all. The probe had no
stall witness, so the run cannot prove it either way. One is added now.

Worth stating plainly: this is the fourth probe written without a witness and
the third whose flat output could not be distinguished from a freeze. Each time
the fix gets applied to that one script. The durable fix is the shared probe
harness already noted in this file, and the lesson recurring four times is
itself the argument for building it.

What the hunt needs is unchanged: two HUD readings at different values in
non-stalled samples. The counter moves on kills, which lands back on the combat
limit, though the earlier 4 to 11 observation shows it does move.
This commit is contained in:
Sylpheed RE agent
2026-08-24 23:14:59 +00:00
parent 696119b9e6
commit a040cad0da
3 changed files with 117 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -215,3 +215,46 @@ kill-driven route it costs no combat.
Also worth extending `ob_digits.png` with the missing digits — most samples were
unreadable, which is why only two data points survived a 480 s run.
---
# Widened to every plausible encoding (2026-08-24)
`ob_by_hud.py` now scans seven readings of the same bytes and keeps a separate
candidate set for each, expressed as byte offsets:
`u32be`, `u32le`, `u16be`, `u16be@1`, `u16le`, `u16le@1`, `u8`.
First run, HUD showing **4** throughout:
```
t= 7s u32be:6285 u32le:414 u16be:10668 u16be@1:2718 u16le:656 u16le@1:9012 u8:25559
t=110s u32be:4472 u32le:156 u16be: 8794 u16be@1:1386 u16le:286 u16le@1:8124 u8:20381
t=136s u32be:4452 u32le:154 u16be: 8773 u16be@1:1380 u16le:284 u16le@1:8119 u8:20346
t=162s .. t=267s identical to t=136 in every encoding
```
**`u32le` is much the tightest at 154**, an order of magnitude below `u32be`.
That is a hint about the encoding, not a result — a rarer bit pattern narrows
faster regardless of meaning.
## 🔴 Inconclusive, and probably a frozen guest
The HUD read **4** at every sample, so there was no second value to collapse the
sets against. Worse, from t = 136 s the candidate counts are **byte-identical
across five samples in all seven encodings**, which is what a frozen guest looks
like — nothing in 32 MB changed at all.
`ob_by_hud.py` had **no stall witness**, so the run cannot prove it. Added now.
**This is the fourth probe written without a witness and the third whose flat
output could not be told from a freeze.** Each time the fix is applied to that
one script. The durable fix is the shared harness already noted in this file, and
the fact that the lesson keeps recurring is itself the argument for building it.
## What is needed
Two HUD readings at **different** values, in non-stalled samples. The counter
changes on kills, so this lands back on the combat limit — unless a phase change
or another event moves it. The earlier 4 → 11 observation shows it does move,
which is what makes the approach worth continuing.