a3f6ab617b
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.