# ✅ 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`](../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`](autopilot-memory-driven.md)
documents. Nothing needed fixing.

## ✅ "0 movers" is a STATE, not a tool defect

[Last iteration](entity-position-anchor-refuted.md) 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](entities-live-roster.md)) | 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.