a21927ab01
Same moment, same stage: the INST_VTABLE scan sees 116 objects across 14 types; the moving+0x130 method sees 30 across 4. Every capital ship, station, missile and the objective-critical Acropolis reads ZERO in the +0x130 method. The absence is structural, not a filter artifact -- both obvious explanations were tested and failed. Dropping the speed floor to 0 raised the count 30 -> 59 and recovered the _Player but still only 4 types; scanning the WHOLE map with no floor gives 181824 movers and still 4 types. And 0/116 vtable instances lie inside the window where the +0x130 blocks are found (instances 0xbc372cc0-0xbc9bc720, window 0xbd000000-0xbe000000), independently confirming these are separate allocations. Consequence: an autopilot that must protect the Acropolis cannot find it via the +0x130 method at all. Also found: LOAD GAME -> slot 01 no longer restores the S01 training area but a Stage-02-style escort mission (Acropolis, SchlosBase, cruisers, frigates). Slot 01 is the AUTO-SAVE, so the restored mission moves as the save is written -- which invalidates the earlier "101 vs 42" comparison outright, since those came from different stages. Corrects the previous note: entities2 prints its count AFTER dedup, so the 101 was already deduplicated; the gap was the stage change, not duplication.
4.6 KiB
✅ The two enumerations are two different structures — and only one is complete
Measured 2026-08-26, live flight HUD, movers precondition checked (18 002).
The stage changed between runs — earlier cross-run comparisons were invalid
LOAD GAME → slot 01 did not land on the same mission it did earlier today.
This run's definition table has 14 entries and no asteroids at all:
UN_bf001_TCAF_SchlosBase UN_f101_TCAF_Acropolis UN_f201_TCAF_Tanker
UN_e105_ADAN_Cruiser UN_e106_ADAN_Destroyer UN_e108_ADAN_ASFrigate
UN_e201_ADAN_ISCMissile UN_f003_TCAF_ArrowHead UN_f105/f106 TCAF ...
That is the Stage 02 escort mission (the ACROPOLIS of
autopilot-memory-driven.md), not the S01 training
area with UN_S01_Asteroid_cmesh_* that earlier runs loaded. Slot 01 is the
auto-save, so the mission it restores moves as the save is written.
❌ This invalidates the earlier "101 vs 42" comparison outright — those two numbers came from different stages, not merely different moments. And it means no runtime roster is reproducible across runs unless the stage is verified first.
Same moment, same stage, both methods
| type | INST_VTABLE scan |
moving + +0x130 |
|---|---|---|
UN_e007_ADAN_Turret |
21 | 14 |
UN_e010_ADAN_Attacker_S |
9 | 8 |
UN_f001_TCAF_DeltaSaber_T |
7 | 7 |
UN_f001_TCAF_DeltaSaber_T_Player |
1 | 1 |
UN_e106_ADAN_Destroyer |
19 | 0 |
UN_f106_TCAF_Destroyer |
14 | 0 |
UN_f105_TCAF_Cruiser |
11 | 0 |
UN_e105_ADAN_Cruiser |
7 | 0 |
UN_e108_ADAN_ASFrigate |
9 | 0 |
UN_e201_ADAN_ISCMissile |
9 | 0 |
UN_f003_TCAF_ArrowHead |
6 | 0 |
UN_f101_TCAF_Acropolis / bf001_SchlosBase / f201_Tanker |
1 each | 0 |
| total | 116 | 30 |
✅ The absence is structural, not a filter artifact
The obvious explanations were tested and both fail:
- Speed band.
moving()filters displacement tolo=1.0 … hi=4000.0per 0.5 s, which would exclude a slow capital ship. Dropping the floor to 0 and the ceiling to 1e12 raised the count 30 → 59 and recovered the_Player— but still only 4 types. Capital ships never appear. - Address window.
moving()defaults to0xBD000000–0xBE000000. Scanning the whole map with no speed floor gives 181 824 movers and still 4 types.
So the ten missing types do not have a definition pointer at position + 0x130
anywhere in memory that a moving-triple scan can reach. The +0x130 block is
not the universal entity record — it belongs to a subset.
🟡 The subset is nearly "small craft": every type it does cover is a fighter,
attacker or turret. But UN_f003_TCAF_ArrowHead is a TCAF fighter and reads
0, so "small craft" is not the rule. ❔ What actually distinguishes them is
not established — plausibly an active-flight-model flag, with parked wingmen and
capital ships handled by a different update path.
✅ They live in different regions, which is why they are different structures
vtable instances : 0xbc372cc0 .. 0xbc9bc720 (116)
ENT_VA window : 0xbd000000 .. 0xbe000000
instances inside that window : 0/116
Zero of the 116 vtable objects lie in the window where the +0x130 position
blocks are found. This is independent confirmation of
the earlier refutation: the vtable object and
the position block are separate allocations in separate regions, not two views of
one record.
Which list to use
- Completeness — the
INST_VTABLEscan. It sees all 14 types including stations, capital ships and the objective-criticalAcropolis. - Motion state — the
+0x130blocks. They carry position, speed, orientation (pos−0x70, stride 16) and hull (pos+0x154), but only for ~4 types. - An autopilot that must protect the
Acropoliscannot locate it through the+0x130method at all. That is a concrete limit on the existing approach.
Also confirmed
The exact 2× duplication reappeared: def-pointer hits come in pairs 0x1000
apart with byte-identical positions (0x011db3bd80 / 0x011db3cd80, both
(-1654.7, -3992.7, 458.2), both moving 424.482). ❌ It is not page aliasing
in gmem.MAP terms — aliased VAs share one file offset, and these differ by
0x1000 in the offset itself, so they are genuinely two copies.
❌ Correction to the previous note: it
said "at least one of the counts was un-deduplicated". That is wrong —
entities2.py prints its count after ents = list(uniq.values()), so the 101
was already deduplicated. The gap was the stage change, not duplication.