RETRACTION + FIX: the myomer seek->speed coupling IS in the 4.10 binary --
restored byte-grounded; the morning's removal was export-gap blindness Player testimony (Oracle, pod veteran: seek-4 humanoid = 182 kph -- the manual's printed Super Charged figure; overheat = 'freezing up') forced a re-audit of the morning's 'no dynamic myomer->speed feed' verdict. The verdict was WRONG: a raw-image capstone sweep for FPU reads of [reg+0x31C] found the consumer inside the UN-EXPORTED master-perf region -- the same decomp gap that hid the #93 crash block. Decoded @0x4a9cf2-0x4a9da4 [T1]: per frame: MAX speedEffect@0x31C over the myomer chain (+0x7AC) -> mech+0x79C mapper->speedDemand@0x128 *= it (the SPEED coupling) if |drive| <= 1e-4 (@0x4ab16c): mapper->turnDemand@0x12C = 0 (the FREEZE) Everything the manual + the veterans describe emerges: gear 4 rides speedEffect ~1.43 into the RegisterMaxOutput gait cap (base x 1.4284 -- the two mechanisms interlock: 61.5 x 1.43 = 87.9 vs cap 87.8 measured) = SUPERCHARGE; myomer heatFactor degradation slows you; overheat freezes speed AND turn; damage slows (speedEffect carries 1-damage -- #75's original premise was RIGHT and its 'falsified' close was wrong). Restored in mechmppr.cpp, byte-grounded and better than the pre-removal draft: MAX over the chain (was first-found), NO 1.0 clamp (the old clamp ate the overdrive), turn-freeze included. BTMyomersSpeedEffectOf (unclamped) replaces the deleted BTMyomersDriveOf. Verified live: healthy drive=1.0 (no speed change), collision-rattled myomers drive 0.999 -> 0.892 -> 0.742 with demand scaling in lockstep (61.5 -> 54.9 -> 45.7). KB corrected in place (subsystems WAVE 6, pod-hardware manual audit retraction, open-questions resolved) + NEW GOTCHA #21: export-gap blindness -- 'no callers in the decomp' is not 'no callers in the binary'; sweep the raw image for the operand pattern before declaring a data path dead, and when a primary source disagrees with your decomp sweep, suspect your evidence first. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019Zh7PTkFy4KwTzVighLR9J
This commit is contained in:
Joe DiPrima
co-authored by
Claude Fable 5
Claude Fable 5
parent
4704ab3d41
commit
905a4a86c0
@@ -161,8 +161,13 @@ 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)
|
||||
- **Myomer seek "SUPERCHARGE" — 4.0-manual vs 4.10-binary, AWAITING THE PLAYER VERSION-PROBE
|
||||
(2026-07-31).** The 1995 manual (p20/p22 + stat sheets) says seek changes TOP SPEED (gear 4 =
|
||||
- **~~Myomer seek "SUPERCHARGE"~~ — ✅ RESOLVED same day: the players' testimony (Oracle:
|
||||
seek-4 humanoid = 182 kph, overheat = freeze) prompted a re-audit that found the coupling in
|
||||
the un-exported master-perf gap (@0x4a9cf2). The manual was right, 4.10 HAS supercharge, and
|
||||
the port now implements it byte-grounded ([[subsystems]] WAVE 6 correction). LESSON: a
|
||||
"no callers in the decomp" claim is only as good as the export coverage — sweep the raw image
|
||||
for the operand pattern before declaring a data path dead ([[reconstruction-gotchas]]).
|
||||
Original entry below for the record:** The 1995 manual (p20/p22 + stat sheets) says seek changes TOP SPEED (gear 4 =
|
||||
"Supercharge", expert-only; Loki/Thor print Normal 143 / Super Charged 182 / Gimped 40 kph).
|
||||
The 4.10 binary provably has NO runtime myomer→speed coupling (full data-flow closure [T1]:
|
||||
demand fn @004afd10 all branches, all speedDemand writers, AvailableOutput's 2 callers, the
|
||||
|
||||
@@ -208,7 +208,15 @@ every checked control behavior:
|
||||
side button columns + **EJECT button** beside the joystick + per-mech COOLANT LOOP tables
|
||||
(weapons+generators per loop 1-6) and stat sheets (tonnage/armor/reservoir liters/heat
|
||||
sinks/top speeds incl. "Super Charged").
|
||||
- **MYOMER SEEK / "SUPER CHARGE" — a documented 4.0→4.10 DRIFT (2026-07-31) [T1 both sides].**
|
||||
- **MYOMER SEEK / "SUPER CHARGE" — ⚠ the "4.0→4.10 drift" verdict below was WRONG and is
|
||||
RETRACTED (same day).** 4.10 HAS the seek→speed coupling — in the un-exported master-perf
|
||||
gap (@0x4a9cf2: `speedDemand *= max myomer speedEffect`, turn-freeze at dead drive; see
|
||||
[[subsystems]] WAVE 6 correction). The manual is ACCURATE for 4.10; Oracle's pod memory
|
||||
(seek-4 humanoid = 182 kph = the printed figure) confirmed it and prompted the re-audit.
|
||||
The paragraph below is retained as the record of the error (its BINARY facts — the two
|
||||
exported AvailableOutput callers, the single attr ref — were correct but incomplete:
|
||||
export-gap functions are invisible to decomp text sweeps).
|
||||
~~ORIGINAL (WRONG) VERDICT:~~
|
||||
Manual p20/p22: seek "translates to a lower or higher top speed", gear 4 is named
|
||||
**Supercharge** (screenshot caption "Seek Level Is Set to Supercharge"), expert-only ("in
|
||||
standard simulation mode, you are not able to supercharge"), and "overheated myomers can
|
||||
|
||||
@@ -700,3 +700,20 @@ damage isn't only cross-TU reads (gotcha #23) — it is **which half rides the w
|
||||
**Tool:** scope the trap. `StateIndicator`/`Simulation` state traps drown in subsystem churn —
|
||||
filter to one watched object (`g_btGimpWatchMech`) and print the caller module-relative
|
||||
(`btl4+0x…`) so `tools/symcrash.py` names it. That turned a two-hour guess into one line.
|
||||
|
||||
|
||||
## §21 — Export-gap blindness: "no callers in the decomp" is NOT "no callers in the binary"
|
||||
**(2026-07-31, the myomer seek retraction — the costliest wrong verdict to date.)** The Ghidra
|
||||
export has GAPS (gitea #60): whole functions absent from `reference/decomp/all/*.c` — the
|
||||
master-perf region 0x4a9770-0x4ab188, the 0x4a03xx crit caller, @004b838c, and others. A text
|
||||
sweep of the decomp for callers/readers of a symbol **cannot see a consumer that lives in a
|
||||
gap**. The myomer `speedEffect@0x31C` demand feed was declared dead on exactly such a sweep
|
||||
("two AvailableOutput callers, one attribute reference, no raw readers") and an already-correct
|
||||
port mechanism was deleted on that basis — while the real consumer sat un-exported at
|
||||
@0x4a9cf2 (`speedDemand *= max myomer speedEffect` + the dead-drive turn freeze). Field
|
||||
testimony (Oracle: pod seek-4 = 182 kph, the manual's printed figure) forced the re-audit.
|
||||
**RULE: before declaring a data path dead, sweep the RAW IMAGE for the operand pattern** —
|
||||
capstone over the CODE section for the addressing form (e.g. FPU reads of `[reg+0x31C]`, SIB
|
||||
`[reg+reg*4+0x330]`). Minutes of scanning; it found in one pass what three decomp sweeps
|
||||
missed. Corollary: when the decomp and a PRIMARY SOURCE (the manual, a pod veteran) disagree,
|
||||
treat the disagreement as a hole in YOUR evidence first, not in theirs.
|
||||
|
||||
+17
-10
@@ -70,10 +70,20 @@ Making a base byte-exact GROWS every subclass — they must be re-based TOGETHER
|
||||
was built on a misattribution.** `@004b9550/@004b95b8` (the "ConnectToMover/DisconnectFromMover"
|
||||
bodies) are **MechWeapon::ConfigureMappables/ChooseButton** — their `+0x31C` is the weapon
|
||||
TriggerState and `**(mech+0x128)` is the CONTROLS MAPPER's button roster (proven by the
|
||||
MECHWEAP.CPP assert string + the trigger-edge detector @004b9608 adjacent). **The binary has NO
|
||||
dynamic myomer→speed feed**: `AvailableOutput` has exactly TWO callers in the whole image —
|
||||
`RegisterMaxOutput` (assembly) and the SeekVoltageGraph sampler — and `speedEffect@0x31C` is a
|
||||
published GAUGE attribute. The authentic myomer system, all live in the port now:
|
||||
MECHWEAP.CPP assert string + the trigger-edge detector @004b9608 adjacent).
|
||||
**⚠ SAME-DAY CORRECTION (the seek audit): the binary DOES have a dynamic myomer→speed feed —
|
||||
it lives in the un-exported master-perf gap** (@0x4a9cf2-0x4a9da4, raw capstone; the same gap
|
||||
that hid the #93 crash block). Per frame: MAX `speedEffect@0x31C` over the myomer chain
|
||||
(+0x7AC) → `mech+0x79C` → **`mapper->speedDemand@0x128 *= it`**, and at |drive| ≤ 1e-4
|
||||
(@0x4ab16c) the mapper's `turnDemand@0x12C` is ZEROED — dead/overheated myomers freeze speed
|
||||
AND turn. The morning's "no feed" verdict was export-gap blindness (text sweeps cannot see
|
||||
un-exported functions; the decisive tool was a raw-image capstone scan for FPU reads of
|
||||
+0x31C). Field truth agrees: Oracle (pod veteran) — seek-4 humanoids ran 182 kph (the
|
||||
manual's printed Super Charged figure), overheat = "freezing up". The port restored the
|
||||
demand scale byte-grounded (mechmppr.cpp): MAX over the chain, UNCLAMPED (gear 4 rides ~1.43×
|
||||
demand into the RegisterMaxOutput cap = SUPERCHARGE), turn-freeze included; damage slows
|
||||
(speedEffect carries 1−damage — gitea #75's original premise was RIGHT).
|
||||
The rest of the myomer system, all live in the port:
|
||||
1. **Heat** — the drive-heat integrator (#85, below).
|
||||
2. **Vital death** — myomers are the ONLY `vital=1` subsystem in the authored records
|
||||
(BTL4.RES `res+0x48` scan): destroying them KILLS the mech (the #80 vital-crit path). This
|
||||
@@ -95,12 +105,9 @@ Making a base byte-exact GROWS every subclass — they must be re-based TOGETHER
|
||||
on a damaged generator freezes the pilot's AIM until they downshift. On a healthy mech,
|
||||
gears 1-3 are literally identical (heat ratio floors at 1, no speed coupling); gear 4 =
|
||||
double heat + a tighter dropout threshold for nothing but the taller graph — a trap.
|
||||
**Deliberately REMOVED (was an invention): the `speedDemand *= speedEffect` demand multiplier**
|
||||
(mechmppr.cpp) and `BTMyomersDriveOf`. Damaged-but-alive myomers heat faster and drop the
|
||||
power curve but do NOT slow the mech — gitea #75's premise is falsified by the binary; the
|
||||
mech's damage slowdown is the LEG-damage gimp gait, a separate live mechanism. Seek gears do
|
||||
NOT change speed (heat + sourcing + graph only). Verified live: a mech with dmg=0.234
|
||||
(speedEffect attr 0.766) beelines at full commanded speed with dmgGain=1.234 heat.
|
||||
(A `speedDemand *= speedEffect` multiplier was removed in the morning commit and RESTORED,
|
||||
byte-grounded and improved, the same day — see the correction above. Verified live: healthy
|
||||
drive=1.0, collision-rattled myomers drive 0.89→0.74 with demand scaling in lockstep.)
|
||||
**✅ 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
|
||||
|
||||
Reference in New Issue
Block a user