the crit system, complete: two gap functions recovered, the dead sink revived, and a wrong verdict reversed (#80)

The whole critical-hit pipeline was dark, three layers deep, and one of those
layers had fooled us into a false conclusion about the 1995 binary itself.

LAYER 1 -- the trigger, recovered from the un-exported gap. The Mech MESSAGE
TABLE at 0x50bdf8 ({id, name, handler} rows) names the real
Mech::TakeDamageMessageHandler at 0x4a0230 -- message 0x12 "TakeDamage" --
plus seven sibling handlers (PlayerLink, RealMaxSpeed, BalanceCoolant,
Set/ClearBurningState, EjectPilot, DuckRequest). Inside it, the crit chance
at 0x4a0164: p = clamp(0.7 * damageLevel^2 + 0.01, 0..1), gated on the
player's simLive flag (+0x25c -- novice never crits), rolled PER BURST on the
current zone, skipping a zone already burning. Chance is ~1% on fresh armour,
~18% at half-stripped, ~58% at 90% -- crits arrive exactly as armour fails.

The handler's application loop replaces the engine base's single call, which
ignored burstCount entirely (multi-burst damage under-applied (burst-1)x).
Faithful shape: per burst, crit-roll -> CriticalHit @0049ccc4 (which routes
half the amount through the armour internally and picks ONE critical
subsystem by criticalWeight) else zone->TakeDamage -- then RE-RUN the
cylinder lottery from the impact point for the next burst, stopping early
once the mech is disabled. Multi-burst damage sprays across zones by design.

LAYER 2 -- the sink. MechSubsystem::TakeDamage was an empty btstubs stand-in;
the real body is at 0x4ac0bc (CLASSMAP had that address mislabeled
"HandleMessage"): zone damage, then on level >= 1.0 the Destroyed alarm, the
PrintState gate, the 1.0 pin, and -- for a vital subsystem -- the owner
mech's graphicAlarm to level 9, the same fall/death level the leg path
raises. That is the #28 vital-subsystem kill machinery, now real.

LAYER 3 -- the one that rewrites yesterday. The subsystem ctor DID copy
armour points + per-type scales into the private zone -- through the
ReconDamageZone PROXY, whose fields sit at struct offsets +4/+8, not the
binary's +0x140/+0x144. The floats landed on the engine object's header and
the real damageScale[] stayed zero. The 2026-07-28 experiment that "proved"
subsystem zones cannot be damaged -- and that the Myomers un-powered
self-repair was dead code in the original -- was measuring exactly this port
bug. Both verdicts reversed: the binary ctor (0x4ac7bb) initializes the zone
from the resource keys WeaponDamagePoints (required) + CriticalHitScoreBonus
(required) + Collision/Ballistic/Explosive/Laser/EnergyDamagePoints, none of
which the CSS parsed. Now parsed (with the binary's own error strings), and
the ctor writes the engine's NAMED members -- layout-parity holds, so they
land on +0x140/+0x144 faithfully. The Myomers repair branch is LIVE, in 1995
and here. KB corrected and swept (combat-damage, subsystems WAVE 6,
myomers.cpp, CLASSMAP).

Live-verified twice: [subarmor] prints real parsed scales for every subsystem
at spawn (HeatSink pts=10 scale=0.1x5, Condensers pts=5 scale=0.2x5, ...);
[critroll] landed full-chain crits in both runs (zone -> weighted pick ->
subsystem's own zone driven to 1.0 -> Destroyed); mech death/respawn and the
ammo gates un-regressed; zero crashes/asserts. Honest gaps: burst>1 spraying
is transcribed but not yet exercised live (self-damage fires burst=1), the
damageType==0 COLLISION divert (@0x49ffcc) is documented-not-reconstructed,
and the id-0x16 damage/kill report messages to the players (the authentic
stats plumbing, decoded to field level in the KB) are deferred to the #45
work.

Diags: BT_CRIT_LOG ([subarmor] + [critroll]), the existing BT_DMG_LOG.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

context/combat-damage.md

@@ -359,20 +359,29 @@ death). ALL EIGHT proxy-view sites in mechsub.cpp swept to the engine view
 `GetStatusFlags` (read the vptr as a float → always "intact") and `ApplyDamageAndMeasure` (the
 crit cascade's damage-measure read garbage). Gotcha §5 (alias fields), new archetype.
 
-## ⚠ A subsystem's PRIVATE zone cannot be damaged via `TakeDamage` (2026-07-28) [T0]
-Each `MechSubsystem` owns a private `DamageZone` at `+0xE0`, built by the **2-arg trivial ctor**
-`new DamageZone(this, 0)`. That ctor (`engine/MUNGA/DAMAGE.cpp:187-190`) zeroes **all five**
-`damageScale[]` entries, `Reset()` never touches them, and the only other writer in the tree is
-`Mech__DamageZone` — the mech's *streamed* zones (`mechdmg.cpp:246-253`), a different class. Since
-`DamageZone::TakeDamage` is `damageLevel += damageAmount * damageScale[damageType]`, **any**
-`TakeDamage` against a subsystem's own zone is arithmetically a no-op, whatever the amount or type.
-Verified by experiment: a zone seeded to 0.6 and fed −0.011f for ~1500 ticks never moved.
-The crit path works because it **bypasses this entirely** and writes `damageLevel` directly
-(`DistributeCriticalHit` pins `*(this[0x38]+0x158) = 1.0f`; `ForceCriticalFailure` sets the state).
-Practical consequence: if you are reconstructing something that "damages a subsystem", route it the
-way the crit path does — a `TakeDamage` call there will silently do nothing. This is also why
-Myomers' Performance `@004b8bb9` (an un-powered self-repair) is dead code in the 1995 binary itself:
-see [[subsystems]] WAVE 6.
+## ⚠ CORRECTED (2026-07-29, #80): subsystem private zones ARE damageable — the port was writing
+## their scales through the WRONG LAYOUT
+The 2026-07-28 verdict here ("a subsystem's private zone cannot be damaged via `TakeDamage` — in
+the original too") was **wrong about the original**, and the experiment that "confirmed" it was
+measuring a PORT bug. The truth [T1, raw disasm @0x4ac7bb + live-verified]:
+- The binary's `MechSubsystem` resource ctor **initializes the private zone's armour**:
+  `defaultArmorPoints@0x140` ← resource `WeaponDamagePoints` (+0x44, REQUIRED key) and
+  `damageScale[5]@0x144` ← the five per-damage-TYPE keys
+  `Collision/Ballistic/Explosive/Laser/EnergyDamagePoints` (+0x30), normalized
+  `1/(scale·armorPoints)` exactly like the mech zones (without their extra ×0.5).
+- The PORT had this copy — but wrote it through the **`ReconDamageZone` proxy**, whose
+  `structureReference/armour[]` sit at struct offsets **+4/+8**, not the binary's +0x140/+0x144.
+  The floats landed on the engine object's header and the real scales stayed at the engine ctor's
+  zeros — hence the frozen-damage experiment. Classic databinding trap, now on the engine side.
+  FIXED: the ctor writes the engine's NAMED members (layout-parity holds — `Mech__DamageZone`
+  locks its derived fields from 0x160 up).
+- The port's CSS also never parsed the seven keys (now parsed; two are required with the binary's
+  own error strings).
+Consequences: `MechSubsystem::TakeDamage @0x4ac0bc` (now real, was a stub) accumulates authored
+per-type damage on subsystems; crits land and destroy subsystems; and **the Myomers un-powered
+self-repair `@004b8bb9` was LIVE in 1995 and is live in the port now** — the earlier "dead code in
+the original too" note in [[subsystems]] WAVE 6 is superseded. `DistributeCriticalHit`'s direct
+`damageLevel = 1.0f` pin remains the ammo-explosion path, not the general mechanism.
 
 ## ⚠ ZONE SELECTION IS A WEIGHTED LOTTERY — pixel-precise limb damage does not exist (2026-07-29) [T1]
 Issue #73 ("fired only at the left arm, damage credited elsewhere, no crits") is **largely the
@@ -394,7 +403,31 @@ plausibly intersected the mech's *cylinder* — the damage table is literally cy
 Deciding whether that distortion is material needs a per-hit theta probe + a wheel dump (slices ×
 percent tables, MadCat) — see #73 on the tracker.
 
-## ⚠ CRITS NEVER ROLL FROM WEAPON FIRE — the trigger is un-exported + the sink is a stub (2026-07-29) [T1]
+## ✅ CRITS RECONSTRUCTED (2026-07-29, #80) — the section below records the GAP as found; all three
+## layers are now fixed and live-verified
+The recovery: the un-exported gap held `Mech::TakeDamageMessageHandler @0x4a0230` (found via the
+Mech **message table @0x50bdf8** — rows `{id, name, handler}`: 0x12 TakeDamage, 0x14 PlayerLink,
+0x15 RealMaxSpeed, 0x16 BalanceCoolant, 0x17/0x18 Set/ClearBurningState, 0x19 EjectPilot @0x49f854,
+0x1a DuckRequest @0x49fa00) and the **crit-chance roll `@0x4a0164`**:
+`p = clamp(0.7·damageLevel² + 0.01, 0..1)`, gated on the player's `simLive` flag (+0x25c — novice
+never crits), rolled per BURST on the current zone (skip if the zone is already burning). The
+handler's application loop (binary @0x4a0423-0x4a04d8, now in `mech.cpp`): per burst — crit roll →
+`CriticalHit @0049ccc4` (replaces the zone application; routes half through armour internally,
+tally += the subsystem's `CriticalHitScoreBonus`) else `zone->TakeDamage`; then **re-run the
+cylinder lottery from the impact point for the next burst** (multi-burst damage sprays), stopping
+early once the mech is disabled. The engine base's single-application (which ignored `burstCount`
+entirely — multi-burst under-applied (burst-1)×) is superseded. `MechSubsystem::TakeDamage
+@0x4ac0bc` is real (zone damage → destroyed alarms → **vital-subsystem kill**: owner
+`graphicAlarm` level 9, the #28 machinery — CLASSMAP's "HandleMessage@4ac0bc" was a mislabel).
+Live-verified: `[subarmor]` shows parsed scales at spawn; `[critroll] zone=3 -> Myomers subLvl=1`
+— a full chain crit destroying a subsystem. Still deferred [T4→documented]: the `damageType==0`
+COLLISION divert (@0x4a0368 → `0x49ffcc`, its own distribution) and the **id-0x16 damage/kill
+reports** to shooter+victim players (@0x4a04da-0x4a07b2 — the authentic stats plumbing, feeds #45:
+`{tally, zone, destroyed-flag, inflicting subsystem, victim name}`, kill-flagged variant on newly
+disabled, plus a killed-by block gated on movementMode 9/10). Diags: `BT_CRIT_LOG` (`[subarmor]` +
+`[critroll]`), `BT_DMG_LOG`.
+
+## (HISTORICAL — the gap as found 2026-07-29, superseded above) [T1]
 The authored crit machinery exists and is reconstructed — `Mech__DamageZone::CriticalHit @0049ccc4`
 (half the damage to armour, half to ONE critical subsystem chosen by `criticalWeight`, capped by
 `damagePercentage`) — but **nothing in the port calls it**. Raw byte-scan of the binary: exactly ONE

context/decomp-reference.md

@@ -473,6 +473,7 @@ default-ON (`'0'` disables).
 | `BT_SELF_DAMAGE=<dps>` | dispatch an unaimed `TakeDamage` at your OWN mech once a second, through the real `Entity::Dispatch` path, so the whole RESPAWN family is bench-testable solo (nothing else can kill the local pilot: `BT_MP_FORCE_DMG` only targets replicants). **Latches off at first death** so everything after the respawn is the respawn's doing, not the harness still shooting you |
 | `BT_POWER_DETACH_TEST=<name\|1>` | drop a subsystem's voltage link + force Auto, so the auto-hunt must recover it. `1` = first powered subsystem to tick; a NAME (`PPC_1`, `Myomers`) targets one, which is what proves FAILOVER to a different generator rather than a same-generator re-attach |
 | `BT_AUDIO_SOURCES=<n>` | request `n` OpenAL mono sources instead of the driver default (~256). **Opt-in on purpose** — the cap doubles as a governor, and with EFX reverb live a higher ceiling means more simultaneous voices mixing during heavy combat. Measure frame time. See [[wintesla-port]] |
+| `BT_CRIT_LOG` | #80 crit diagnostics: `[subarmor]` per-subsystem armour/scales/critBonus at ctor (proves the resource keys parsed + the zone got REAL scales), `[critroll]` per landed crit (zone, subsystem, its resulting own-zone level). NB the type-0x1e loader's `[crit]` tag is a different, older log |
 | `BT_DEVICELOST_TEST=<frame>[,crashrepro]` | #35 bench hook. `<frame>` forces the D3D9 DEVICELOST branch at that render frame (+600/+1200 = 3 cycles), driving the REAL `BTResetLostDevice` recovery. `,crashrepro` runs the field null-teardown shape (double `ParticleEngine::Destroy`) — pre-fix this reproduced the field crash byte-for-byte (`Destroy +0x11`, `target=0x0`); post-fix it must log `SURVIVED`. See [[wintesla-port]] §Device-loss |
 
 Full render/locomotion gates (BT_RAMP, BT_MATPRI, BT_CULL, BT_SHADOW_*, BT_LODSEL, BT_ADDLOD,

context/subsystems.md

@@ -92,18 +92,16 @@ Making a base byte-exact GROWS every subclass — they must be re-based TOGETHER
   thermal curve and zone damage; `@004b8ceb` run the inner integrator **only when `outputVoltage > 0`**.
   Verified live: healthy `outV=10000 speed=1`, un-powered `outV=0 speed=0`, and 96/96 torso samples at
   `elec=4` across two death/respawn cycles.
-  ⚠ **`@004b8bb9` is DEAD CODE — in the original too** [T0]. It builds a `Damage`
-  (type=`Explosive`, amount=`0xbc343958`≈-0.011f, impactPoint=`owner+0x100`, burst=1) and calls the
-  **zone's** `TakeDamage` (zone vtable `+0x18`, *not* the subsystem's `+0x24`). Reading it as
-  "an un-powered myomer heals" is the evident intent, but it can never fire: a subsystem's private zone
-  comes from the 2-arg `new DamageZone(this,0)`, and `engine/MUNGA/DAMAGE.cpp:187-190` zeroes **all five**
-  `damageScale[]` entries; `Reset()` never touches them and the only other writer is `Mech__DamageZone`
-  (the mech's *streamed* zones — `mechdmg.cpp:246-253`). Since `TakeDamage` is
-  `damageLevel += amount * damageScale[type]`, the sum is always `+= amount * 0`. Confirmed by
-  experiment: seeded to 0.6 and held at NoVoltage ~1500 ticks, `damageLevel` never moved.
-  Reconstructed and deliberately NOT "fixed" — inventing a working repair would be made-up behavior.
-  **General rule:** you cannot damage a subsystem's own zone through `DamageZone::TakeDamage`; the crit
-  path writes `damageLevel` directly (`DistributeCriticalHit` pins `*(this[0x38]+0x158) = 1.0f`).
+  ✅ **CORRECTED 2026-07-29 (#80): `@004b8bb9` — the un-powered self-repair — is LIVE, in 1995 and
+  now in the port.** The 2026-07-28 "dead code in the original too" verdict here was wrong about the
+  original: the frozen-at-0.6 experiment was measuring a PORT bug (the subsystem ctor wrote the
+  zone's armour/scales through the `ReconDamageZone` proxy at struct offsets +4/+8 instead of the
+  engine members at +0x140/+0x144, so the real `damageScale[]` stayed zero). The binary ctor
+  (`@0x4ac7bb`) initializes them from the resource keys `WeaponDamagePoints` + the five per-type
+  `...DamagePoints`; the port now does the same through the engine's named members, and the CSS
+  parses the keys. An un-powered, not-yet-destroyed myomer heals at `0.011 × damageScale[Explosive]`
+  per tick. The retracted "cannot damage a subsystem's own zone" rule is superseded — see
+  [[combat-damage]] §CORRECTED for the full mechanism (this also revived the crit sink, #80).
   Also un-stubbed here: `Myomers::DamageStructureLevel()` returned a hardcoded `0.0f`, which pinned
   `AvailableOutput`'s `(1 - damage)` factor at 1 — a shot-up myomer drove exactly as well as a fresh
   one. Now routed to the base bridge `GetSubsystemDamageLevel()`; measured `dmg=0.6 → speed=0.4`.