# MISSILE.CPP / SEEKER.CPP / MISTHRST.CPP / PROJTILE.CPP — the flying rounds **Status: PARTIAL (5.3.18) — the guided flight loop is LIVE-VERIFIED through DETONATE (spawn → fly → home → proximity fuse → cluster damage lands once), but the death-row TEARDOWN page-faults, so the spawn path is opt-in (`BT_MISSILE_FLIGHT=1`); the default delivery remains the 5.3.18a instant-hit cluster message.** ## Interfaces - `SEEKER.HPP` + `MISTHRST.HPP` are AUTHENTIC survivors (CODE/BT/BT/). The Subsystem base chain is the NAME ctor (binary FUN_0041c52c) with the shipped strings "Seeker" @00512e1e and **"MissleThruster"** @00512e25 (the 1995 misspelling is authentic — keep it). - `MISSILE.HPP` / `PROJTILE.HPP` are STAGED (only MISSILE.TCP / PROJTILE.TCP survive). Binary chain: Entity → Projectile (@004be1bc, 0x340) → Missile (@004bf5b4, vtable @00512f2c, 0x368). Our staged chain matches: Projectile : Mover (make-message path), Missile : Projectile. ## What is verified live (BT_MISSILE_FLIGHT=1 fight run) ONE cluster Missile entity per SRM salvo, spawned through the real Mover make machinery mid-weapon-sim (the Entity ctor self-registers — the engine tolerates mid-roster-walk creation, as the binary did); flight telemetry shows thruster acceleration (150→153 u/s) and closing range; the proximity fuse (rangeToTarget <= 20u staged) delivers `damageData` (salvo-split amount, burstCount=missileCount) exactly once via TakeDamageMessage with the LAUNCHER as inflictor; lifetime fizzle retires unexploded rounds. Guidance constants are binary-decoded (steer deadband 1e-4, turn gain 4.0, seeker loft 200/50/300/0.1 — .rdata @004bec18/@004bf594). ## THE OPEN CRASH (the 5.3.18 frontier) After the first detonated round's `~Missile` completes (dtor log proves it), the frame page-faults with EIP IN THE HEAP (0x9FEAEF-style) — something calls through freed missile memory or a base-dtor releases a structure wrongly. The Seeker/MissileThruster are the FIRST SUBSYSTEMS and the Missile the FIRST ENTITY ever DESTROYED in the reconstructed sim — the whole ~Entity/~Mover/~Subsystem teardown path is virgin. Checked already: NOT AlwaysExecute (flag-only), NOT interestZoneID (message base NULLs it), NOT the subsystemArray idiom (matches ~Entity's expectations exactly), Sensor holds no pointers. Latent bug FIXED on the way: the Subsystem NAME ctor left `damageZone` UNINITIALIZED (the resource ctor NULLs it) — garbage for every name-built subsystem. Next suspects: ~Mover's collision/interest release (collisionLists array delete), the executive's per-frame entity chain vs mid-frame delete (FryDeathRow one-per-frame), the host-manager update-record writer touching a condemned entity. ## Engine truths learned (load-bearing) - `ResourceFile::SearchList(id, type)` CRASHES (@0x414938) when `id` is not in the top-level directory — it derefs its inner FindResourceDescription unconditionally. `FindResourceDescription(int)` is the NULL-safe probe. - Resource IDs in MakeMessages must be FAMILY ids: the Mover base ctor runs its own `SearchList(resourceID, GameModelResourceType)`, and member resources resolve only through their family head. - The streamed `explosionModelFile` is a small INDEX (SRM6 reads 17), a model-list indirection like voltageSourceIndex/ammoBinIndex — decoding it into the real projectile family is the projectile-model brick. Until then the round spawns on the OWNER's family (GameModel member provably present; our staged flight reads none of the Mover mass/drag). ## Staged / deferred - Muzzle = mech origin; the authored MuzzleVelocity arc through the MOUNT segment world frame (fire builder @0x4bcc60:8758-64, z NEGATED + mech velocity) is the muzzle wave. - Flight envelope defaults (lifetime 10s, burn 2s @120 u/s², launch 150 u/s, fuse 20u) pending the missile GameModel record decode (model +0x44 lifetime, +0x48 thrust, +0x50 detonation mode). - Cluster SPLASH + explosion entity (ClassID 0x5C @004be078), world-geometry collision (@0042291c), target-velocity intercept lead, Missile WriteUpdateRecord (tag 0x78) for MP replication.