Sylpheed/docs/re/entity-count-discrepancy-resolved.md

❌ The "82 turrets are projectiles" hypothesis is refuted — the count inflation is page duplication plus wave arrivals

Measured 2026-08-26, fresh boot, save slot 01, Stage 01, live flight HUD, movers precondition checked first (23 798 in the entity window).

❌ Refuted: they are not projectiles

The previous note flagged 82 objects typed UN_e007_ADAN_Turret moving at ~375/s and suggested they were shots carrying their shooter's definition pointer. Three independent checks all say no.

1. They persist. Enumerated, waited 15 s, re-enumerated:

survivors: 42/42
  of the FAST (>300/s): 22/22 survived
  of the SLOW (<=300/s): 20/20 survived

Every fast object was still there 15 seconds later. A shell fired at a target 2–5 km away does not live 15 s.

2. They carry a per-type hull at pos+0x154, the documented anchor:

entity	speed	hull +0x154
UN_f001_TCAF_DeltaSaber_T	850.0	1000.0
UN_e007_ADAN_Turret	354.2	100.0
UN_e007_ADAN_Turret	354.2	79.0

Clean round numbers, constant within a type and different between types — and one turret reading 79.0 against its siblings' 100.0, i.e. a unit that has taken damage. A projectile does not carry a damageable per-type hull.

3. The speed was never suspicious in the first place. structures/isl-builtins.md already records that UN_e007_ADAN_Turret's definition carries MaximumVelocity 500 and CruisingVelocity 280 — "the data models turrets as if mobile". 354–375/s sits inside that envelope. My hypothesis rested on "a turret is a fixed emplacement", which is an inference from the name that the corpus had already contradicted from the data. Fifth time this session that grepping first would have been cheaper than measuring.

✅ What the inflated count actually is

Two effects, both measured, neither of them mis-typing.

(a) Exactly 2× duplication. In one enumeration: 64 raw hits → 32 after deduplicating by (name, rounded position), and every per-name count halves exactly —

name	raw	dedup
UN_e007_ADAN_Turret	32	16
UN_e010_ADAN_Attacker_S	16	8
UN_f001_TCAF_DeltaSaber_T	14	7
UN_f001_TCAF_DeltaSaber_T_Player	2	1

The commonest gap between consecutive hit offsets is 0x1000 (52 of 63) — one page. So each entity is found twice, one page apart. entities2.py's main() already dedups by (name, rounded pos); a caller using typed() directly does not, and will double-count.

(b) The population grows. The same enumeration 15 s later returned 60 where it had returned 42 — consistent with the wave arrivals in mission-wave-arrivals.md.

So comparing "101 from the +0x130 method" against "42 from the vtable scan" was never a fair comparison: the two numbers came from different mission times, and at least one of them was un-deduplicated.

❔ Not settled

• Whether the earlier 101 figure was raw or deduplicated — it is odd, so it cannot be a pure 2× artifact, and I did not re-check which of the two numbers the tool prints at that point.
• Whether the 0x1000 duplication is a genuine second copy of the object or the same physical page appearing at two file offsets. The exact one-page spacing suggests aliasing, but nothing here distinguishes them.
• The two enumerations still describe different sets — the vtable scan sees asteroids and the _Player, the +0x130 method mostly sees combatants — so "which is the entity list" remains open even though the count gap is explained.