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

re: REMAINING OB found and verified — big-endian u32 at 0xbdb59668

Browse Source 
Ported onto the shared harness, the HUD changed from 4 to 8 and the intersection
collapsed in a single step: one u32be survivor at 0xbdb59668, with the u16be and
u8 hits at 0xbdb5966a and 0xbdb5966b being the low half and low byte of that same
word.

Verified live rather than asserted. Reading screenshot and memory together three
times, the one legible HUD frame showed 012 against mem@0xbdb59668 = 12; the
other two frames were unreadable rather than mismatched. This independently
rediscovers the address the earliest sessions found by digit-transition hunting,
by a completely different method.

It also corrects an earlier conclusion. A previous run intersected HUD readings
of 4 and then 11, got zero survivors in every encoding, and that was written up
as eliminating big-endian u32 for the whole region. This run shows u32be holds
the counter, so the refutation was wrong. The likely cause is the input:
ob_digits.png has templates for 0 1 2 4 8 only, so values containing other
digits are misread rather than rejected, and "11" was probably one of those. A
single bad reading poisons an intersection permanently, because it removes the
true address and nothing later can restore it. The lesson is that an
intersection method needs individually verifiable inputs -- the reader's
confidence scores were printed but never gated on.

One observation reopens the arrival question in a useful way: the counter
increases, 4 then 8 then 12 across about five minutes, measured in memory so not
a digit misread. A count of remaining marked targets that rises means targets
are being added during the mission. That does not contradict the deployment
finding, since the roster is fixed at load, but it does mean the game marks new
objective targets as the mission proceeds. Watching this one address across a
whole mission is now the obvious next experiment and costs almost nothing.
This commit is contained in:
Sylpheed RE agent
2026-08-25 05:40:30 +00:00
parent 3355ce9198
commit 4142438ae8
5 changed files with 220 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -258,3 +258,73 @@ 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.
---
# ✅ FOUND AND VERIFIED: `REMAINING OB` is a big-endian u32 at `0xbdb59668`
## The run
Ported onto the shared harness (`ob_hunt2.py`), the HUD changed **4 → 8** and the
intersection collapsed in one step:
```
t=126s HUD=4 u32be:8717 u32le:163 u16be:13844 u16be@1:3319 u16le:832 u8:36635
t=191s HUD=8 u32be:1 u32le:0 u16be:1 u16be@1:2 u16le:0 u8:3
t=254s HUD=8 (unchanged)
```
Resolving the survivor:
| encoding | address |
|---|---|
| **`u32be`** | **`0xbdb59668`** |
| `u16be` | `0xbdb5966a` — the low half of the same word |
| `u8` | `0xbdb5966b` — the low byte of the same word |
All three are the same location. The `u16be@1` pair and the other `u8` hits are
elsewhere and did not survive as a coherent field.
## ✅ Verified live against the HUD
Read three times, twenty seconds apart, screenshot and memory together:
```
HUD='0?2' mem@0xbdb59668 = 12 (HUD frame unreadable)
HUD='012' mem@0xbdb59668 = 12 MATCH
HUD='???' mem@0xbdb59668 = 12 (HUD frame unreadable)
```
The one legible frame agrees exactly. **`REMAINING OB` is a big-endian `u32` at
`0xbdb59668`** — independently rediscovered by value-intersection, and landing on
the same address the earliest sessions found by digit-transition hunting.
## 🔴 Correction: the earlier "big-endian u32 refuted" was wrong
An earlier run intersected HUD readings of 4 and then **11** and got zero
survivors in every encoding, which was written up as eliminating `u32be` for the
whole region. This run shows `u32be` holds the counter.
The likely cause is the reading itself: `ob_digits.png` only has templates for
**0 1 2 4 8**, so any value containing 3/5/6/7/9 is misread rather than rejected,
and "11" was probably one of those. A single bad reading poisons an intersection
permanently — it removes the true address and nothing later can bring it back.
**Lesson: an intersection method needs its inputs to be individually verifiable.**
The HUD reader's confidence scores were printed but never gated on; a minimum
score would have dropped the bad frame instead of trusting it.
## 🟡 The counter *increases*: 4 → 8 → 12
Across roughly five minutes the value went 4, then 8, then 12 — measured in
memory, so not a digit misread. A counter of *remaining* marked targets that
rises means **targets are being added during the mission**.
That is the arrival question again, and now with a cheap, reliable, one-word
signal instead of a 32 MB scan. It does not contradict
[mission-phase-deployment.md](mission-phase-deployment.md) — the roster's
deployment is fixed at load — but it does mean the game *marks* new objective
targets as the mission proceeds.
Watching this one address across a mission is now the obvious next experiment,
and it costs almost nothing.