92783b9935f0935b4c80d91ee246a15bb90ca350
16
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
9657fbb11e |
control mode: REPRODUCE the "centering fought my control" fight, and prove the fix in Sauron's config
Follow-up to
|
||
|
|
4ccc2a7eec |
control mode: Basic re-centre used the STICKY held-button cell -- and the elevation-limit swap was never ported
Sauron: "toggled through advanced controls from standard to advanced and back
to standard -- lost torso control."
The cycle is 0 Basic -> 1 Standard -> 2 Veteran -> WRAPS TO BASIC, so getting
from "advanced" back to Standard PASSES THROUGH BASIC, whose arm re-centres the
torso. @004afbe0 is a complete spec and the port got three things wrong:
iVar1 = mech+0x438 (TORSO) iVar2 = mech+0x5b4 (HUD)
if (mode == 0) { // BASIC
*(iVar1 + 0x1f0) = 0; // analogTwistAxis
*(iVar1 + 0x274) = 1; // recenterActive
*(iVar1 + 0x220) = *(iVar1 + 0x228); // vertLimitTop
*(iVar1 + 0x224) = *(iVar1 + 0x22c); // vertLimitBottom
*(iVar2 + 0x2a0) = 1; // HUD flickerActive
} else if (mode - 1U < 2) { // STANDARD/VETERAN
*(iVar1 + 0x220) = *(iVar1 + 0x230);
*(iVar1 + 0x224) = *(iVar1 + 0x234);
}
1. WRONG CELL. Basic called CommandRecenter() -> centerCommand (@0x208), the
HELD-BUTTON cell: TorsoSimulation re-arms recenterActive from it EVERY frame
it is non-zero, and only the input path clears it -- a mode switch has no
button release to follow. Digital twist commands are processed BEFORE the
centerCommand block, so while it is set they are overridden as fast as they
are applied: the torso stops responding. The binary sets recenterActive
(@0x274) directly -- a ONE-SHOT that self-clears on settle
(`recenterActive = Recenter(dt)`) and is cancelled by any twist input.
2. THE ELEVATION-LIMIT SWAP WAS MISSING ENTIRELY. Two authored pairs exist --
BASIC @0x228/@0x22C (full top, HALF bottom) vs STANDARD/VETERAN @0x230/@0x234
(the full pair) -- and all four members were ctor-written and read by NOTHING.
Basic never restricted downward travel; the assisted modes never restored it.
3. Basic also raises the HUD's flickerActive (@0x2A0) so the horizon re-settles
with the torso it just re-centred. Not ported. (New BTSetHudFlickerActive
bridge in hud.cpp -- mechmppr sees Subsystem*, not HUD.)
Also removed an invented SetAnalogElevationAxis(0); the binary zeroes only 0x1F0.
MEASURED A/B (scratchpad/night13/modecycle.sh, LEGACY=1 for the old path;
BT_LEGACY_MODE_RECENTER=1 is the revert switch):
ctrCmd=1 samples legacy 26 fixed 0
vLim pairs fixed run shows BOTH -- (-0.698..0.349) = -40..20 deg
assisted, and (-0.349..0.349) = -20..20 deg Basic.
Before this commit only the ctor pair ever appeared.
WHAT IS *NOT* PROVEN. I did not reproduce Sauron's PERMANENT loss. In this
bench the legacy latch is periodic, not sticky:
..........LLLL......LLLL......LLLL......LLLL......LLLL......LL
because the desktop key bridge writes centerCommand every frame and zeroes it
when no button is held, so it self-recovers. The torso IS locked while the cell
is set, which is the symptom -- but whether it stays locked depends on the input
path OWNING that cell. On the glass/pad route (Sauron's) nothing may clear it,
which would make it permanent. So: mechanism fixed and binary-grounded, exact
field persistence unverified. Field-verify by cycling modes on a pad build.
Probe: the BT_TORSO_LOG gate line now carries ctrCmd / recen / vLim.
Bench hook: BT_MODECYCLE_EVERY=<n> cycles the mode from the mapper (the pod's
own route is console key 0x13d -- not a RIO button, so BT_BTNTEST cannot press
it, and mech4's BT_MODECYCLE_TEST counter did not advance in a solo run).
NOTE the bench needs BT_KEY_BRIDGE=1: with a PadRIO present the key-bridge
block that consumes the cycle is skipped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
|
||
|
|
f36f0136c8 |
#148: restore the ENGINE's replicant instance-branch in the Mech subsystem tick
Correct on its own merits as a fidelity fix; it is NOT the cause of #148, and I am not claiming it is. Entity::Perform (ENTITY.cpp:733-793, real engine source [T0]) picks the executable predicate BY INSTANCE: if (GetInstance() != ReplicantInstance) IsNonReplicantExecutable() else IsReplicantExecutable() and the two differ exactly on the replicant case (SIMULATE.h:195-206): NonReplicant : (flags & DontExecuteFlag) == 0 Replicant : (flags & DontExecuteFlag) == 0 || lastUpdate >= lastPerformance `ExecuteOnUpdate()` SETS DontExecuteFlag -- it means "do not tick me every frame, tick me when an UPDATE ARRIVES". Mech's reconstructed tick loop used the NonReplicant predicate for EVERY mech, dropping the branch, so on a replicant any ExecuteOnUpdate subsystem could never run however many records arrived. Restored. Measured: it does NOT move #148 (first TorsoCopySimulation call 1014 -> 1006, noise). So the torso's own flag was not the gate. Keeping it because the engine source is unambiguous about what the loop is supposed to do. WHAT #148 ACTUALLY IS, now much better characterised: * The record CADENCE is authentic -- my original "only 13 records" framing was wrong. Payloads are the sweep EXTREMES with `rate` flipping sign each time (atUpd 0.0437, 2.3558, -2.3928, 2.3854, ...): the master sends on RATE CHANGE and the peer dead-reckons `atUpd + rate * elapsed` between them. 12 records for 12 direction reversals is correct, not starved. * The real defect is that the peer's copy torso PERFORMANCE does not run at all until log line ~1006, while its first record arrived at line 205 -- ~800 lines of correctly-replicated twist integrated by nobody. The first tick coincides with the replicant's MODEL bring-up, not with record arrival: [loadclips] end: fScale=0.8 ... hasGimpClips=1 [clipfix] mech 05769358 -> EXTERIOR (lean) [torso] PushTwist COPY node=057A3C68 type=1 twist=-1.52319 so the gate is above the subsystem level, in replicant model/clip init. Not yet found; #148 stays OPEN. Also: [torso-copy] logs on call #0 (s_cl++ % 120), so its first line IS the first Performance call -- that is what makes the 205-vs-1006 gap readable, and it is why the earlier "first copy currentTwist != 0 at 1016" reading was a SAMPLING artifact, not a measurement of when the twist started. Probe additions kept: [torso-copy] now prints limL/limR/enab (which ruled out the ComputeTargetTwist clamp -- limits load correctly at +/-2.44346 on the copy), and [launchframe] now prints the shooter's live torso twist so twistDelta and its driver sit on the SAME line. That pairing is what proved #141 is fully fixed: every zero-twistDelta peer launch reads liveTwist=0, and the first launch with liveTwist=-1.84061 reads twistDelta=-1.83813. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC |
||
|
|
05d7b5890a |
#141 peer missiles: the launch frame read a STALE segment cache on replicants
Oracle: "missiles are firing in the direction the mech feet are facing ...
and then coming around to track the target", peer POV only -- the shooter's
own view is correct.
REPRODUCED AND MEASURED (scratchpad/night13/missileframe.sh, 2-node: only A
sweeps its torso and only A fires, so every REPLICANT line in B's log is the
mirror of one A salvo). New [launchframe] receipt prints the yaw of the
launch forward vs the BODY forward on both nodes:
master n=165 |twistDelta| max=2.2962 mean=1.2283 >0.1rad: 100%
REPLICANT n=165 |twistDelta| max=0.0000 mean=0.0000 >0.1rad: 0%
segResolved=1 on BOTH, and segYaw == bodyYaw EXACTLY on the peer.
WHAT IT IS NOT. Both sides already pass the mount segment (mislanch.cpp:363
master, :478 replicant mirror, both `GetSegmentIndex()` from task #67), and
the peer's torso data is fine end to end: records arrive (atUpd=2.44/-2.39,
rate 0.305), the copy extrapolates correctly (cur=-2.13987 target=-2.13987
copy=1), and the copy torso demonstrably writes its joint (PushTwist COPY
twist=-1.49601). Hierarchy is identical too: same seg 18, same parentIdx 4,
non-null parent + joint subsystem on both.
ROOT CAUSE. BTPushProjectile composed the frame BY HAND --
`mw.Multiply(seg->GetSegmentToEntity(), localToWorld)`. But
EntitySegment::GetSegmentToEntity (SEGMENT.cpp:262) recomputes ONLY when
`segmentModified` is set, and the thing that sets it after a joint moves is
JointedMover::GetSegmentToWorld (JMOVER.cpp:136-146), which tests
AreJointsModified() and then marks every segment dirty. Hand-composing skips
that, so you read whatever cache is sitting there. On the MASTER that was
invisible -- the renderer/cockpit camera call GetSegmentToWorld for the local
mech every frame, AFTER the local torso pushes its joint, so the cache was
already correct. A REPLICANT gets no such refresh: its cache stayed at the
BIND POSE, and the twist never reached the launch direction.
FIX. Use the engine accessor, and set the joints-dirty flag first so it
actually refreshes (by fire time the frame's render pass has already consumed
and cleared it -- measured jointsDirty=0 on BOTH nodes).
RESULT (same bench):
REPLICANT max 0.0000 -> 2.1145 mean 0.0000 -> 0.8252 0% -> 64%
PARTIAL, and I am not claiming otherwise. 36% of peer salvos still read the
exact-zero stale signature while the master is 100%. Forcing every per-joint
`jointModified` flag as well (GetSegmentToParent's own gate, SEGMENT.cpp:196)
was tried and moved the number by NOTHING -- 64% either way -- so the residual
is a different cause, most likely frame ORDER (the salvo mirror running before
the copy torso has posed that frame). Cheap form kept.
Also fixes a SAMPLING TRAP in the torso probe: PushTwist sampled one shared
static every 30th call, and with a master torso and a copy torso ticking 1:1
every 30th call is always the SAME instance -- so the probe showed only the
local untwisted torso and hid the copy's writes entirely. Now sampled per
instance-kind, which is what made the copy's correct joint writes visible and
moved the search downstream to the segment cache.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
|
||
|
|
546aabd5ba |
#131 false lock FIXED: miss-means-miss -- the pick answers only for drawn geometry
Night-12 field report (Ronin/Conn Man/Oracle, blackhawk-correlated): lock ring lit with the reticle visibly off the mech + no-reg complaints. Root cause: TWO port stand-ins answered where the 1995 card (which cast against the DRAWN geometry) would miss -- the pick's any-object sphere fallback and the caller's whole-mech AABB fallback. The regime that exposes them: a LEVEL boresight over a SHORT mech -- the blackhawk's mesh tops out below eye-ray height, so the ray clears every triangle but pierces the fat cull spheres; the ring lights with the reticle above the mech's head (the operator watched exactly this on the sweep bench). Careful aimed-down fire rides triangles, which is why Oracle's per-panel audit passed on the same build. Fix: MechSegmentPick returns 1=drawn-geometry hit / 0=TRUE MISS / -1=no render tree; the sphere may answer ONLY for a mesh the reader cannot parse (pm==0 -- currently none exist: counters objs/invFail/noTri all clean); the AABB survives ONLY as the pre-tree replicant grace. A readable mesh the ray misses is a MISS -- no lock. Verified (2-node vs bhk1 at 100u, all runs on force-relinked string- verified exes after today's stale-link flake): - LEVEL lock-sweep: 0 locks all run (pre-fix: lock band from 168 sphere answers; picksrc tri=0 sphereFB=168). - DOWN-PITCHED sweep: locks return 100%% tri-sourced (tri=158 sphereFB=0), landing on real parts (rarm/ldleg/rdleg) with honest gaps. - Full zone-walk matrix: tri=18874 sphereFB=0 box=0; victim took 156 hits across 16 zones incl. both side torsos -- combat un-regressed. New instruments (all env-gated): BT_LOCK_SWEEP=<axis> torso pan (the operator-visible lock-envelope bench), [locksweep] transition log, BT_LOCK_ENVELOPE synthetic unit-sweep probe, [picksrc]/[pickbox] source telemetry with objs/invFail/noTri localization counters. Bench: scratchpad/night12/zonewalk_bhk.sh. NOTE for the field: locking is now strictly TIGHTER (ring = reticle truly on the machine). If era testers feel the pods were more forgiving, Draco's "slight lock linger" memory becomes a deliberate investigation (sourced hysteresis), not an accidental sphere halo. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
1f995ee35a |
#124 twist-sign VERIFIED correct (live missile bench) + the rig to do it
The frame-adapter's inferred twist-sign flip (SelectSlice theta -= twist, vs the binary's += pre-reflection) was the last unverified half of #124 -- every earlier probe ran at twist 0. Bench: stationary madcat target with the torso PINNED at 0 / +140 / -140 deg, LRM salvos from a fixed shooter (missiles = the authentic cylinder path; the binary DROPPED zone -1 beam damage). Result: slice picks track the physically-facing flank in BOTH directions (twist-left -> right-family zones for left-flank impacts, twist-right -> left-family), deterministic, wrong-sign outcome (slice 7 vs observed slice 1) clearly excluded. No game-code change needed. Instrumentation added (all env-gated): - torso.cpp BT_FORCE_TWIST=<-1..1>: HOLD the sim's analogTwistAxis (the input-level pin was dead -- live input rides the CONTROLS.MAP device push, and Basic mode auto-centers; sim-level is plumbing-independent). - dmgtable.cpp [slice] line: rot flag, live twist, thetaIn/thetaAdj, chosen slice -- the weighted leaf roll made zone-only logs ambiguous. - [dmgresolve] now names the zone (BTMechZoneSegAndName). - mech4.cpp BT_FORCE_TWIST input pin + one-shot mode cycle (kept as doc of the dead path), mechmppr [mppr] mode probe. - scratchpad/night11/twistsign.sh: the 3-config bench. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
14ff3519ac |
#83: the COLLISION DIVERT -- type-0 damage prices as internal rattle, never armor
The crash self-damage reconstruction (
|
||
|
|
ef8e449a17 |
#55 steps 0/1/2/4: the 1995 DEATH pass restored, the arg gate made real, and 5 subsystems the respawn sweep never reached
THE HEADLINE: the port's death sweep was a total no-op, and fixing it required
fixing the arg gate in the same commit -- otherwise corpses refill their ammo.
STEP 2 -- the authentic dispatch shape:
* engine/MUNGA/SUBSYSTM.h: Subsystem::DeathShutdown gains the binary's
universal base body { DeathReset(c) } (@004ad10e). It was empty, and NO
port class overrode it, so everything the 1995 game does at death was
skipped entirely.
* mech4.cpp death sweep now passes 0, not 1 (the binary's @0049fe0c arg) --
the wreck shape: alarms/state settle, nothing refills.
* ARG PROPAGATION (mandatory once the sweep runs): AmmoBin::DeathReset is now
arg-gated exactly as @004bd26c -- refill only when arg != 0, ammoAlarm
unconditional. Ignoring the arg was harmless only while the sweep was
dead; with it restored, every corpse would have re-armed. Also forwarded
in PoweredSubsystem / HeatSink / Condenser / HeatableSubsystem / Generator
(each binary body forwards it -- verified addresses in the plan).
STEP 4 -- coverage for 5 classes that had an authentic slot-10 body but no
DeathReset, so the respawn sweep fell through to the empty base:
Torso (this is Gitea #70 -- "loosing torso twist function after a death"),
Gyroscope, Myomers, HUD, Seeker.
STEPS 0/1 -- observability + the David chain:
* Three unconditional matchlog rows: DEAD_NOTIFY (mech + resolved link),
PLAYER_LINK (player <-> vehicle), RESPAWN (mode/alive/zones/subsys/pos).
A respawn was previously INVISIBLE in the matchlog -- night 3's analysis
had to infer them from ammo arithmetic.
* Mech::PlayerLinkMessageHandler + the death dispatch site: when the engine's
one-shot registry lookup misses (no null check, no retry -> the whole
death/respawn cycle silently swallowed), recover the SAME object via the
reverse link the binary's own respawn branch walks (player+0x1FC ==
playerVehicle). Complete-type TU, no raw offsets.
* deathPending cleared in the first-spawn branch (a latch carried in would
permanently kill every later respawn -- the #57 class).
VERIFIED on the 2-pod rig (madcat vs thor, forced kills, 5 death/respawn cycles
per pod): build clean, ZERO new /FORCE unresolved externs from the 5 new
overrides; refill lines appear ONLY immediately before a Mech::Reset and NEVER
between a death and the next respawn (the corpse-refill regression this commit
had to pre-empt); all three probe rows present in both pods' matchlogs; every
DEAD_NOTIFY carried a non-null link.
DELIBERATELY DEFERRED (documented, not forgotten): the mechsub.cpp rename pair
(ResetToInitialState -> GenerateFault, ClearStatus -> the root reset @004ac22c),
deleting HeatableSubsystem::ResetToInitialState, and deleting RespawnRepair.
Those need the HeatableSubsystem vtable-slot-10 pre-flight the plan calls for,
and we have no binary image here to dump the vtable from -- guessing at it
risks the vptr-alias trap. Next session with the decomp shards open.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
|
a3329a64da |
#67 torso replication, part 1: the dead-reckoning clock fix + the bug REPRODUCED on the rig
THE CLOCK FIX (landed, verified live). The replicant torso's extrapolation
window was hardwired to ZERO: both shim accessors returned the same field
(torso.hpp, the "dormant in single-player" note). The engine maintains both
clocks exactly as the binary expects -- WriteUpdateRecord stamps
lastUpdate=lastPerformance on the master, ReadUpdateRecord stamps
lastUpdate=Now() on the replicant (SIMULATE.cpp:276/296, the 1995 "HACK"
comment intact) -- so the fix is one mapping: GetCreationTime (misnamed; now
GetLastUpdateTime) reads lastUpdate. ComputeTargetTwist's
`current - lastUpdate` window is real again. Why legs always replicated
while torsos did not: Mover is ENGINE code reading these fields natively; the
Torso is our reconstruction with the collapsed shim. Rig-verified: the
copy-side log now shows distinct lastUpd/now values.
THE FIELD BUG REPRODUCED (2-pod rig, thor vs thor -- thor because the first
attempt used FOGDAY's Black Hawk, whose torso is authentically FIXED like the
Owens: hEn=0, limits +/-0.01 deg):
[torso-copy] cur=-3.31613 target=-3.31613 atUpd=-3750
The replicant renders at EXACTLY its twist limit (thor: +/-3.31613 rad)
because twistAtUpdate holds garbage (-3750) and the limit clamp slams it to
the stop -- "twisted full right but was not using TT", on demand. An earlier
run poisoned it with 2.1e-44 (= int 15 as float, suspiciously the torso's
subsystem index).
NARROWED: the tx/rx probes added here (BT_TORSO_LOG prints every torso record
both directions, header + raw payload dwords) logged ZERO records in the
poisoned runs -- Torso::Read/WriteUpdateRecord never executed. The garbage
therefore arrives OUTSIDE the torso record path: a raw state write during
mech spawn/consolidation spraying the torso's fields (stream-walker framing
or a consolidation blit). That writer is part 2's hunt; the probes and the
deterministic repro make it a short one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
|
b85afed925 |
Torso-elevation aim LIVE: R/F now pitches the view + aim ray (pitch was inert)
User + tester reports: pitch does not work. Root cause: the Torso sim integrated the R/F / stick-Y axis into currentElevation (authored limits and rates all correct) but NOTHING consumed it -- eyepointRotation's only writer was the look-state switch, so neither the cockpit view nor the aim ray (camera basis) ever pitched. Shots always flew level; low targets (trucks) were unhittable. Fix (faithful: the pod's stick-Y pitches the EYE; the torso geometry does not tilt): per-frame compose in the HUD tick -- eyepointRotation = EulerAngles(lookPitch + torsoElevation, lookYaw, 0); BTCommitLookState now stores its look component in gBTLookPitch/Yaw; new complete-type bridge BTGetTorsoElevation (torso.cpp, mirrors BTGetTorsoTwist). DPLEyeRenderable consumes it every frame, so the view and the boresight aim pitch together (crosshair stays screen-centred). Sign PIXEL-CALIBRATED via new diag BT_FORCE_ELEV=<-1..1> (pins the axis headless): screenshots confirm axis +1 (key R) = aim UP, -1 (F) = down. X still recenters. Awaiting human verification. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
f4cf1e631a |
Spec cross-check vs the 1995 manual: reads CORRECT, numbers are 4.0-vs-4.10 drift
Audited our live streamed subsystem config against the manual's per-mech stat sheets (new BT_SPEC_LOG dump: torso speed/limits, heat-sink count, reservoir capacity, at subsystem ctor). RESULT: structure + semantics align perfectly; the tuning NUMBERS differ -- because the manual is Tesla 4.0 and our content is release 4.10. Point-release balance drift, NOT a reconstruction bug: - Owens + Blackhawk are the two fixed-torso mechs in BOTH (speed 0, limit ~0, torsoHorizontalEnabled=0); the other four twist-enabled -- our reads correctly identify every case - torso speed/limit + heat-sink count exist per-mech exactly as the manual documents; only the values were retuned 4.0->4.10 (e.g. torso speed MadCat 80->50, heat sinks Loki 38->15) - reservoir coolantCapacity reads a flat 20 = the coolant THERMAL capacity (game units), NOT the manual's per-mech 'liters' (a display/flavor quantity with no single subsystem field) -- different measures, not a bug CONCLUSION: do NOT retune content to the manual -- BTL4.RES is the authentic 4.10 shipping data; the 4.0 manual's numbers are an earlier pass. The manual CONFIRMS our structural fidelity. BT_SPEC_LOG retained for re-auditing. Follow-up (structural, less drift-prone): the per-mech coolant-loop weapon/generator assignments. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
21378ec132 |
Audio Phase 4b (AUDIO_FIDELITY F16): the torso-twist servo whir -- Torso
publishes its real attribute table Recovered the binary Torso attribute table [T1]: dense ids 3..15 from MechSubsystem::NextAttributeID (HeatWatcher/PowerWatcher publish nothing -- binary parity), all 13 rows land on already-reconstructed members: RotationOfTorsoVertical/Horizontal @0x1E4/0x1D8, HorizontalLimitRight/Left @0x1DC/0x1E0, SpeedOfTorsoVertical/Horizontal @0x1EC/0x1E8 (the |rate| the binary abs's -- our derive already did), StickPosition @0x1F0, TorsoUp/Down/ Left/Right/Center @0x1F8..0x208, MotionState @0x20C (statusFlags; the binary writes 2 on the limit-hit frame -- the authored ==2 matcher is the twist-stop clunk, settling the audit's [T4] guess). Torso's AttributeIndex was default-constructed EMPTY -- TorsoTwistInt01/ Ext01/Stop01 were unreachable. Now the authored chain (pitch -200..+200 cents over twist speed 0.5..0.9, start/stop gate at 0.25, stop clunk on MotionState==2) drives them unchanged. Regression (25s): stable; all three bind real; **attrnull count = 0 -- every authored audio attribute in the game now binds a real member.** Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
|
02cdfd6576 |
Torso: the TWIST goes LIVE -- electrical watchdog chain, centered crosshair, coherent controls (task #57/#58)
The MadCat torso twists, the view turns with it, and targeting follows. Three reconstruction fronts closed: THE ELECTRICAL WATCHDOG CHAIN (why the torso never powered up): - PowerWatcher::UpdateWatch reconstructed (@004b181c, the REAL registered Performance -- PTR @0050f5fc; Ghidra missed the fn start): the watchdog MIRRORS the watched subsystem's electrical level (+0x278), brownout downgrade when gen output <= minVoltage% x rated. @004b1804 relabeled ResetToInitialState (slot 10) -- the old "Simulation" tag was wrong. - The factory watcher-CONNECT pass reconstructed (vtable slot +0x38, @004aee2c/@004b1a40 byte-identical, recovered from raw exe bytes): watchedLink.Add(roster[watchedSubsystem]) on the master node. Was the SubProxy::Start() no-op -- every watchdog sat at 0 forever. - MinVoltageScale = 0.01 (a 10-byte x87 literal @0x4b1924; was 1.0f = permanent brownout) and PowerWatcher's Derivation chains its REAL base HeatWatcher (the HeatableSubsystem stand-in broke IsDerivedFrom for the whole Torso/Searchlight/ThermalSight family). - KB correction swept: derivation tag 0x50e604 = HEATWATCHER (not "HeatSink"); the btl4gaug heat-widget gate now tests it via the BTIsHeatWatcher bridge. THE CROSSHAIR (task #58 forensics, 6-agent workflow + live probes): - The VIEW is TORSO-MOUNTED: jointtorso -> jointeye -> siteeyepoint in every twist-capable .SKL; the camera + canopy ride the same hinge subtree through HingeRenderable's live matrix-stack compose -- ALREADY WORKING in the port. The crosshair stays screen-centered (center IS the boresight); the twist reads on the tape carets/compass/radar. - The real bug was the port's gBTAimX = tan(twist) slew (the falsified "body-mounted view" model): the camera already carried the twist, so the crosshair counter-slid to hull-forward and the fire ray with it. Deleted; the pick ray inherits the twist from the yawing eye basis. - Two instrumentation traps documented (chase-eye-as-default-camera, BT_FORCE_TORSO clobbering real joints -> the hook now only fills unresolved ones); an over-correcting explicit eye compose was added on those false readings and retired the same day. CONTROLS + REPLICATION: - Q/E spring-center on release (the axis is a twist-RATE demand; the old hold-deflection model drifted forever); X also zeroes the axis and pulses the authentic torso Recenter (@004b6918). M cycles control mode via the real CycleControlMode body. - Torso update-record DIRECTION fixed: engine truth is Write=serialize / Read=apply; @004b6a78 is the READ (was mislabeled Write) and the missing WRITE @004b6a1c recovered from raw disasm (recordLength 0x1C, twist/vel/rate at +0x10/14/18) -- kills the replicant's 0xCDCDCDCD -140-degree ghost twist. - Marching-ghost desync: 4 Standing-case guards zero stale reverse cycleSpeed (negative cadence passed the <= ZeroSpeed stop gate). - Kill credit rerouted to the OBSERVED killer (lastInflictingID -> killer's player link) -- kills count, target K/D populates. KB: subsystems.md (watcher chain), multiplayer.md (record direction), combat-damage.md + gauges-hud.md + cockpit-view.md (torso-mounted view re-correction), decomp-reference.md (new addresses + tag fix), open-questions.md (dead capability-roster loops 2-4, snapshot CD read). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
cb85517ede |
Gyro: byte-exact re-enable -- ctor map, integrators, jointeye writers (task #56)
The Gyroscope subsystem is LIVE again (was a stub since the NaN revert).
Reconstructed byte-exact from @004b3778 / @004b2ec0 / @004b30ec / @004b33e0 /
@004b34ec + the byte-verified dispatch in the unexported Mech performance
FUN_004a9b5c (calls @0x4aaf74/0x4aaf83):
- ctor field map corrected: springConstant@0x1E8 / dampingConstant@0x1F4 were
mislabelled (the old 'eyeOrientation = r->springConstant' poison line), the
0x254-0x2B3 block (externalPitchPtr, work matrix, placement) was missing so
everything after was mis-offset, and clamps/accumulators were 0xCD fill --
every field now initialised per the binary; 33 offsets static_assert-locked,
sizeof == 0x3D0 exact
- integrators: state-minus-target displacements, componentwise damping
OVERWRITE (FUN_004086d0 is a component multiply, not a cross), position step
without dt, clamp to [posSpring, negSpring]; IntegrateBody's X/Z-crossed
force + integration terms
- writers: WriteMechJoint drives ONE node ('jointeye', type 5): TRANSLATION =
eyePosition spring, ROTATION = bodyOrientation spring; WriteEyeJoint is a
multiplicative sway attenuator on 'jointlocal' (post-anim only)
- dispatch moved out of GyroscopeSimulation into the Mech performance tail
(GyroFrameJointWrite bridge, mech4.cpp) with the binary gates; gyro<->torso
pitch link wired (gyro+0x258 = &torso currentTwist) via complete-type-TU
bridges, retiring the SubProxy::linkTarget landmine
- Mech ctor: deathAnimationLatched/legResetLatch were never initialised --
0xCDCDCDCD gated the writers off silently
Runtime-verified: joints resolve (both BallTranslation), Performance installs,
WriteMechJoint finite from frame 0 (no NaN), Madcat cockpit un-regressed,
combat targeting healthy. Empirical: spring targets are SYMMETRIC -> eye
equilibrium (0,0,0), clamps +/-0.1-0.15u -- the gyro is the hit-BOUNCE
mechanism, not a steady eye offset (hypothesis disproven, recorded in KB).
Pending (task #56 tail): the damage->gyro fan-out FUN_004b2980 (unexported
gap) so hits actually kick the springs; the mech+0x3F0 overspeed sway model;
the torso-pitch EyepointRotation writer (FUN_004b66b4) + glance-look states.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
|
d07ac7dd49 |
STEP 6 COMPLETE: cylinder hit-location LIVE — unaimed hits resolve to zones
The Mech per-impact hit-location resolver (the cylinder damage table) is now functional, wired, and runtime-verified [T2]. Unaimed (zone==-1) hits — the collision-damage path — now resolve an impact point to a damage zone via the authentic height x angle grid + weighted dice roll, instead of dropping. dmgtable.cpp/.hpp was a non-functional skeleton on no-op ReconTable/stream shims; backed it with real std::vector storage and fixed 5 latent runtime bugs: - ReadEntries now consumes the leading cell name-string ([i32 len][len+1]) - PieSlice ctor reads rotateWithTorso into the correct member - SelectSlice direct-indexes (was int lookup on a float-keyed table) - ResolveHit returns the zone (chains SelectSlice -> SelectZone) - real MemoryStream::ReadBytes (was a variadic no-op) mech.cpp ctor: replaced the empty-name StandingAnimation stub with the real load — FindResourceDescription(dzRes->resourceName, type 0x1d) -> stream -> new DamageLookupTable, cached at mech[0x111]; ~Mech deletes it. Mech::TakeDamageMessageHandler override registered (MESSAGE_ENTRY overlays Entity's by ID): on invalidDamageZone, resolve via the table then base-route; aimed reticle hits pass through unchanged. Three named accessors (no databinding-trap raw reads): WorldToLocal (localToWorld.MultiplyByInverse), CylinderReferenceHeight (standingTemplateMaxY == collisionTemplate->maxY == binary mech+0x2ec[+0xc]), TorsoHeading via a BTGetTorsoTwist bridge in torso.cpp (Torso::CurrentTwist == torso+0x1d8; torso.hpp cannot be included into mech.cpp — subsystem-stub collision). Stream format + geometry + roll + handler were all byte-verified against the shipped BTL4.RES type-29 resources (18 tables, exact consumption) and the disassembly (FUN_0049eb54/e678/de14, glue 0x49ed0c, handler @0x4a037a). Runtime: boots clean, "[cyl] table 'bhk1' layers=7" (exact byte-verified layer count, found by name), mech spawns + walks, no asserts/AV/0xCDCDCDCD. Env gate BT_CYL_LOG=1. Unblocks collision-damage application. KB updated (combat-damage.md STEP 6 COMPLETE, open-questions.md marked done). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
|
7b7d465e5e |
Initial commit: bt411 -- standalone Windows BattleTech (Tesla 4.10 port)
Clean, self-contained extraction of the BattleTech-specific work from the
reverse-engineering workspace -- engine + game + content + build, with nothing
from Red Planet or the raw archive dumps. Builds green (Win32) and runs the
single-player drive->animate->target->fire->damage->destroy loop out of the box.
Layout:
engine/ MUNGA + MUNGA_L4 shared 2007 engine, carrying our BT render/loader
work (bgfload/L4D3D/L4VIDEO: BSL bit-slice decode, LOD/ground/shadow
models) + image codec; the minimal rp/ headers the audio HAL needs
game/ reconstructed BT logic + surviving-original BT source + fwd shims
+ WinMain launcher
content/ full runtime tree (BTL4.RES, VIDEO/, GAUGE/, AUDIO/, eggs, BTDPL.INI)
docs/ format specs + reconstruction ledgers
reference/ raw Ghidra pseudocode (recon source-of-truth) + decomp exporter
tools/ MP console emulator + map/resource scanners
One top-level CMake builds munga_engine lib + bt410_l4 game lib + btl4.exe.
All paths relativized (186 fwd shims + ~437 CMake abs paths -> repo-relative);
DXSDK is the one external, overridable via -DDXSDK. Verified: builds to a
byte-identical 2.27MB exe and runs combat (TARGET DESTROYED, 0 crashes) against
the bundled content.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|