fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: the REMAINING OB address does not survive a run - refuted twice over

Browse Source 
0xbdb59668 reads 0 in two independent Stage 02 runs while the HUD counts
004 -> 008 -> 012. Not an unmapped read: SEEK_DATA at that offset returns the
offset itself and the next hole is 5 MB later, so it is an allocated,
zero-filled word. The address was a per-run artefact, exactly as that file
already suspected it might be; the method is the durable result.

Re-finding it in the new run also failed, and both failures are recorded because
they are the instructive part. Two candidates were produced and both died on the
corpus's own rule -- verify across a transition you did not select on:
0xbc2377dc went 12 -> 18 while the HUD stayed 012 and read 3 two minutes later,
and 0xbd295b04 was plain noise.

One correction to the method note in that file: the scan is not slow. Over the
live /dev/shm image it takes 0.9 s. The real trap is that REMAINING OB climbs
004 -> 012 within about four minutes as waves spawn, so a scan is only valid if
the HUD is confirmed to hold the same value immediately before AND after it --
which is why the earlier 4-then-8 intersection came back empty.

What blocked finishing: with pilot.py retired at hull 340/1500 nothing was
killing objectives and the counter sat at 012 for five minutes, so there was no
later transition to filter on. What the counter counts, and whether an OB-badged
entity carries a flag, is untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-23 17:16:07 +00:00
parent c905b3b6ad
commit d412347c37
3 changed files with 93 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
docs/re/structures/mission-objective-counter.md
View File

@@ -58,3 +58,52 @@ evidence; the same offset tracking a *later*, unselected change is.
the natural follow-on — and it is what the pilot actually needs to *choose*
targets rather than merely know how many are left.
* ❔ Whether the same address holds for other stages.
## 🔴 2026-08-23 — cross-run stability: **REFUTED**
`0xbdb59668` does **not** repeat. A second Stage 02 run on the same baseline
(rebuilt per [`../dynamic-re-state-restore.md`](../dynamic-re-state-restore.md))
reads **0** at that address for the whole mission while the HUD counts up:
| HUD | RAM `0xbdb59668` |
|---|---|
| `004` (t+18 s, flight entry) | 0 |
| `008` | 0 |
| `012` (held for ~5 min) | 0 |
A **second, independent** run of the same mission repeats it: at `TIME 01:08.96`
with the HUD on `REMAINING OB 004`, the word is again **0**
([`../captures/stage02-inflight-run2-ob-address-zero.png`](../captures/stage02-inflight-run2-ob-address-zero.png)).
Read three times back-to-back at `004` — all zero — and `±64 bytes` around it are
zero too. The page is **not** a sparse hole (`SEEK_DATA` at the offset returns the
offset itself; the next hole is 5 MB later), so this is an allocated,
zero-filled word, not an unmapped read. The number was a **per-run artefact**, as
this file already suspected; the method is the durable part, and every future
session must re-scan.
**And re-finding it in the new run failed too — recorded because both failures
are instructive.** Two candidates were produced and both were killed by the
"verify across a transition you did not select on" rule:
* `0xbc2377dc` — held 12 at selection, then went 12 → 18 while the HUD stayed
`012`, and was reading **3** two minutes later at HUD `012`.
* `0xbd295b04` — read 12 once, then 0, 21, 54, 46, 4 in the next 50 s. Noise.
🔴 **A correction to this file's own method note.** The trap is *not* that the
scan is slow: `ob_scan.py scan` over the live `/dev/shm` image takes **0.9 s**
(9 555 hits at value 12; the SEEK_DATA extent walk skips the sparse 4.6 GB). The
real trap is that **`REMAINING OB` climbs fast early in Stage 02** — `004` → `008`
→ `012` inside about four minutes as waves spawn — so a scan is only valid if the
HUD is confirmed to hold the same value **immediately before and after it**. The
earlier `4 ∩ 8` intersection here came back with no survivor for exactly that
reason: the value-8 scan was actually taken at 12.
**What blocked finishing it:** with the pilot in `RETIRE` (hull 340/1500) nothing
was killing objectives, and the counter sat at `012` for five minutes — no
transition to filter on. A run that intends to find this address needs a pilot
that is still *engaging*, which is the same constraint
[`../autopilot-memory-driven.md`](../autopilot-memory-driven.md) records.
**Unchanged and still open:** what the counter counts, and whether an `OB`-badged
entity carries a flag in its entity object. Nothing in this pass touched that.