#85: myomer drive heat LIVE -- the five Mech motion operands were return-0

shims, so the reconstructed integrator @004b8d18 accumulated zero forever

The integrator, its gates and the heat plumbing were all reconstructed and
running -- but OwnerVelocityMag/OwnerDriveMag/OwnerVelocityY/OwnerMotionGain/
OwnerMass were cross-family compile shims returning 0.0f, so the myomers
priced ratio^2 * damageGain * 0 every tick: ice cold at any seek (Oracle's
night-7 panel-confirmed report).

Operands re-grounded against the raw disasm + decomp and mapped to NAMED
members via a complete-Mech-TU bridge (BTMechMyomerMotionSample, mech4.cpp),
per the databinding rule:
  +0x1C4 vec  -> localVelocity.linearMotion
  +0x82C vec  -> localAcceleration.linearMotion (the authentic 15-ring
                 smoothed AccelerationLastFrame the port already maintains)
  +0x20C      -> moverMass (the collision divert's cell; the old "motion
                 gain" label was a misread)
  *(+0x250)   -> environment gravity (FUN_00421e2c: vy -= **(+0x250)/tick),
                 via GetEnvironment()->gravityConstant
So the heat physics reads: 0.005 * 1/2 m v^2 (kinetic work, per-tick/no-dt
in the binary -- kept verbatim, frame-rate note documented) + 0.2 * m g
|vy| dt (climb power) + 0.2 * m |v||a| dt (acceleration power), all scaled
by ratio^2 and (1 + zone damage).  Restored the binary's fabs(v.y) (the
draft had signed vy -- descending would have COOLED).

Authored tuning extracted from BTL4.RES (18 mech records, one shared
tuning): VelocityEfficiency=0.995, AccelerationEfficiency=0.8, gears
0.3/0.5/0.7/0.9999 rec idx 2; myomer thermal profile 77/1000/2000,
conductance 1.9e5, thermalMass 2.5e5.

Live-verified (solo arena, BT_MYO_LOG + BT_HEAT_LOG): standstill generates
~0; hard circling drove Myomers T 77 -> 1225 (past the 1000 degradation
line) and the coolant loop conducted it back to ~520 equilibrium on
slowing; damageGain live at 1.048 from grind rattle.

Known-inert remainder (filed in open-questions): the climb term reads g=0
because Mover::localEnvironment is never populated in the port
(EnvironmentZone res type 23 unwired); the mover feed (speedEffect ->
locomotion) stays WAVE 6.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019Zh7PTkFy4KwTzVighLR9J

context/open-questions.md

@@ -161,6 +161,16 @@ register.  ⚠ The audit also flags the damage-economy item as SELF-CONTRADICTOR
 (task #8 "landed" vs the kShotDamage=12 bring-up residue) — audit before reworking.
 
 ## Deferred subsystems / feeds (authentic path scoped, marked in code)
+- **Environment gravity unwired — the myomer CLIMB-heat term is inert (found 2026-07-31, #85).**
+  `Mover::localEnvironment` (MOVER.h:271) is declared and never populated anywhere in the port;
+  `GetEnvironment()->gravityConstant` is the named analog of the 1995 Mover's gravity POINTER at
+  `+0x250` (`FUN_00421e2c` does `vy -= **(+0x250)` per tick), which the myomer drive-heat
+  integrator uses for its `m·g·|vy|·dt` climb-work term.  The bridge (`BTMechMyomerMotionSample`)
+  null-guards it, so climbing currently generates no myomer heat (flat maps: moot; cavern slopes:
+  a missing cost).  EnvironmentZone resources (RES type 23) exist in BTL4.RES — wiring them (or at
+  least a constant-gravity Environment on mover birth) revives the term.  Also relevant to any
+  future airborne/jump physics (`ApplyAirResistanceAndGravity` reads the same member).
+  [[subsystems]]
 - **Revolving-door Phase 2 (true mid-mission drop-in) — PLANNED, gated on a spike**
   (`docs/REVOLVING_DOOR_PLAN.md`, 2026-07-24). Open questions before any engine work:
   (a) can an `Entity::MakeMessage` be REGENERATED post-birth (serializing current state), or

context/subsystems.md

@@ -66,7 +66,29 @@ Making a base byte-exact GROWS every subclass — they must be re-based TOGETHER
     change needs its own verification pass).
 - **WAVE 5** — Torso (aim twist/elevation; joint-I/O reconstructed; the BLH record disables torso →
   faithfully no visible twist).
-- **WAVE 6** — Myomers (mover-coupled; structural un-stub is INERT — no live mover/heat coupling).
+- **WAVE 6** — Myomers (mover-coupled; the mover feed is still inert — WAVE 6 cutover — but **DRIVE
+  HEAT IS LIVE**, #85 fix 2026-07-31, see below).
+  **✅ MYOMER DRIVE HEAT LIVE (#85, 2026-07-31) [T2].** The five Mech motion operands of the
+  drive-heat integrator `@004b8d18` were `return 0.0f` cross-family shims, so the (fully
+  reconstructed) integrator accumulated `ratio² · damageGain · 0` every tick — myomers ice cold at
+  any seek (Oracle's night-7 panel-confirmed report).  Operands re-grounded from the raw disasm +
+  the decomp and mapped to named members via the complete-TU bridge `BTMechMyomerMotionSample`
+  (mech4.cpp): `+0x1C4` vec = `localVelocity.linearMotion`; `+0x82C` vec =
+  `localAcceleration.linearMotion` (the authentic 15-ring smoothed AccelerationLastFrame);
+  `+0x20C` = `moverMass` (the collision divert's cell — the old "motion gain" label was wrong);
+  `*(+0x250)` = the environment **gravity pointer** (`FUN_00421e2c` does `vy -= **(+0x250)`/tick).
+  Physics: `heat += ratio²·(1+dmg)·[0.005·½mv² + 0.2·m·g·|vy|·dt + 0.2·m|v||a|·dt]` — kinetic work
+  + climb power + acceleration power.  The binary `fabs`es v.y (the port's old draft didn't).
+  **Authored tuning extracted from BTL4.RES** (all 18 mech variants share one record):
+  VelocityEfficiency=0.995, AccelerationEfficiency=0.8, seek gears 0.3/0.5/0.7/0.9999 rec idx 2;
+  myomer thermal profile startT=77 / degradation=1000 / failure=2000 / conductance=1.9e5 /
+  thermalMass=2.5e5.  Live-verified (solo arena, BT_MYO_LOG): standstill ≈ 0 generation, hard
+  circling drove T 77→1225 (past degradation) and the coolant loop pulled it back to ~520
+  equilibrium on slowing.  ⚠ Two carried caveats: (1) the kinetic work term has **no dt** in the
+  binary (per-tick accumulate, a 1995 fixed-frame assumption) → heat/s scales mildly with frame
+  rate; kept verbatim, field-calibrate against pod veterans.  (2) the climb term is wired but
+  inert: `Mover::localEnvironment` is never populated in the port (EnvironmentZone res type 23
+  unwired), so g reads 0 — see [[open-questions]].
   ⚠ **The registered Performance is the WRAPPER @004b8b9c, not the inner integrator @004b8d18**
   [T1, fixed 2026-07-28]. The ctor @004b8fec stores `[0x511620]` into activePerformance, and that
   pointer resolves to `0x4b8b9c`, whose first instruction is `call 0x4b0bd0` =