2 Commits

Include renames

Author	SHA1	Message	Date
Joe DiPrimaandClaude Opus 5	3b7c19c232	#95: REVERT the salvo-damage hack; deliver the cluster the way the binary does ... Supersedes the mislanch change in efc3e9f, which multiplied the lead round by missileCount. That produced roughly the right average total but as ONE lump on ONE zone, with no scatter and no variance -- not what the arcade does. WHAT THE BINARY DOES (all byte-verified): * MissileLauncher ctor @004bcff0: burstCount = missileCount; damageAmount /= missileCount * FireWeapon @004bcc60 spawns exactly ONE Missile -- no loop, missileCount is never read there. The salvo IS one cluster round. * Missile::Perform rolls how many of the cluster connect right before it dispatches (part_013.c:10082): b = Random(n) + n/4, clamped to n -- i.e. between a quarter of the salvo and all of it. * It then dispatches DIRECTLY at the struck entity (FUN_004be078: param_2->Dispatch(&msg)) -- NOT through the shooter's message manager. * Mech::TakeDamageMessageHandler @0x4a0439-0x4a04d8 applies the hit burstCount times, RE-ROLLING the struck zone per burst. Our handler already implements that loop faithfully (mech.cpp, task #80) -- I wrongly believed it was missing, because the KB asserts as [T1] that "burstCount is cosmetic for zone damage". That is half right: DamageZone::TakeDamage really does ignore burstCount (verified @0041e4e0), but the HANDLER honours it by calling that function repeatedly. KB corrected separately. The actual defect was that the projectile impact path hardcoded burstCount = 1, and -- worse -- routed damage through the SubsystemMessageManager, whose consolidation rebuilds the record from a stream carrying only {damageType, damageAmount, subsystemID}. DamageInformation has no burstCount field, so the cluster count was DROPPED in transit no matter what the round carried. So: dispatch projectile damage directly, as the binary does, carrying the rolled burst. This also retires the #84 double explosion architecturally -- the second blast came from the manager's bundled explosion, and projectiles no longer go through the manager at all. The MarkRoundDetonated suppression added in efc3e9f is therefore dead and is removed. ALL-WEAPON-CLASS AUDIT (scratchpad/night8/allweap.{sh,py}), one run, all classes firing at once: EXPLOSIVE (missile) 38 zone applications, bursts spread 1x2,2x6,3x9,4x4,5x5, 6x12 across ELEVEN zones -- the [n/4..n] roll plus the per-burst zone re-roll, i.e. the cluster scattering ENERGY (beam) 8 applications, burst 1 -- unchanged, no regression type4 8 applications, burst 1 -- unchanged COLLISION 0 applications reached armour -- divert intact Explosions: 10 projectile impacts produce no bundled blast; direct-fire still queues its own (11 made). NOT yet verified: cross-pod delivery. Dispatch reroutes to a replicant on its own (and the binary relies on exactly that), but the manager routing is gone, so MP damage should get a two-node run before this ships. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 04:42:15 -05:00
Joe DiPrimaandClaude Opus 5	efc3e9ff1a	#95/#84: missile salvos deliver their FULL authored damage, and stop double-exploding ... THE SALVO DAMAGE (#95). Players measured an LRM 15 landing "3ish points". The logs agreed: [projectile] IMPACT damage=3.33333 (Oracle, LRM15) and 3.5 (Rajel, LRM10). Those are right PER MISSILE -- 50/15 and 35/10 -- and the bench shows why the salvo still under-delivers: each launcher pushes N rounds of which exactly ONE carries damage. Two individually-correct changes composed into an N-fold shortfall: * The ctor does what the binary's MissileLauncher ctor does (@0x3ac/@0x3d4): damageData.burstCount = missileCount; damageData.damageAmount /= missileCount; The record holds the PER-MISSILE amount plus the count; the arcade reconstitutes amount x burstCount when it applies the hit. * Task #62 then correctly stopped the port applying the hit once per visual round (that was ~missileCount-x too lethal) by damaging only the lead round -- but handed it the already-divided amount. Our DamageZone::TakeDamage is `damageLevel += amount * scale` and drops burstCount, so the salvo delivered amount/missileCount. Since the port collapses the cluster to one damaging round, multiply the count back in there. Bench: an SRM6 salvo now lands amt=35 (the authored total) taking a zone 0 -> 0.556, where it previously landed 5.83. THE DOUBLE EXPLOSION (#84). Oracle: "missile appear to register hit explosions twice, once where target was and again where the target is." There are two spawn sites: BTSpawnRoundDetonation at the round's own impact point, and the message manager's bundled explosion at the CONSOLIDATED point a frame later. The duplicate was known and thought harmless -- "among a rippled volley it is invisible" -- which held only while a salvo landed N detonations. A projectile now marks its weapon (MarkRoundDetonated) and the consolidation skips queueing a second blast for it; direct-fire weapons never mark, so lasers/AC keep the bundled explosion they rely on. Bench: 4 missile impacts -> 4 SKIPPED, while 11 direct-fire hits still queue normally. SWEPT CONTACT (#84 tail). Contact was a 10-unit sphere sampled only at the END of each step. With the authored thruster live (#84) field rounds arrive at v=955 -- a ~16 unit step at 60fps, larger than the radius -- so samples can straddle the target. (Pre-#84 rounds flew ~100-300 = a 1.7-5 unit step and could never skip it: the velocity fix exposed this, it did not cause it.) Now tests the whole segment travelled and bursts at the point of NEAREST APPROACH, which also stops the detonation being flung past the target at speed. RETRACTION: I posted tunnelling as the leading explanation for the lost salvo. The bench disproves it -- zero fizzles, and the "missing" rounds are the dmg=0 visual rounds of the cluster, which never registered damage by design. The sweep is kept as speed-independent robustness, not as the #95 fix. Bench: scratchpad/night8/salvo.sh (BT_PROJ_LOG + BT_FIRE_LOG). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 23:59:44 -05:00