df4b79bfd2
Fresh run, unmodified tools: entities2.py self 0x130 returns 74-101 typed live entities with positions and speeds, a player entity, and the orientation matrix at pos-0x70 with 16-byte stride -- exactly the documented layout. Artifact committed as docs/data/live-entities-2026-08-26.txt. Last iteration's "zero moving triples across 357 MB" does not reproduce: sampled seven times 4s apart, the whole map gives 47k-123k movers and the committed ENT_VA window 10k-20k. So the window is populated and the tooling is sound; what differed between the sessions is NOT determined and is recorded as open, since the earlier zero persisted for minutes across several commands. Practical rule added: check movers are non-zero before concluding anything from a memory probe. New open discrepancy: the vtable scan reports 42 instances (20 turrets) while the +0x130 method reports 101 (82 turrets), most of the excess moving at ~375/s -- and a turret is a fixed emplacement. Likely projectiles typed as their shooter, but explicitly NOT asserted: no test here separates a projectile from a fast craft.
3.2 KiB
✅ The live entity readout works end-to-end — and "0 movers" was a state, not a defect
Measured 2026-08-26, fresh boot, save slot 01, Stage 01, live HUD.
Artifact: ../data/live-entities-2026-08-26.txt.
The readout
entities2.py self 0x130, unmodified, with its committed VA window:
# 14 unit definitions
# 9142 moving triples
# 74 typed live entities (delta +0x130)
# player entity: pos va 0xbdb3bd80 UN_f001_TCAF_DeltaSaber_T
# pos (-2012.3,-2267.7,-1968.4) speed 51.6/s
# orthonormal 3x3 blocks inside the player object: 4
pos-0x0070 stride 16: (-0.013,-0.202,+0.979) (-0.149,+0.969,+0.198) (-0.989,-0.143,-0.043)
Position, speed, and the orientation matrix at pos − 0x70 with 16-byte
stride — exactly what autopilot-memory-driven.md
documents. Nothing needed fixing.
✅ "0 movers" is a STATE, not a tool defect
Last iteration recorded zero moving triples across the whole 357 MB mapping, repeatedly, while the mission visibly ran. Same mission, same tools, same window, fresh run — sampled seven times, 4 s apart:
| round | movers, whole map | movers in 0xBD00_0000–0xBE00_0000 |
|---|---|---|
| 0 | 111 105 | 16 396 |
| 1 | 122 919 | 10 266 |
| 3 | 75 268 | 10 627 |
| 6 | 47 206 | 10 406 |
So the committed window is populated and the tooling is sound. What differed between the two runs is not determined — the earlier session's zero persisted for minutes across several commands, so it was not a sampling artifact either. Recorded as an open question rather than explained away: something about that session's state held the simulation while the renderer kept drawing.
Practical rule: before concluding anything from a memory probe here, check that movers are non-zero. It is a one-line precondition and it would have saved this corpus two iterations.
❔ The two enumerations disagree, and the difference is not noise
| method | total | e007_Turret |
DeltaSaber_T |
|---|---|---|---|
INST_VTABLE scan (roster) |
42 | 20 | 6 |
moving triple + def ptr at +0x130 |
101 | 82 | 7 |
Most of the excess is "turrets" moving at ~375/s — several of them at exactly
375.0/s, and a turret is a fixed emplacement. 🟡 The likely reading is that
these are projectiles, carrying the definition pointer of whatever fired
them, so the +0x130 method types a shot as its shooter. That is consistent with
the note in autopilot-memory-driven.md about separating "20-odd real combatants
from ~30 000 moving particles" — the same hazard, one layer up.
❌ Not asserted as fact: no test here distinguishes a projectile from a fast-moving
craft. The clean check is whether these objects have a hull value at +0x154 and
whether they persist for more than a few seconds.
Withdrawn claims, now positively disproved
Both "tool defects" reported two iterations ago are dead, and this run is the
positive evidence rather than merely the absence of the negative:
entities2.py's window returns 10 000–20 000 movers in it, and the unmodified
tool produces a typed, positioned, oriented entity list.