Three results, two of them against my own earlier claims:
- REFUTED: position = instance - 0x12c. The corpus anchors on position (def ptr
at +0x130, orientation at -0x70, hull at +0x154) and name_of reads the def ptr
at instance+4, which predicts -0x12c. Measured over all 42 named instances:
almost every read is (0,0,0), three are garbage, and 0/42 move. The vtable
object and the position block are different structures.
- WITHDRAWN: last iteration's claim that entities2.py's ENT_VA window is aimed at
the definitions rather than the instances. entities2 does not look for vtable
objects at all -- it hunts moving position triples and checks +0x130, the
documented anchor -- and it had worked minutes earlier (6914 movers, +0x130
voted 92x; then 6634/138x). I built the defect report on the single sample in
between that returned zero. The +0x29d0 position candidate falls with it.
- FOUND: sampling 64 spots across the 505 extents (357 MB) twice, 2.5s apart,
with the mission visibly running, only 5 change. The megabyte holding all 42
instances is byte-identical over seconds, as is its primary-VA counterpart.
The mapping IS live (5 regions prove it); what is undetermined is whether the
entity records are simply static or whether writes land in a different alias.
Either way: verify a region changes before measuring through it.
