KB: autocannon jam/coolant-priority -- mechanism is FAITHFUL + COMPLETE (decomp hunt)

Two-agent decomp hunt on the QA report ('AFCs jam on 3rd shot if coolant priority
not boosted'). Conclusion: the whole coolant->jam chain is reconstructed end-to-end
and FAITHFUL -- the weapon's constant coolantFlowScale=1.0 is authentic (only
condensers' 0x15C is written from the valve, via RecomputeCondenserValves over the
condenser chain mech+0x7cc). Authentic mechanism is second-order-in-equation but
first-order-in-outcome: weapon -> its condenser -> bank; boosting a condenser's valve
share (~5x conductance swing) keeps its weapon below degradationTemp -> no jam.
Distinguished the sticky probabilistic jam (degrad 1000, JammedState 5) from the
self-clearing overheat lockout (failure 2000, weaponAlarm 7). Empirically the port is
directionally correct (~4th-shot probabilistic) but not the QA's deterministic 3rd
shot -- a calibration/scenario question pending QA clarification, NOT a stubbed path.
Do not tune the heat economy to force it without ground-truth.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
arcattack
2026-07-14 06:56:34 -05:00
co-authored by Claude Fable 5
parent 3acab416ee
commit 21abe2212e
+27
View File
@@ -413,6 +413,33 @@ register. ⚠ The audit also flags the damage-economy item as SELF-CONTRADICTOR
under reconstruction: config-mode regrouping (task #6), generator reassignment (ids 4-8),
coolant valves.
- **AUTOCANNON JAM / coolant-priority — mechanism FAITHFUL + COMPLETE; a CALIBRATION question
pending QA ground-truth (2026-07-14) [T1 mechanism / T3 pacing].** An original QA dev reports:
"all AFCs jam on their 3rd shot if coolant priority isn't boosted; boosted → almost never jam."
Full decomp hunt (2 agents) confirms the whole chain is reconstructed end-to-end and the port is
FAITHFUL — **do NOT "fix" it by driving a weapon's `coolantFlowScale` from the valve; that field
being a constant 1.0 for weapons is AUTHENTIC** (the ONLY writer of any HeatSink `+0x15C` from a
valve value is `RecomputeCondenserValves`/FUN_0049f788, which iterates ONLY the condenser chain
`mech+0x7cc`). Authentic mechanism: a weapon dumps `heatCostToFire` (AFC100=6.5e7 raw) into its
OWN linked condenser; the condenser sheds to the shared bank at a rate scaled by its valve SHARE
(`coolantFlowScale = valveState_i / Σ valveState`, MoveValve msg id 4, detents 1/5/50/0). Boosting
ONE condenser's valve (share ~0.17→~0.9 = ~5× conductance) drops its equilibrium temp so the
weapon dumping into it stays below `degradationTemperature`(1000) → `heatAlarm`=0 → CheckForJam
early-returns → no jam. Starved → condenser saturates → weapon crosses 1000 → the STICKY
probabilistic jam (`p=clamp(0.41·T/failT,0.05,1)`, JammedState 5, clears only on ResetToInitialState)
latches. Two distinct "jam" states: **degradation 1000 → probabilistic sticky jam** (the pilot's
"jam"); **failure 2000 → deterministic self-clearing overheat lockout** (recoil-pinned + weaponAlarm 7,
re-fires each frame until it cools). ALL thermal constants load strictly from the resource (no
stand-in fallback — a missing value ERRORS). **Empirical (BT_JAM_LOG/BT_VALVE, madcat AFC100):**
uncooled the weapon crosses 1000 at ~shot 4 and PLATEAUS ~1400 (conduction balances input), giving
~25% probabilistic jam — directionally right but NOT the QA's deterministic "3rd shot". Gap is
calibration (condenser thermalMass/conductance live in LAST.EGG, unread) + scenario (fire rate;
which condenser boosted — a uniform BT_VALVE is normalized away, need a targeted per-condenser
boost). NEXT: get QA to clarify (a) deterministic lockout vs probabilistic jam, (b) per-weapon vs
global coolant boost + which control; THEN verify calibration — do NOT tune the heat economy to
force "3rd shot" without ground-truth (would be un-faithful). Diag probes committed: `BT_JAM_LOG`
(projweap.cpp), `BT_VALVE` (heatfamily_reslice.cpp). See [[combat-damage]], [[subsystems]] heat.
- **Subsystem-panel online/offline gate — fields unidentified [T4] (2026-07-12).** The binary's
SubsystemCluster draw-state reads `*(subsystem+0x40)==1` and `*(subsystem+0x278)!=4`; neither
1995 field is identified (weapon simulationState is 0/2/3/4 -- +0x40 isn't it). The port pins