Files
TeslaRel410/restoration/source410/BT/MISSILE.NOTES.md
T
CydandClaude Fable 5 110ecec2ca BT410 Phase 5.3.18: flying missiles -- spawn/home/detonate LIVE, teardown open
The Missile entity family is reconstructed: Projectile : Mover gets a real
make-path ctor; Missile hosts the Seeker + MissleThruster roster (the
AUTHENTIC surviving SEEKER.HPP / MISTHRST.HPP interfaces -- the 1995
misspelling included) and flies the binary's guided integrator (@004bef78):
age/lifetime, seeker re-lead with the decoded loft constants
(200/50/300/0.1), thruster burn, steering (gain 4.0, deadband 1e-4), and
the proximity fuse delivering the cluster damage ONCE with the launcher as
inflictor.  Live-verified end-to-end: LAUNCH -> flight telemetry (thruster
visibly accelerating) -> DETONATE on the target ~0.9s out.

OPEN: the first ~Missile off the death row completes, then the frame
page-faults with EIP in the heap -- the first entity/subsystem teardown the
reconstructed sim has ever run.  The spawn path is therefore OPT-IN
(BT_MISSILE_FLIGHT=1); default SRM delivery stays the 5.3.18a instant-hit
cluster (verified 1:1, zero exceptions).  Forensics + engine truths
(SearchList crashes on non-directory ids; MakeMessages need FAMILY resource
ids; explosionModelFile is a model-list INDEX) in MISSILE.NOTES.md.

Also fixed on the way: the Subsystem NAME ctor left damageZone
UNINITIALIZED (latent garbage for every name-built subsystem).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 11:58:40 -05:00

74 lines
4.1 KiB
Markdown

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