Joe DiPrimaandClaude Opus 5
abea159b23
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
59 lines
3.1 KiB
Python
59 lines
3.1 KiB
Python
"""#137: post the clean mechanism write-up (the inline attempt was shell-mangled)."""
|
|
import sys
|
|
sys.path.insert(0, r"C:\git\bt411\scratchpad\night7")
|
|
import gitea
|
|
|
|
BODY = """*(Reposting -- the previous comment was mangled in transit. This is the readable version.)*
|
|
|
|
**MECHANISM SOLVED -- and it is not the respawn.** Controlled A/B on one bench, only the load differs:
|
|
|
|
| load | respawns | post-reset runaway |
|
|
|---|---|---|
|
|
| 0.95 throttle + continuous missile fire | 4 | **17 frozen samples, T climbs 77 -> ~11,600** |
|
|
| 0.50 throttle, no weapons | 2 | **0** |
|
|
|
|
Measured, not argued:
|
|
|
|
* **The reset works.** `T == startingTemperature` (77) at every single reset, in both runs.
|
|
`HeatSink::RTIS @004ad760` does `param_1[0x45] = param_1[0x4f]`, and our port matches --
|
|
additionally resetting `heatEnergy`, which it must, since the sim derives
|
|
`currentTemperature = heatEnergy / thermalMass`.
|
|
* **The stale cache is real but harmless.** Nothing in the reset chain writes
|
|
`Myomers::speedEffect` (@0x31C) -- `Myomers::RTIS @004b8aa4` only chains to the
|
|
PoweredSubsystem one -- so it survives the reset reading 0. It self-heals on the very next
|
|
tick (`T=77.13` -> `speedEffect=1`). Not the bug.
|
|
* **With ordinary load the myomers never approach `failT=2000` after a respawn.**
|
|
|
|
## What players are actually experiencing
|
|
|
|
Run hard -> myomers pass `failT=2000` -> the derating curve `@004b8ac0` returns 0.0 -> chain
|
|
MAX 0 -> `speedDemand *= 0` -> bogged down -> die, often *because* bogged down. The respawn
|
|
correctly resets to 77. Resume high throttle and firing and it climbs back over the cliff within
|
|
seconds -- which reads as "respawned with the heat bar maxed".
|
|
|
|
That also explains the intermittency (5 of 61 field respawns, ~8%): it tracks how hard you were
|
|
driving into and out of the respawn, not the respawn itself.
|
|
|
|
Oracle's "loop 5 and generator D heating up as all the excess heat goes into the loop" is
|
|
confirmed literally -- the myomers link to **Condenser5** (`mass=250000 k=190000`).
|
|
|
|
## The remaining defect: the climb RATE
|
|
|
|
Overshooting roughly 6x past a cliff the design treats as coolant-managed (`degradeT=1000`
|
|
governor onset, `failT=2000`) is not a lever a player can work with. That is the real ticket now.
|
|
|
|
Suspect under review, **not yet proven**: the kinetic term. The binary `@004b8d18` applies **no**
|
|
`time_slice` to it (`fVar5 * fVar1`), while the climb and accel terms both carry `param_2` -- i.e.
|
|
it is a per-frame energy add at the pod's fixed ~28 Hz. Our port rate-normalises it
|
|
(`work * (time_slice * 28)`), which agrees per-second at any frame rate, so this is not yet a
|
|
demonstrated discrepancy. Next step is a term-by-term dump (`BT_MYO_LOG`) against the authored
|
|
tuning: VelocityEfficiency 0.995, AccelerationEfficiency 0.8, thermalMass 2.5e5.
|
|
|
|
**Retitling suggestion:** this should stop being "respawn comes back hot" and become
|
|
"myomer heat rate under sustained load overshoots the failure cliff"."""
|
|
|
|
gitea.comment(137, BODY)
|
|
gitea.call("/issues/137", method="PATCH", payload={
|
|
"title": "Myomer heat rate under sustained load overshoots the failure cliff (was: respawn came back with MYOMERS heat MAXED)"})
|
|
print("posted + retitled #137")
|