Files
Sylpheed/docs/re/entity-readout-working.md
Sylpheed RE agent cc6d088573 re: the live entity readout works end-to-end; "0 movers" was a state
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.
2026-08-26 21:54:23 +00:00

71 lines
3.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# ✅ 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_00000xBE00_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 00020 000 movers in it, and the unmodified
tool produces a typed, positioned, oriented entity list.