fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the live entity readout works end-to-end; "0 movers" was a state

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-26 21:54:23 +00:00
parent 0256d71e78
commit df4b79bfd2
2 changed files with 130 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
docs/re/entity-readout-working.md Normal file
View File

@@ -0,0 +1,70 @@
# ✅ 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.