From da80727467aad0814c65c427328626ccc53960ed Mon Sep 17 00:00:00 2001 From: arcattack Date: Tue, 14 Jul 2026 07:27:01 -0500 Subject: [PATCH] KB: autocannon jam/coolant -- SOLVED from decomp, QA behavior CONFIRMED faithful Reproduced the QA report end-to-end from the decomp + raw-binary-verified constants. The coolant-priority effect is real but fire-rate-dependent: at the ~11s combat cadence, not-boosted jams (T=1058>1000) while boosting the AFC's condenser keeps it below the line (T=953, no jam) -- exactly as the QA described. Max-spam (8s) overheats regardless (why the earlier 'weak boost' read was wrong); 16s never jams. All AFC100 constants verified authentic vs BTL4.RES raw bytes (afc_dump.py). No bug, no stand-in. Co-Authored-By: Claude Fable 5 --- context/open-questions.md | 52 +++++++++++++++++++-------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/context/open-questions.md b/context/open-questions.md index 9223999..c89092c 100644 --- a/context/open-questions.md +++ b/context/open-questions.md @@ -413,32 +413,32 @@ 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. +- **✅ AUTOCANNON JAM / coolant-priority — FAITHFUL + CONFIRMED against QA ground-truth, SOLVED + purely from the decomp (2026-07-14) [T1/T2].** An original QA dev reported: "all AFCs jam on their + 3rd shot if coolant priority isn't boosted; boosted → almost never jam." VERDICT: the whole chain + is reconstructed end-to-end, FAITHFUL, and reproduces the reported behavior — no bug, no stand-in. + **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`). + Mechanism: a weapon dumps `heatCostToFire` (AFC100=6.5e7 raw) into its OWN linked condenser (AFC100→ + Condenser4); 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). The + weapon's OWN thermal conductance (35500) caps how fast it sheds into its condenser, so coolant + priority shifts the weapon's equilibrium only ~100 K — but that is EXACTLY enough to straddle the + `degradationTemperature`(1000) jam line at combat fire rates. Cross `1000` → `heatAlarm`≥1 → the + jam roll arms (`p=clamp(0.41·T/failT, 0.05, 1)`); on a hit → sticky `JammedState`(5), clears only on + ResetToInitialState. (Distinct: `failureTemperature`(2000) → self-clearing overheat lockout, + recoil-pinned + weaponAlarm 7.) **ALL constants VERIFIED AUTHENTIC vs the raw BTL4.RES bytes** + (`scratchpad/afc_dump.py`): AFC100 startT=77, degradT=1000, failT=2000, thermalConductance=35500, + thermalMass=94700, heatCostToFire(+0x1A4)=6.5e7, recharge(+0x190)=8, damage=25, minJamChance=0.05 — + no mis-scaling. **THE ANSWER IS FIRE-RATE-DEPENDENT** (measured, BT_JAM_LOG/BT_VALVE_BOOST/BT_AF_PERIOD, + madcat AFC100 → Condenser4): at MAX spam (8s recharge) the AFC overheats regardless (~1460 boosted + ~1360 — both jam); at a SLOW cadence (16s) it plateaus ~770 and never jams; at the ~11s COMBAT cadence + it is DECISIVE — **not boosted → 1058 K (jams), boosted (Condenser4 valve→50, others→1) → 953 K (never + jams)**. So the QA is right and the reconstruction is faithful; the earlier "boost is weak" read was + an artifact of testing at max spam (above the window). Diag probes committed: `BT_JAM_LOG` + (projweap.cpp), `BT_VALVE`/`BT_VALVE_BOOST=` (heatfamily_reslice.cpp), `BT_AF_PERIOD=` + (mech4.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