This repository has been archived on 2026-09-16. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
Syplheed-Reborn/docs/re/structures/mission-objective-counter.md
Sylpheed RE agent a3f6ab617b tools+docs: find REMAINING OB in guest RAM, verified across unselected transitions
The mission's objective counter is a big-endian u32 at guest VA 0xbdb59668 in a
Stage 02 run on the upstream baseline. It was selected on an 18->24 transition
and then tracked 24->23->22 against the HUD on its own - four readings, two
changes it was not filtered on.

That last point is the whole discipline here, because the first attempt failed it.
An earlier differential over 19->18 also produced exactly one candidate,
0xbc22e83c, which matched the transition it was selected on and was still wrong:
read live it held 26 while the HUD showed 017. One matching transition is not
evidence.

A second trap is recorded too: a three-snapshot filter requiring 19 -> 19 -> 18
left ZERO survivors, because the value moves between the memory copy and the
screenshot that reads it. Filtering on the next DISTINCT value instead found the
counter on the first try.

ob_scan.py carries the method: scan one snapshot, then filter the candidate set
against live /dev/shm/xenia_memory_* at each new value, so only the first pass
needs a 4.8 GB copy.

Stated plainly as unsettled: the ADDRESS is from one run and cross-run stability
is untested, so the durable result is the method rather than the number. And what
the counter counts - whether every OB-badged entity is one of them, and whether
that badge is a flag in the entity object - is the follow-on the pilot actually
needs to CHOOSE targets rather than just know how many remain.
2026-08-19 19:01:24 +00:00

2.9 KiB

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 itself is from one run — cross-run stability is untested. what it counts, and whether objective-marked entities carry a flag.

Why it matters

autopilot-memory-driven.md ranks this its problem #2: a pilot that flies well but ignores the objective cannot finish a mission. Its 300 s run took no damage, killed one fighter, and watched REMAINING OB rise from 004 to 011 as waves spawned. Reading the counter is what turns "shoot whatever is nearest" into "shoot what closes the mission".

The find

Guest VA 0xbdb59668, big-endian u32, in a Stage 02 run on the upstream baseline.

time RAM 0xbdb59668 HUD
selected on 18 → 24 018 → 024
t+40 s 24 024
t+75 s 23 023
t+110 s 22 022
t+145 s 22 022
t+180 s 22 022

The two middle rows are the ones that matter: the candidate was filtered on the 18→24 transition, and it then tracked 24→23→22 on its own.

Method, and the two traps in it

tools/re-capture/ob_scan.py. Scan one snapshot for the current value, then filter that candidate set against live /dev/shm/xenia_memory_* at the next distinct value. Only the first pass needs the 4.8 GB copy.

🔴 Filter on a change, not a repeat. The first attempt scanned at 19, filtered at 19 again, then at 18 — and left zero survivors. The value moves between the memory copy and the screenshot that reads it, so "still 19" is not reliable. Scanning 18 and filtering on 24 gave exactly one candidate on the first try.

🔴 Verify across a transition you did not select on. An earlier differential over 19→18 also gave exactly one candidate, 0xbc22e83c — and it was wrong: read live it held 26 while the HUD showed 017. It was an unrelated counter that happened to step 19→18 in the same window. One matching transition is not evidence; the same offset tracking a later, unselected change is.

What is not settled

  • 🟡 Cross-run stability. 0xbdb59668 is from a single run. The corpus's other runtime finds are re-scanned per run, so the durable result here is the method, not the number. Testing whether the address repeats costs one boot.
  • What it counts. It rose 18 → 24 while waves spawned and fell as things died, so it is objective targets remaining, not kills. Whether every OB-badged entity is one of them, and whether that badge is a flag in the entity object, 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.