f59c4e595c
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.