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

re: correct my own OB write-up -- I refuted a stale status line, not an open question

Browse Source 
The section I added last iteration claimed to be testing an untested 🟡 and
concluded "the address is run-dependent, always re-derive".  Both halves were
wrong, and the evidence was already further down the SAME file:

 - cross-run stability was not untested -- the body records 0xbdb59668 carrying
   the counter in 3 of 5 measured runs and reading a hard 0 in the other two.  The
   stale claim was in the status line at the top, which I took at face value.
 - "always re-derive" is worse advice than the rule the file already gives: try
   0xbdb59668 first, check it against the HUD, re-scan only when it reads 0.

What my run genuinely adds is a SIXTH data point with a new failure mode: the
address read neither the counter nor 0 but 95748078, constant over four samples.
Status line rewritten to match the body (🟡 recurs but not universal), so the
document no longer contradicts itself.
This commit is contained in:
Sylpheed RE agent
2026-08-26 23:57:01 +00:00
parent dd052287e9
commit 6e081c5437
1 changed files with 24 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,14 +1,31 @@
# `REMAINING OB` — the mission's own objective counter, in RAM
**Status:** ✅ `CONFIRMED` for one Stage 02 run: a **big-endian u32** whose value
is exactly the HUD's `REMAINING OB`, verified across two transitions it was not
selected by. ❌ **the ADDRESS is run-dependent — measured 2026-08-26, see below.**
❔ what it counts, and whether objective-marked entities carry a flag.
**Status:** ✅ `CONFIRMED` as a **big-endian u32** whose value is exactly the
HUD's `REMAINING OB`. 🟡 the ADDRESS recurs but is not universal — `0xbdb59668`
carried it in 3 of 5 measured runs, read a hard 0 in 2, and read garbage in a
6th (2026-08-26). ❔ what it counts, and whether objective-marked entities carry
a flag.
> ## ❌ Cross-run stability: REFUTED (2026-08-26)
> ## 🟡 A sixth run, and a new failure mode (2026-08-26)
>
> The 🟡 above said cross-run stability was untested. It is now tested, and the
> address does **not** carry over. A fresh Stage 02 run (guarded route, stage
> ### ❌ First, a correction to this very section
>
> As originally written this section claimed to be *testing an untested* 🟡, and
> concluded "the address is run-dependent — always re-derive". Both halves were
> wrong, and the evidence was already further down **this same file**:
>
> * Cross-run stability was **not** untested. The status line at the top said so,
> but the body had tested it repeatedly — `0xbdb59668` carries the counter in
> **3 of the 5** runs measured, and reads a **hard 0** in the other two. I
> refuted a stale *status line* and presented it as news.
> * "Always re-derive" is worse advice than the rule this file already gives:
> **try `0xbdb59668` first, check it against the HUD, and re-scan only when it
> reads 0.** A scan costs ~5 minutes; the check costs seconds.
>
> ### What this run actually adds
>
> A **sixth** data point, and a failure mode not previously seen: the address
> read neither the counter nor 0 but **95748078**, constant over four samples. A fresh Stage 02 run (guarded route, stage
> asserted via `assert_stage.py UN_f101_TCAF_Acropolis`):
>
> | | |