Chasing yesterday's [T1] to retire it produced an answer that must not be
papered over.
Two corrections to my own 5.3.137 note first. FUN_0041db7c is the
engine's Damage CONSTRUCTOR -- it zeroes the amount, seeds the force,
sets the normal to (0,1,0) -- so the bin's +0x1f0 block is a Damage
struct, not an "explosion record", and our cookOffState[12] is that
struct in disguise. And the resource read I thought filled it belongs to
the GENERATOR ctor: same dword index, different class. The per-class
offset trap, twice in two days.
The uncomfortable part: across the whole AmmoBin TU that Damage is only
default-constructed and read. Nothing writes its amount. The
constructor leaves it zero, so rounds x 0 == 0 -- the shipped game's
cook-off appears to compute ZERO damage. It destroys the bin, announces
"ammo explosion damaging" for every zone, and delivers nothing.
Three readings survive: the feature is vestigial in 4.10; a writer lives
outside the TU (a table-registered handler is where to look next); or the
multiplier cell is misidentified.
So the landing is re-marked [T2], a deliberate divergence, not [T1]
staging. With the fed weapon's damage standing in, ours does 500-800
points across the zones and destroys subsystems where the shipped one
does nothing. That is us being more lethal than the original, which is
exactly the silent gameplay drift this project exists to avoid. It stays
ON -- an inert mechanic is indistinguishable from an unfinished one and
would hide the question -- but it is now flagged in the code, in the
notes, and to the operator, and BT_FORCE_COOKOFF remains the only way to
trigger it without genuine heat failure.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5
77db3290d0