# MECH4 — pre-TU reconstruction notes **Status: no MECH4.CPP exists yet.** The ground snap, frame rejection, knockdown stagger and collision economy that the binary keeps in mech4's master performance are currently RE-HOSTED inside `Mech::Simulate` ([[MECH]], 5.3.98–100) at seams marked STAGED. This file carries the decode work for the pieces not yet written, so it survives session boundaries. ## Mech::ProcessCollision (@004abb40) — decoded, not yet reconstructed The override of the engine's protected virtual (`MOVER.CPP:1354`), called per contact by `Mover::ProcessCollisionList`. The decomp (part_012.c:15206–15416) reads as the BASE function plus four additions: 1. **The base head, verbatim**: `collisionVolume->ProcessCollision(collision, worldLinearVelocity, lastCollisionList, &damage->surfaceNormal, &penetration)`; on a miss NOTHING runs. Clamp penetration to the slice, ratio = pen/dt, `damage->damageAmount = StaticBounce(old, dt, r, normal, &elasticity, minimumBounceSpeed, &friction)` with the elasticity/friction locals seeded from the mover's coefficients. 2. **The Mover-family branch** (owner = the collided solid's owner entity, solid+0x1c; family test FUN_0041a1a4 against the "Mover" derivation GUID @0x4e4518): * SEPARATING-CONTACT GATE: `(ourWorldVel − other->WorldVel[vtbl+0x20]) · normal < −1e-4` (`_DAT_004ac044`) → return, no damage, no dispatch. * If the other's classID == **0xbb9** (mech), build a TakeDamage message (raw wire shape `{id, len, inflictor = DAT_0050b9ac global, zone −1, the Damage verbatim}`) and Dispatch it AT THE OTHER — the mech-vs-mech ram. Use our `Entity::TakeDamageMessage` ctor as the weapon path does. 3. **The CulturalIcon branch** (GUID @0x4e7038): * `stopping = other->instanceFlags & 0x8000` (the StoppingCollisionVolume flag, entity+0x28). * Same separating gate against a ZERO other-velocity (icons are static). * Dispatch the crunch TakeDamage at the icon (crushable props have no zones → their base handler no-ops it, but the dispatch is real). * If NOT stopping: `damage->damageAmount = 0.00123f` (bits 0x3aa137f4) — the WALK-THROUGH SENTINEL. The caller (the response block in Simulate) must treat exactly 0.00123f as "the move stands": restore the post-snap saves, zero the amount, feed the gyro crunch (torque 0.4 along the normalized force, upward impulse 0.2 — binary @4aa81e/@4aa86c). 4. **The material tail**: the elasticity/friction OUT values from StaticBounce are compared against `_DAT_004ac048`; sets `collisionTemporaryState` (+0x44c) to 1, or 2 when both match and the state was 0. The state is pushed into the `collisionState` StateIndicator once per frame by the response block (0→1 fires the impact sound). Needs the `_DAT_004ac048` constant identified before writing (likely the default-material coefficient — check the literal pool at 0x4ac048). ## Two hazards the donor fought that DO NOT apply here * **Compounded StaticBounce reflections**: our engine's `Mover::ProcessCollisionList` (MOVER.CPP:1203) restores `worldLinearVelocity = initial_velocity` and position PER CONTACT before each ProcessCollision call, and averages the results. The port's `frameEntryWorldVelocity` economy guard has no counterpart hazard in this engine — do not import it. * **The AlarmIndicator ODR split**: a port-only problem; our tree reads `MovementMode()` / the alarms directly. ## Already re-hosted in Mech::Simulate (move here when mech4.cpp exists) | piece | binary | landed | |---|---|---| | ground probe + snap | @4aa630–4aa6cc | 5.3.98 | | frame rejection + crash self-damage + knockdown | @4aa6cf–4aab0b | 5.3.99 | | collision economy divert + distributor | @0x4a0368 → @0049ffcc | 5.3.100 (in the damage hub, where the binary has it) | | status→mode limp promotion | master perf (un-decompiled) | 5.3.97, STAGED | | forwardCycleRate re-pick (ground/airborne) | IntegrateMotion head | partially — the ctor sets it once; the per-frame re-pick needs +0x3f4 | ## Still to decode * `FUN_004a9b5c` — the master performance. **ISOLATED AND MAPPED (2026-08-04):** one single 5,676-byte body @004a9b5c..@004ab168 (one `ret`), hidden inside the manifest's mis-sized @004a9770 entry (that fn is really the stream-builder's 6.6KB name→SharedData strcmp resolver, and Ghidra swallowed everything to @004ab188 behind it). Registration proven from the ctor decomp: `(flags & 0xC) == 4` → replicant perf, else master @004a9b5c. Recipe: extract CODE bytes (va 0x1000 → file 0xe00), `ndisasm -b 32 -o 0x4a9b5c`. **5.3.121 corrections: the DECOMP has both perfs in plain C (master = part_013.c:3059, and @004ab430 IS the complete replicant perf — my "@004ab9d8 hidden inside it" note was its CONSTANT POOL @004ab9c8.. right after the body). Replicant perf read (not yet landed): zero +0x1dc, IntegrateMotion(dt, flavor 1); ret 1 (fresher update present) → quaternion slerp +0x10c toward the update target +0x26c with t = dt/(update age + dt) + matching velocity lerps (+0x1d0 vs +0x2a4, +0x1f4 vs +0x298); either path applies the +0x598 error-offset vector smoothed over the @004ab9cc window while the +0x5a4 latch holds, then position ← the DR anchor +0x260; without flags&0x4000 it re-resolves its room via the world chain (@0040e36c on the +0x2e8 box) → +0x2f0; same ground clamp; `FUN_00421b6c`; same five ring publishes + acceleration tail; NO update-record writer.** **The ordered call skeleton (111 calls)** — blocks in execution order, matching our Simulate's structure and locating every staged gap: 1. controls/demand intake (mech.cpp helpers 0x4a4eab/0x4a4ee9/0x4a4f9e) 2. three cerr+SetLevel triplets — illegal-state alarm guards 3. **THE DUCK DRIVER** — DECODED + LANDED 5.3.120, live-verified (BT_FORCE_DUCK cycles down/hold/up continuously on the rig). The full system: DuckRequest message 0x1A (authentic name from the binary's handler table; roster = RealMaxSpeed 0x15, BalanceCoolant 0x16, SetBurningState 0x17, ClearBurningState 0x18, EjectPilot 0x19, DuckRequest 0x1A) latches one evaluation (+0x398, one-shot, Reset clears); the phase machine reads the RAW simulation state, the mapper's duck cell (+0x25c) and the analog demand (+0x79c, deadzone 1e-4 @0x4ab16c): gait 0/4 + input -> down (LEG slot 2, sqd), gait 1 -> up (slot 3, squ); limp modes 3/4 force stand-up; the collisionVolumeState alarm (+0x4c4; 1=standing, 0=ducked; "Whoa! Bad Collision Volume State!" guard, line 417) swaps the collision template's maxY (ExtentBox +0xc == the box TOP; the ground probe's minY untouched) between the ctor-captured height and 0.6x it (the double @004a2d38); duckState publishes for the cockpit selector. Still open here: the two MarkUpdate masks (8 then 1) ride our ForceUpdate no-op, and the mapper duck cell's streamed binding id awaits a BT_MAP_LOG audit on a duck-bound RES. 4. verify-guarded state read (mech4 accessors + Fail 0x40385c) 5. gyro feed a (vec pair → gyro_b 0x4b2de4, gyro_a 0x4b2d8c) 6. death GUARD on the advance dispatch: InDeathTransition 0x49fb54; 0x4a71f4 = AdvanceLegAnimationGimp (modes 3/4 + 0x580), 0x4a5028 = AdvanceLegAnimation -- NOT a death advancer (5.3.121 correction) 7. ~~status→mode LIMP PROMOTION~~ -> the STREAMED MODE-REQUEST COUNTERS (see the 5.3.121 section; landed) 8. update-record block (0x421bac/0x40e5f0/0x4227e0/0x41db7c/0x422bac + Point3D copies) — the dead-reckon/update writer 9. collision → gyro crunch (gyro feeds + alarms) 10. knockdown/bump arms (EntityID pair + two SetAnim/Mark/SetLevel arms) 11. IntegrateMotion @004ab1c8 + position dirty marks 12. pose/joint tail: gyro_d/gyro_c → **Torso::UpdateJoints @004b66b4** → five StateIndicator::SetState publishes + four GetState reads 13. frame close (position latch) **MarkUpdate = FUN_004a4c54 (×20!)** — the update-record dirty-mask OR (death strips motion bits); our `ForceUpdate(int)` is an EMPTY STUB, so none of these marks exist in our tree yet (MP replication feed). Next sitting: instruction-level read of blocks 3 and 7 (the two STAGED items), then the mark masks. * `@004ab430` ReplicantPerformance (1432B) — the replicant-side interior. * `@004ab1c8` IntegrateMotion — decoded (see 5.3.95 notes) but only partially re-hosted: the local-velocity/orientation integration and the dead-reckon latency fold (+0x778/+0x77c) remain. **`+0x598` is a Point3D** (its replicant branch writes it with a vector subtract), so `motionEventName` in MECH.HPP is mistyped as CString — fix when this lands. ## 5.3.121 -- THE DECOMP HAS THE MASTER PERF (ledger correction + full C read) **`part_013.c:3059` = `@004a9b5c file=bt/mech4.cpp` -- the ENTIRE master performance is in the BT411 decomp as plain C.** Every "never decompiled / raw-disasm-only" note above is superseded; the asm read (scratchpad masterperf.asm) and the C agree line for line where both were done. Rule for the rest of this file: read the C first, keep ndisasm for byte-level checks. (`@004ab1c8` IntegrateMotion and `@004ab188` -- its dead-reckon position fold -- are decompiled right below it; the replicant-perf interior sits inside `@004ab430` from part_013:3804 with the SAME five ring publishes at :3948.) ### The movement-mode carrier (the big one) * **mech+0x2c is the entity MOVEMENT-MODE AlarmIndicator; +0x40 is its LEVEL cell.** Everything we had read as "raw simulationState at +0x40" is this alarm's level. It is entity-BASE machinery: the engine seeds it from the class descriptor's state count (`@0041bdf0`, `FUN_0041b9ec(entity+0x2c, *(desc+0xc))`). * Mode roster so far: 0 DefaultState, 2/9 death transition (InDeathTransition `@0049fb54` == 2||9 exactly), 3 GimpLeft, 4 GimpRight, 5-8 the four fall variants (the body machine `@004a5678` head arms body clips 0x1c-0x1f from them, one-shot latched by +0x650), 9 killed. WHO WRITES 2 and 5-8 is still undecoded (the death FSM brick). Mode 1: seen only as "not standing" in duck gates; identity open. * **The damage path writes the mode DIRECTLY**: TakeDamage `@0049c690` calls `FUN_0041bbd8(mech+0x2c, ...)` -- half-gone right leg -> 4 (`@0x49c8fb`), left -> 3 (`@0x49c926`), leg destroyed while already limping -> 9 (`@0x49c88f`/`@0x49c8c5`), vital zone -> 9 (`@0x49c83c`), gated by the REAL `InDeathTransition`. The old model (statusAlarm@0x714 as damage carrier + a Simulate "promotion") was a misconstruction -- RETIRED in 5.3.121; MECHDMG now writes the mode, and the @0x714 alarm is ONLY the body-graphic clip selector (level = body clip index 0..0x20, 0x3c-stride name table at 0x50cfe8 "StandingAnimation"...). * **Block 7 truth**: not a promotion. Three STREAMED request counters -- +0x334 DefaultState / +0x338 GimpLeft / +0x33c GimpRight (authentic names, traced to the debug stream as consumed) -- re-assert the mode alarm every frame they are positive. Writers: the creation-stream ctor `@004b3778` (record +0x1c0/1c4/1c8) and the update-record appliers; zeroed by ctor `@004a1674` and Reset `@0049fb74` (which also drops the mode alarm to 0 and zeroes +0x328/+0x32c/+0x330 -- those three cells still unidentified). LANDED with the authentic traces; inert until the MP stream feed exists. ### Corrected field identities (from the C) * **+0x79c = the MOBILITY SCALE**, not a duck analog: zeroed each frame, then MAX of item+0x31c over the +0x7ac leg roster (count via the iterator); throttle command (mapper+0x128) *= it; |scale| <= 1e-4 also ZEROES the turn command (mapper+0x12c). The duck-down pick reads it as the "legs still work" gate. Our tree HOLDS it at 1.0 ([T1]) until the leg-roster scan is reconstructed. * **+0x3f4 = the REVERSE/BRAKE flag** (the "airborne re-pick" note was wrong): set when speedCmd < 0 while +0x348 (current speed) > 0, cleared otherwise; +0x344 (the accel rate the body advancers slew by) picks +0x5b8 forward / +0x5bc reverse accel (sentinel -1.1f @0x4ab174 = whole system disabled; IntegrateMotion re-derives the pick at its head). Entering reverse: MarkUpdate(0x100), gyro kick (0,0,+/-rand)@0.4 (50% sign flip via 0x408050 rand + 0.5f compare @0x4ab170). While reversing above the walk threshold (+0x534 < +0x348): pitch kick (0,1,0)@0.2 on a 0.4s countdown (+0x5c4) -- the braking shudder. NOT YET LANDED. * +0x654 = the legResetLatch (saved at frame top, cleared, compared at frame end -> MarkUpdate(8) on change). +0x584 = squat-capable, +0x588 = turn-clip-capable, +0x580 = gimp-clip-capable. * +0x574/+0x578 = walk/run turn rates; turn attenuation: speed >= +0x538 -> t=(speed-+0x534)/(+0x34c-+0x534), lerp A->B, t>1 -> B/t^2; clamp >=0; x mapper turn cmd (+0x12c); ZERO while fallen (+0x650) or legState 1/2/3; result -> +0x1d4. * +0x348 = current speed, +0x34c = max run speed, +0x350 = min(?) speed clamp in the shortfall term, +0x7a0 = real max speed (5-notch throttle quantizer: cmd = round(5*cmd/+0x7a0 + 0.5)/5 * +0x7a0... exact rounding via ftol of +0.5f), +0x6b4/+0x6b8 = body-channel demand/speed pair. * Perf head: `FUN_0049fa1c` = the combat-effectiveness census -> +0x414: walks roster slots 2.., classID 0xBBE (generator) charge fraction +0x12c/+0x128, 0xBC1 count with state != 1 && +0x210 != 4 (working coolant units), RTTI-gated weapon count (excluding launchers with +0x364 == 7); +0x414 = 1 when weapons < +0x448 min, no coolant, charge below threshold, or limping with the duck cell 0. Consumer unknown. * Perf head one-shot: +0x7a4 set && +0x7a8 clear -> sends the **RealMaxSpeed message (0x15, 0x20 bytes)** carrying +0x7a0, then latches +0x7a8 -- the network share of the computed real max speed (pairs with the 0x15 handler @0049f604, still to land). * Link plug at +0x418: first bound entity's distance -> +0x400, presence -> +0x3fc (identity of the link: open). * Mission-list y-compare -> +0x394 (the old "verify-guarded read" block): compares *(+0x67c) against a mission-chain entry's position y when legState not 0/1 -- identity open (in-water / off-pad flag?). ### Block 8 (move/collide) -- decoded, NOT yet landed Ground clamp `FUN_0040e5f0(+0x2f0, pos)` (penetration -> pos.y and the +0x2e8 box y/z); save old basis/pos; `FUN_004227e0(this,0)` volume; +0x44c = 0; `FUN_00422bac(this, vol, dt, &oldpos, &probe)` = THE MOVE. Outcomes on probe[1] (local_1c8): == sentinel @0x4ab180 -> restore pos+basis, gyro kick along normal @0.4 + pitch @0.2, CollisionState alarm (+0x450, 3 levels) -> 0; <= 0 -> alarm 0; else REAL HIT: partner material *(partner+0x24) -> +0x4a4, world->body normal -> +0x4a8, closing speed -(n . v) -> +0x4b4 (the CollisionMaterialType / CollisionNormal / CollisionSpeed attribute cells), alarm <- +0x44c, STOP at old pos (basis <- identity const @0x4e0f74), then **collision damage = a SELF-DISPATCHED TakeDamage message (id 0x12, 100 bytes, damage type DAT_0050b9ac, attacker = own entity id +0x184)** via vtbl+0xc; slow (speed^2 <= @0x4ab184) -> legs to 0 + legResetLatch=1 (+ MarkUpdate(1| 0x40) if +0x464 == 1), fast -> stagger clip 0x20 + MarkUpdate(1|0x20). After: +0x464 changed over frame -> MarkUpdate(0x80); vel.y = pos.y - oldpos.y (raw delta); `FUN_00421b6c`; IntegrateMotion(dt, 0); dirty thresholds (+0x768 pos-xz^2, +0x76c turn-delta, +0x770 heading-delta -> MarkUpdate(0x10)/(1); mapper cmd != +0x6b4 -> MarkUpdate(4)). ### The tail (decoded, partially ours already) Instability accumulator +0x3f0, THREE terms then clamp 1.0: (|accelvec +0x82c| / +0x784 * +0x788)^2 + speed-shortfall (clamped cmd vs +0x348, relative) * +0x78c + (legState==4 ? +0x798 : 0); -> gyro+0x3a8 when gyro exists. Gyro churn `FUN_004b2eac(gyro, dt)` only when legState != 0 && +0x57c == 0, then `FUN_004b34ec(gyro)` always -- both gated !fallen(+0x650). Torso::UpdateJoints(+0x438, &+0x360) gated !fallen. `FUN_0049fe80(this)` (a second roster census -- damage-side; decode parked). Five RING BUFFERS (FUN_0043ade4 = ring push, 0x43ae47/ 0x43ae0b = ring reduces): +0x7e0<-vel.z, +0x7ec<-vel.y, +0x7f8<-vel.x, +0x804<-turn rate, +0x810<-dt; smoothed values -> acceleration vector +0x1dc (delta/sum-dt vs prevs +0x81c..+0x828) -> copied to +0x82c (the instability input). `FUN_00421b2c` opens AND closes the frame (called twice); the mobility iterator is destroyed at the very end (`FUN_004a4ffb`). ### Landed in 5.3.121 MECHDMG kill/limp writes retargeted to the mode (SetSimulationState); IsMechDestroyed reads the mode (>= 9); the staged promotion replaced by the authentic counter block (+ ctor/Reset zeroes + Reset mode drop); the duck driver moved to its authentic slot (counters -> duck -> limp standup -> volume swap -> advance) and its gate renamed mobilityScale; the advance dispatch death-guarded. SIDE EFFECT: `Mech::InDeathTransition` and the camera director's cut-away are now LIVE (mode 9 is finally written on kills) -- the director path needs a rig eyeball when a pod is back. ## 5.3.122 -- the message roster fills (three of the six landed) Landed: **RealMaxSpeed** (@0049f604: adopt streamed +0x7a0 while +0x7a4 clear; wire payload at +0x1c, sender EntityID stamped at +0xc by Entity's network send @0041f640 = {stamp id, msg+0x14 <- entity+0x194, EntityManager (app+0x30) send @00434ea0}), **SetBurningState** (@0049f674: park the wreck at (localHostID x 10000, localHostID x -1000) -- constants @0049f6fc/f8, host id = HostManager::GetLocalHostID, THE accessor the instance dispatch compares against ownerID -- then MODE 2 = BURNING, the second InDeathTransition state's missing writer, + ForceUpdate(1) + AlwaysExecute), **ClearBurningState** (@0049f700: mode 0 + same pair). simulationFlags bit 1 == DontExecuteFlag (SIMULATE.HPP) -- the binary's `&= ~2` IS AlwaysExecute(). Still to land from the roster: * **BalanceCoolant @0049f728 -- LANDED 5.3.123** (equal-split press + RedistributeCoolantShares @0049f788 + the heatable ctor sweep that populates the heatableSubsystems chain + ctor/Reset redistribute calls; soak: 20 heatables, first share 0.05, ctor + BT_PRESS_BALANCE both renormalize, crash-sig 0). UNIFIED 5.3.124: MoveValve steps the heatable-base coolantPriority and calls the mech's RedistributeCoolantShares; valveState and the condenser-local renormalization are retired (RecomputeValves survives only as the [T3] conduction-flow bridge -- the fight-verified pump consumes a CONDENSER-relative fraction, refreshed from the redistribute tail; the ratios are numerically identical to the old math since non-condenser priorities cancel). REGISTRATION CAVEAT: the @0x50e534 name table sits in the HEAT TU statics but its owning class (heatable base vs Condenser) is NOT proven -- our registration stays Condenser id 4 (the live-verified streamed binding); revisit if a non-condenser valve binding ever surfaces. ValveSetting attribute still publishes coolantFlowScale (the displayed fractions are unchanged). * **EjectPilot @0049f854 -- LANDED 5.3.125** with the census (@0049fa1c -> combatIneffective, the master perf's opening call). Census truths, all pinned: 0xBBE = the AGGREGATE HEATSINK BANK (its coolant fraction +0x12c/+0x128 < 0.05 @0049fb50 = crippled term; my earlier "generator charge" reading was wrong), 0xBC1 = GENERATOR (working = state != 1 && generator state != 4 = GeneratorFailed -- our enum matches), weapons by RTTI with dry launchers excluded (+0x364 == 7 == our NoAmmoState exactly), minimum weapon count = mech+0x448 = CTOR-HARDCODED 2 (part_012.c:15749), limping without the crouch cell completes the roster of crippled terms. The eject: mode 10 + mapper ejectLatch (+0x258) + self-dispatched explosive TakeDamage (type 2, zone -1 -> cylinder resolver, impact = own position). STAGED, recorded: the damage amount (binary reads *(*(mapper+0x208)+0x1c), a bound/cached pointer with NO game-side writer in the decomp -- needs the mapper ctor binding-loop decode) and the score notify (@00429078 accessor + app+0x20 vcall, event code 5 -- same poster idiom as the player-side @004c1044 throttle). Dev kit: BT_FORCE_CRIPPLED=1 + BT_PRESS_EJECT=1 (pod_render_eject.conf). THE AUTHENTIC MESSAGE ROSTER IS NOW 6/6. Mode roster: 0 default, 2 burning, 3/4 gimp L/R, 5-8 falls, 9 killed, 10 ejected; writers of 5-8 still open. ## 5.3.127 -- THE SUPER STOP + THE INSTABILITY MODEL (landed) **The model resource's own field names decoded these blocks.** The ctor loads (part_012.c:15798-15804) tie the master perf's anonymous offsets to the authored names our `Mech__ModelResource` already carried: | model rec | mech | name (authentic, from the struct) | |---|---|---| | +0x44 | +0x344, +0x5b0, +0x5b8 | `maxAcceleration` (live rate + forward figure) | | +0x48 | +0x5bc | **`superStopAcceleration`** | | +0x4c | +0x5c0 | `throttleAdjustment` | | +0x80 | +0x784 | `maxUnstableAcceleration` | | +0x84 | +0x788 | `unstableAccelerationEffect` | | +0x88 | +0x78c | **`unstableGunTheEngineEffect`** | | +0x8c | +0x790 | `unstableSuperStopEffect` (streamed, consumer OPEN) | | +0x90 | +0x794 | `unstableHighVelocityEffect` (streamed, consumer OPEN) | | +0x94 | +0x798 | **`unstableStopedTurnEffect`** | That naming is what made the instability formula legible: the term added when the leg gait state is 4 is `unstableStopedTurnEffect` and gait 4 IS turn-in-place; the speed-shortfall term is `unstableGunTheEngineEffect`. The names confirm the arithmetic, and the arithmetic confirms the names. **The super stop** (@0x4aa353): the throttle going negative while the mech still rolls forward is a hard brake, not a reverse. Edge -> swap +0x344 from the forward rate to `superStopAcceleration`, MarkUpdate(0x100), and ONE random-signed lurch through both gyro channels at weight 0.4 (magnitude roll + a 0.5 coin flip @0x4ab170). While it holds above the walk threshold, a (0,1,0)@0.2 pitch kick every 0.4s. Release restores the forward rate. `superStopAcceleration == -1.1` (@0x4ab174) DISABLES the system for that chassis -- the sentinel must survive the model read unguarded. **The instability accumulator** (tail @0x4aab8e): three weighted terms, clamped to 1, into `unstablePercentage` (+0x3f0 -- ALREADY a published cockpit attribute in our tree, so this lights a live gauge) and republished to gyro+0x3a8. The gyro's own tip/sway machinery (@004b275c) reads that sum against its +0x3bc threshold -- that consumer is the next gyro brick. Term 1 rides the ring-buffer acceleration (+0x82c) and stays inert [T1] until the rings land. **CORRECTION to 5.3.122**: `realMaxSpeed` was a DUPLICATE member for mech+0x7a0, which our tree already carried as `runSpeedMax` (the myomers raise it). Merged; the 0x15 handler writes `runSpeedMax`. And the +0x7a4 "we computed our own" flag is set by the ctor's MYOMERS sweep (part_012.c:15874) -- i.e. a mech with myomers broadcasts its cap, a mech without adopts the streamed one. **Gyro primitives already existed**: FUN_004b2d8c == our `Gyroscope::ApplyDamageImpulse` (eyeForce), FUN_004b2de4 == our `ApplyDamageTorque` (bodyForce). OPEN, worth a look: the binary's torque zeroes bodyForce.y then negates ONLY .x (+0x308); ours negates the whole vector, so the .z sign may differ. ## 5.3.128 -- THE TELEMETRY RINGS (landed) The five ring buffers ARE the engine's `AverageOf`, and our tree already carried them: `telemetryFilter[5]`, sized 15 in the ctor since the Mech-layout wave, fed by nothing until now. `FUN_0043ade4` = `Add` (with wraparound), `FUN_0043ae0b` = `CalculateAverage`, and `FUN_0043ae47` = **`CalculateOlympicAverage`** -- sum minus min minus max over count-2, the authentic name for a judge-style trimmed mean. Feeds: vel.z / vel.y / vel.x / turn rate / frame slice. The derived acceleration is the change in FILTERED values over the FILTERED slice, which is why instability answers a sustained shove and not one noisy frame. TWO ODDITIES KEPT VERBATIM (the binary is explicit; do not tidy them): the vel.y ring is fed every frame and never reduced, and the acceleration's components are a mongrel -- x from mean vel.x, y from MEAN vel.z, z from OLYMPIC vel.z. Only the LENGTH is consumed, so behaviour is unaffected. LIVE RESULT + A FREE DIAGNOSTIC: `unstablePercentage` now moves over its whole range (0 -> 1.0 clamp) on the rig. Walking, it pins near 0.84-0.99, dominated by the gun-the-engine term -- because the mech demands 35.9 u/s and the reconstructed gait delivers 7.0. Whether that gap is authentic acceleration or a gait shortfall is a SEPARATE open question, and the new gauge is now the instrument for answering it (BT_TELEMETRY_LOG). ## 5.3.129 -- THE MOBILITY SCAN (landed; the mobilityScale [T1] retired) **Chain identity PROVEN, not inferred.** My 5.3.122 note pinned the +0x7ac chain to Myomers "by static-layout adjacency to the string pool" -- a weak argument that nearly went wrong, because the first cell I checked (+0x31c) is a MechWeapon trigger in the weapon TU. The decisive evidence is arithmetic: the Myomers cap-raise @004b8ef0 (our `Myomers::RegisterMaxOutput`) reads `seekVoltage` at +0x330 indexed by `maxSeekVoltageIndex` at +0x32c. Walking OUR member order backwards -- maxSeek 0x32c, minSeek 0x328, recommended 0x324, current 0x320 -- lands `speedEffect` exactly on +0x31c, the cell the scan maxes. GUID 0x51155c == Myomers, confirmed. (0x511830 == MechWeapon was independently confirmed by the census, which tests it and then tests 0x5121a8 for the dry-launcher exclusion.) The scan: max `speedEffect` over the chain -> the mobility scale, applied straight to the mapper's command cells (throttle *= scale; a scale inside the 1e-4 deadzone ALSO zeroes the turn -- a mech with dead muscles cannot even pivot). It is the same cell the duck driver reads as "the legs still work". Guarded by the myomer count, so a chassis without them is untouched. SAFE BY CONSTRUCTION: the mapper reassigns its demands from scratch in InterpretControls, which ticks before the mech's own performance, so the in-place multiply cannot compound frame to frame. The ctor's myomer sweep is also what sets +0x7a4 -- so a mech WITH myomers computes and broadcasts its own top speed, and one without adopts the streamed value. Both halves now land together. Soak: `[mobility] scale 1 over 1 myomers` on an undamaged bhk1 -- throttle unscaled, drive unchanged (demand 35.9, speed 7.0), zero faults. ## 5.3.130 -- two findings from re-reading landed code **A REAL SIGN BUG, fixed.** `Gyroscope::ApplyDamageTorque` (binary @004b2de4) ended with `bodyForce.Negate(bodyForce)`, but the binary negates ONLY the x component in place (`*(+0x308) = -*(+0x308)`) after zeroing y at +0x30c. `Vector3D::Negate` flips all three, so the z component has carried the wrong sign on every damage shake and every collision crunch since the function landed. Fixed to `bodyForce.x = -bodyForce.x`. STILL WORTH A LOOK: `ApplyVerticalImpulse` ends with `bodyForce.y = bodyForce.x`, which is odd enough to want its binary address found and checked the same way. **THE DAMAGE AVERAGES: computed, consumed by nobody -- NOT landed.** `@0049fe80` (the master perf's second census) writes three means to mech+0x354 / +0x358 / +0x35c: over the HULL zones, over every subsystem's private zone, and over the MYOMERS' private zones (the 0x51155c test -- the same GUID the mobility scan proved). Default 0.0 (@0049ffc8) when a count is empty. A reader hunt found none. The apparent hits at part_013:9498 and 13728 are on OTHER objects at the same offsets -- the gyro's damage multipliers inside its damage fan-out (@004b2980) and a myomers cell inside the myomer simulation (@004b8d18) -- a reminder that offsets are per-class and a bare `+ 0x354)` grep proves nothing. No Mech attribute row binds them either. Landing them would be three loops feeding dead memory, so per the project rule (record where the binary is silent, never invent a consumer) this stays decoded and unlanded until a consumer turns up. ## 5.3.131 -- the instability loop CLOSES, and a family of watchers is found inert **The loop is closed.** `@004b275c` -- the gyro's sway slew -- was ALREADY reconstructed in our tree, and it already read the cell the master perf writes: `swayBias`, which nothing had ever written. So the 5.3.127 `mechInstability` member I added on the gyro was a DUPLICATE of that same cell (the second such mistake this arc, after `realMaxSpeed`/`runSpeedMax` -- the lesson is the same: grep our own tree for an existing carve before adding a member for a binary offset). Merged: the master perf now publishes into `swayBias` through a setter, and the instability model finally does something -- an unstable mech shakes its pilot harder, through code that was already correct and waiting. Also landed: the binary's impaired gate has THREE terms and ours had two. A gyro DESTROYED outright (`gyro+0x40 == 1`) swings to the impaired sway base, not only an unpowered or heat-failed one. VERIFIED on the rig (BT_SWAY_LOG): bias arrives (0 -> 1.0 -> 0.90), the angle slews toward base+bias and stays inside the authored [0, 1.2] band, zero faults. ### NEW DEFECT FOUND, precisely located, NOT fixed here The same log showed `impaired=1` for an entire clean run. Instrumenting the three terms settled it: `state=0 heat=0` (so my new term is inert and correct) but `watchdog=0` where Ready is 4 -- that term fires forever. Chasing it up: `PowerWatcher::UpdateWatch` sets the watchdog from the WATCHED subsystem's voltage state and falls back to 0 when `watchedLink.Resolve()` is NULL. And `watchedLink` is DEFAULT-CONSTRUCTED (HEAT.CPP:886) and **bound nowhere in the tree** -- not for PowerWatcher, not for HeatWatcher (HEAT.CPP:964 resolves the same way). So the whole WATCHER family is inert: every watcher resolves NULL, every PowerWatcher reports its target unpowered, and the gyro has consequently been sitting on its `percentageOnDestruction` sway base since the sway model landed -- invisibly, until this log existed. The fix needs the streamed watch index out of the watcher resource plus the ctor bind, in the shape the crit-table binding already uses. That is a proper brick, not a guess, and guessing a binding is exactly what this project's rules forbid -- so it is recorded here for the next sitting. ## 5.3.132 -- THE WATCHERS ARE BOUND (the family stops being inert) The missing piece found in 5.3.131 is landed. `HeatWatcher` has always streamed `watchedSubsystem` and read it into a member; nothing ever turned that index into the link `UpdateWatch` resolves. The Mech ctor now binds them in a POST-WALK pass -- necessarily post-walk, because a watcher may watch a subsystem with a HIGHER roster id, which does not exist yet while the segment walk is still running -- with out-of-range and self-reference skipped rather than trusted. THE BINDINGS PROVE THEMSELVES. Every index resolves to a semantically right target on bhk1, which a wrong offset could not do: Gyroscope -> Avionics HUD -> Avionics Torso -> Myomers Searchlight -> Avionics AmmoBinAFC100 -> AFC100 AmmoBinLRM15_1 -> LRM15_1 AmmoBinLRM15_2 -> LRM15_2 The gyro and HUD watch the avionics bus, the torso watches the muscles that move it, and every ammo bin watches its own gun. ### The next question, now sharply posed With the link live the gyro's watchdog moved 0 -> 1, so it is no longer the NULL fallback. But 1 is not Ready (4), and `UpdateWatch` can produce 1 two ways: the watched subsystem reporting NoVoltage, or the BROWNOUT branch (watched Ready, but its generator's measured voltage at or below `minVoltage * RatedVoltage`). Avionics is classID 3011 -- a SENSOR instance, named "Avionics" in the art -- and the roster-live line reports a Sensor at voltState 4. So the watched subsystem looks READY, which points at the BROWNOUT branch firing persistently. Next sitting: is `minVoltage` authored/read correctly on these watchers, or is the reconstructed generator genuinely sitting at the brownout threshold? Log the watched level and the measured/rated pair side by side to separate them -- do not adjust a threshold to make an alarm quiet. ## 5.3.133 -- THE BROWNOUT WAS A UNIT BUG (chain closed end to end) The question posed in 5.3.132 is answered, and it was neither of the guesses being weighed -- it was arithmetic. `BT_WATCH_LOG` printed the whole comparison in one line: 'Gyroscope' watched='Avionics' level=4 minVoltage=50 measured=10000 rated=10000 brownout=1 Every term is legible there. The bus is READY and at FULL rated voltage (10000 of 10000) -- so there was never a real brownout. The trip value was 50, and the test `measured <= minVoltage * rated` reads `10000 <= 50 * 10000`, which is true for any voltage whatsoever. The field is called `minVoltagePercent`. It is a PERCENT, and we stored it 1:1 -- our own comment had flagged the missing scale as "a tuning value (stored 1:1 here until located)". The authored data admits no other reading: bhk1 gives the Gyroscope and HUD 50 and the Searchlight 10, round percents that are absurd as raw fractions (5000% / 1000%). Divided by 100 the gyro trips below 5000V of a 10000V bus, which is a sane undervoltage threshold, and the Searchlight -- a light -- tolerates far more sag before complaining, which is exactly the right ordering. CHAIN NOW CLOSED, all four links verified live in one run: watcher bound (5.3.132) -> watchdog reads the target's REAL state (4, Ready) -> impaired FALSE for the entire run (31 samples, none impaired) -> the gyro sways on `percentageOnNormal` instead of its destruction-grade base. NOTE ON PROVENANCE: the binary's own scale SITE was not located in code; the /100 is inferred from the field name plus authored data that is unambiguous. Recorded as such rather than claimed as a byte-verified decode. ## 5.3.134 -- THE "GAIT SHORTFALL" WAS A CONFOUNDED MEASUREMENT The top open question from 5.3.128 -- "the mech demands 35.9 u/s and the gait delivers 7.0, authentic acceleration or a gait shortfall?" -- is answered: **authentic acceleration, and the measurement was confounded by my own soak harness.** The run I drew that reading from was `pod_render_telem`, which still had `BT_SUPERSTOP_SOAK` driving the throttle to -0.5 every six seconds. The mech was never given time to reach top speed; every sample caught the first seconds of a climb that was about to be thrown into reverse. `BT_GAIT_LOG` (new, state-change-triggered) on a clean full-throttle run shows the ladder working exactly as designed: leg=5 speed=0 -> stand-to-walk leg=7 speed=5.69 leg=6 speed=17.0 -> the walk-to-run step leg=11 speed=17.7 leg=12 speed=25.5 leg=13 speed=35.7 leg=12 speed=44.35 target=44.837 legCycle=bodyCycle=44.837 The mech accelerates 0 -> 45 u/s through six clip transitions and settles on its demand. `runSpeedMax` reads 80.06, raised off its unsourced default by the myomers -- the 5.3.129 landing doing its job. Both run-clip slots are bound (clip6=344, clip8=345). So the instability model pinning high during a climb was CORRECT all along: a mech demanding far more speed than it has IS gunning the engine. Nothing to fix in the gait or the instability model. **METHOD LESSON, the expensive kind:** I took a measurement from a rig whose harness was actively fighting the thing being measured, and wrote the result into the notes, a commit message and memory as an open defect. The hedge ("authentic or shortfall?") was the only thing that saved it from becoming received wisdom. Before recording a number as evidence, check what else the conf is driving. ## 5.3.135 -- WHAT THE WATCHER FIXES ACTUALLY TURNED ON Chasing the downstream of 5.3.132/133 (watchers bound, brownout unit bug fixed) found a user-VISIBLE consequence nobody was looking for. `HeatWatcher::WatchSimulation` mirrors the WATCHED subsystem's temperature into the watcher's own 3-level heat alarm. With every link NULL it held NormalHeat forever, so the mirror was dead: the gyro never felt a hot avionics bus, the torso never felt hot myomers, no ammo bin ever felt its own gun's heat. That mirror is now live for all seven watchers. **THE HUD PAGE WAS PERMANENTLY HIDDEN.** `HUD.CPP:145` gates page visibility on `watchdogAlarm.GetLevel() != PoweredSubsystem::Ready` (4). Unbound, the watchdog read 0 -> hidden. Bound but with the percent bug, it read 1 -> still hidden. It took BOTH fixes to reach 4: [hud] page_visible=1 watchdog=4 heat=0 So the HUD page is drawing for the first time. **Flag for the next cockpit A/B session**: the gauge-ab rig last scored 98.9% identical against the shipped binary with this page missing on our side -- if the shipped exe draws it, some of that residual 1.1% should close on its own, and the comparison needs re-running rather than trusted from the old number. Still worth exercising now that the mirror is live: what an AmmoBin does with its gun's heat alarm (a cook-off or a feed lockout would be the obvious candidates, and the binary is the place to check before assuming either). ## 5.3.136 -- THE AMMO COOK-OFF, decoded (the payoff of binding the watchers) Asking what an AmmoBin does with its now-live gun heat alarm turned up a whole mechanic that has never run in our tree, for TWO independent reasons: the watch link was unbound (5.3.132) so the mirrored alarm never left NormalHeat, AND our `AmmoBin` has no Performance at all -- the binary installs one (ctor @004bd5c4 stores the triple @0x512654 -> `@004bd394`, gated master+dynamic as usual). **The trigger** (@004bd394): when the bin's mirrored heat alarm (+0x140) reads 2 = FailureHeat -- i.e. THE GUN IT FEEDS is cooking -- and the bin is not already spent (+0x1a8 != 2) and no countdown is pending, it latches one: `cookoffAt = now + ` (time from @00414b60, the delay through the ftol helper @004dcd94). If the heat clears the countdown is CANCELLED; if it expires the bin destroys itself (state alarm -> 1, dirty mark) and detonates. **The detonation** (@004bd300 -> @004ac274), and the damage is authored per round: `damage = roundsRemaining * perRoundDamage (+0x1f4)`, so a full bin guts the mech and a nearly empty one barely coughs. @004ac274 then: * drives the bin's own state alarm 2 then 1 with an update mark each, * pins its PRIVATE damage zone to 1.0 (destroyed), * collects a target set by walking @004acfa9(mech, -1) and keeping entries whose `+4` field equals **0x4e**, * **divides the damage by the number of targets** -- the blast is SHARED, not applied whole to each, * dispatches a 100-byte TakeDamage (id 0x12) at each, printing the authentic `"ammo explosion damaging "` for every victim, * finally zeroes the ammo count and sets the bin's 6-level state alarm (+0x194, ctor `FUN_0041b9ec(+0x194, 6)`) to 2. **THE ONE THING TO PIN BEFORE LANDING**: what @004acfa9 iterates and what `+4 == 0x4e` selects. 0x4e is not a classID (those are 0xBBx), and the per-victim reads -- a name via `*(+0x15c) + 8` and an index at `+0x13c` -- look more like DAMAGE ZONES than subsystems. Getting this wrong would produce a plausible mechanic that damages the wrong things, which is exactly the failure mode this project keeps catching, so it is decoded no further here. Read @004acfa9 and @004ad03a/@004ad0a4 (the collector and its list) first, then land the whole thing in one piece. Note the shape of the find: two dead systems in series hid a third. The watcher binding did not just fix an alarm -- it exposed that the mech has never been able to suffer an ammo explosion. ## 5.3.137 -- THE AMMO COOK-OFF LANDS The blocking identity from 5.3.136 is settled: **DamageZoneClassID == 78 == 0x4e**, computed from our own VDATA enum, so the collector's filter selects DAMAGE ZONES and the blast is shared across the mech's zones. Also CORRECTING my 5.3.136 write-up: I said heat clearing cancels the countdown. It does not. Re-reading @004bd394, both the arm gate and the cancel test the SAME cell (+0x1a8, adjacent to the ammo alarm and read as the alarm having settled on SPENT). Once armed, a cook-off is only called off by the bin being spent or destroyed -- letting the gun cool does NOT save you. Landed: `AmmoBin::AmmoBinSimulation` (a Performance the class never had, installed master+dynamic gated as the binary's ctor does) plus `AmmoBin::CookOff`. Our fuse is a millisecond COUNTDOWN where the binary stores an absolute deadline -- same behaviour, no clock-source dependency. LIVE (BT_FORCE_COOKOFF=1, pod_render_cookoff.conf): [cookoff] 'AmmoBinAFC100' ARMED -- 20 rounds aboard [cookoff] 'AmmoBinLRM15_1' ARMED -- 16 rounds aboard [cookoff] 'AmmoBinLRM15_2' ARMED -- 16 rounds aboard [cookoff] 'AmmoBinAFC100' DETONATES: 20 x 25 = 500 over 22 zones [cookoff] 'AmmoBinLRM15_2' DETONATES: 16 x 50 = 800 over 22 zones [critfail] 'Searchlight' DESTROYED ... 'ThermalSight' DESTROYED The randomised fuse spreads the rack (the three bins go off at different times, not on one frame), and the blast feeds straight into the existing destruction cascade. ### [T1] THE PER-ROUND CHARGE IS A STAND-IN The binary reads it from the bin's streamed EXPLOSION RECORD (+0x1f4 -- the second field of the block our `cookOffState[12]` reserves and nothing parses), then writes the product back into a copy of that record. Until that record is parsed we use the FED WEAPON's authored per-shot damage: right order of magnitude, physically sensible, but a stand-in to be replaced by the first pass over the ammo resource block. **A caught mistake worth keeping:** the first landing used `heatPerRound` for the charge. That is a HEAT figure of about 3e-9, so the detonation computed 4.8e-08 of damage and did nothing at all -- a mechanic that fires, announces itself, and is silently inert. Only printing the arithmetic in the soak log exposed it. Log the numbers, not just the event.