b56a4ab9f9
Locating DeltaSaber at mission time works: 53 occurrences, all in the heap (0xBC66..-0xBC6C..), none in the XEX image -- DeltaSaber_T.xpr, _Special, _NoseGun, _Missile, _TwinGun. But searching all of guest memory for a big-endian pointer to those addresses returns ZERO references for every one tried. That is the format, not a search bug: those strings live in the mission pak's IDXD string pool, and this corpus decoded that container long ago -- records reference names by OFFSET into the pool, never by absolute pointer. So there are no pointers to find, and "find the name, follow what points at it" cannot work on pak data by construction. This also narrows what the string counts proved. The title-vs-mission control stands (DeltaSaber 0 -> 81), so mission-specific DATA is loaded, which is more than "the tables load at boot". But these are asset-table strings, not live entity objects, so they do not show entities have been spawned. Honest split: the mission's pak data is loaded; whether entity objects exist is still unmeasured, because both probes tried -- gworld's vtable constants and name-pointer following -- are respectively stale and structurally inapplicable. Remaining routes, untried: derive the entity vtable from CODE via sylpheed.db's vptr_writes table, which exists for exactly this; or find the entity list from the mission update function rather than from data.