SubsystemMessageManager reconstructed from the raw decomp with the wire
format pinned by the engine's own parser (TakeDamageStreamMessageHandler:
count, then type/amount/subsystemID per record -- the chain KEY carries the
damage amount, which is why AddDamageMessage keys its plugs by it).
AddDamageMessage @0049b6d8: first hit of the frame wins the common record.
ConsolidateAndSendDamage @0049b784: one DynamicMessage(0x13, 0x34) at the
hit entity, the firing weapon's explosion resource bundled per record
(binary reads roster[id]+0x3e4 blind; [T1] guarded here), DeletePlugs
teardown, commons reset. CreateWeaponExplosions @0049baa0 under its
AUTHENTIC surviving-header signature (the donor's 'SendQueuedExplosions'
rename was drift): per queued resource an Explosion::MakeMessage --
MakeMessageID 3, ExplosionClassID 0x31 (our VDATA enum ordinal matches the
binary exactly), flags 0x100, identity-rotation Origin at the impact point
-- posted to the Registry at CreationEventPriority, staggered 0.1s apart.
The 1995 archaeology: the binary computes a terrain-hit flag from a
Derivation at 0x4e6f54 (unresolved BSS class) and passes it to a parameter
THE SHIPPED BODY NEVER READS; terrainHitExplosionID is resourced by the CSS
and consumed nowhere. A declared, streamed, abandoned feature -- shipped
anyway. We pass False [T3]; behavior is byte-identical.
Ctor corrections vs our stub: weaponExplosions is UNIQUE-keyed (binary
chain ctor flag 1), the Performance registers, resource fields copy from
the stream. MechWeapon grows a public ExplosionResourceIDOf() accessor.
The 0x160-byte engine helper at +0xE0 stays staged [T3]; the CSS stays in
the authoring-family batch. No feeders call AddDamageMessage yet -- the
consolidator idles empty per frame, soak-verified live (no faults, wheel
turning).
Stubs: 13 across 10 files.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
