2fb2f8a36d2adf0ca1c4413c62aac2e86d1d8ba5
217
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 arcattackandClaude Fable 5
|
ff5260ce98 |
Coolant-loop cross-check vs the 1995 manual: structure strongly faithful
Dumped each mech's subsystem->coolant-loop (BT_SPEC_LOG in mech4: walks the roster once, resolves each subsystem's linked-condenser number via BTCoolingLoopFrame) and diffed all 6 manual mechs' COOLANT LOOPS tables. RESULT -- the structure survives the 4.0->4.10 gap remarkably well: - BACKBONE identical on ALL 6: Generator A/B/C/D on loops 1/2/3/5, Sensors(our Avionics) on loop 2, Myomers on loop 5, LRMs on 1&3, autocannon on 4, big energy weapon on 6 -- exact match - weapon LOADOUT identical on 5 of 6 (Thor/Vulture/MadCat/Owens/ Blackhawk); Loki is the one full rework (4.0 PPCx2/AFC100/SRM6 -> 4.10 AFC50x2/ER Medium x2/SRM4) - the consistent 4.0->4.10 change is a small-laser REDISTRIBUTION: the 2 ER Small Lasers moved off the sensor/heavy loops onto the energy loops 4&6 (Thor/MadCat/Vulture); Owens near-perfect (loops 1&3 exact) - Loop 0 = correctly UNCOOLED infrastructure (condensers, reservoir, gyro, torso, HUD, ammo bins, ...) -- not a coolant loop CONCLUSION: the coolant-loop reconstruction is faithful; every diff is 4.0->4.10 balance tuning, not a bug. BT_SPEC_LOG retained. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
arcattackandClaude Fable 5
|
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> |
||
|
arcattackandClaude Fable 5
|
cb82d8c1d0 |
Turn/twist/free-aim sign family: negate ONCE at the key bridge (user-verified)
User live-tested: 'if i push the left arrow the mech turns right' -- correct, and it invalidated my earlier screenshot-forensics 'D=right verified' claim (the yaw telemetry actually agreed with the user all along: D gave POSITIVE yaw = CCW = LEFT; the sim uses math convention, positive = counter-clockwise, for turn AND twist). On the pod the RIO Ranger owned the hardware sign; the desktop bridge now negates in ONE place per channel family: - key_turn = -gBTDrive.turn (forced/BT_GOTO harness demands stay sim-frame, un-negated) - stickPosition.x = -gBTTwistAxis (Standard/Veteran torso stick) - SetFreeAimSlew call-site negations REMOVED (the bridge negation now flows through; double-flip removed) Matches the manual (p8): 'pulling your joystick to the right torso twists your Mech to the right.' User verified live: arrows steer correctly (Blackhawk, basic mode) and MadCat torso twist is correct in middle mode. LESSON (recorded): large-rotation screenshot comparisons are AMBIGUOUS (both directions put 'new scenery at an edge'); trust tracked landmarks, numeric telemetry with an established convention, or the user's live observation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
arcattackandClaude Fable 5
|
af80e62070 |
Fixed-torso free-aim left/right was reversed (tester report confirmed)
Field report: 'left/right is reversed'. Investigation with screenshot + numeric verification found it channel-specific: - A/D leg steering: CORRECT (D tap -> scenery slides left = turns right; verified via cockpit screenshots) - Torso TWIST (turning-torso mechs, e.g. MadCat): CORRECT all along (E -> currentTwist +0.27 = right -- consistent with weeks of validated play; an interim blanket negation that broke this is reverted) - Fixed-torso FREE-AIM slew (Blackhawk & friends): REVERSED -- E/right panned the view LEFT. The slew consumer pans opposite the twist convention; on the pod the RIO layer owned the hardware sign. Fix: negate stick_x ONLY at the two SetFreeAimSlew call sites (Standard + Veteran branches). Verified after fix: MadCat E -> currentTwist +0.270 (right); Blackhawk E -> view pans right. New BT_INPUT_LOG diags: [input] twist in/currentTwist (Standard branch) + mechYaw in the Basic elev line. Note for testers: the tester was almost certainly flying a fixed-torso mech -- 'reversed' reports should always record WHICH mech. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
arcattackandClaude Fable 5
|
1271d3bc76 |
Torso elevation (pitch aim) wired: the pod stick's Y axis lives
The mechs could always tilt their aim up/down -- Torso models the full vertical axis (currentElevation, rate, VerticalLimitTop/Bottom, recenter) and EVERY 1995 control mode routes stickPosition.y into Torso::SetAnalogElevationAxis -- but the desktop bridge hard-zeroed stick Y, so the axis was dead on a keyboard rig. The one pod control the remap left unwired. - btinput: JoystickY axis -> elevTarget/elevActive/elevAbsolute - mech4 shim: sElev integrator (same walk/spring model as the twist; X recenters pitch too via gBTElevRecenter) - mechmppr bridge: feeds stickPosition.y every bridged frame (the old unconditional zero removed); both mode branches covered - CONTROLS.MAP (+ numpad profile + compiled default): R/F = aim up/down, pad LeftStickY = elevation (was unused) - torso.hpp: CurrentElevation()/ElevationVelocity() accessors (diag) - [mppr] trace gains stickY (note: the trace reads AFTER the next frame's device push re-zeroes the stick -- input flows regardless) Verified live: R held -> torso elevation climbs at the authored rate and clamps at 0.349066 rad = exactly 20.0 deg (the Blackhawk's VerticalLimitTop); release holds the aim. The eyepoint correctly stays level -- pitch aims the GUNS and reads on the HUD's vertical elevation tape, as in the pod. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
arcattackandClaude Fable 5
|
4459262b9c |
Camera seat LIVE + Mech::PlayerLinkMessageHandler reconstructed (@0049f624)
The spectator/broadcast seat works end-to-end: a hostType=1 +
vehicle=camera pilot page boots a CameraShip whose 62-camera arena1
network loads from the BTL4.RES type-27 resource (the engine's
CreateStreamedCameraInstances existed all along -- the file probe falls
back to it), the BTCameraDirector locks onto the first live mech, and
the ship TRACKS it (sees=1, goal advancing) and CUTS between authored
camera positions (screenshot-verified: wide arena shot -> close
tracking shot).
The missing piece was the Mech override of PlayerLinkMessageHandler
(@0049f624), which the reconstruction never filled. The engine base
resolves mech->player; BT's override adds:
1. the REVERSE link player->playerVehicle = this on EVERY node
(replicants included) -- how the camera director and scoreboard
find a REMOTE player's mech; without it a spectator parks forever
('NO goal entity')
2. clears NonScoringPlayerFlag (0x4000 = bit 14): a pilot with a
vehicle is a SCORING player -- this admits REPLICATED players to
the ranking pass, so cross-node rank/score displays work
3. master only: seeds the heat bank's ambientTemperature (bank
@0x1d4) from the mission [mission] temperature= (BTMission+0xf4)
-- correcting the heat family's 'frozen 300' deviation note (it
was never frozen; THIS is the writer)
Bridge BTSetBankAmbientTemperature lives in heatfamily_reslice.cpp
(mech.cpp cannot include subsystem headers -- local-stub collision).
BT_CAM_LOG diagnostics: camera-network count, director pick + Players
group census, ship follow state, link dispatch/receive.
Verified live: 2-seat (mech + camera) relay session -- replicated
player shows +veh, director goal locked w/ 30s timer, ship tracking a
moving mech through camera cuts; standard 2-node mech smoke PASS
(un-regressed). Lesson re-learned: a 'clean' build filtered on 'error
C' missed a linker file-lock failure -- one whole test cycle ran
against a stale exe (the /FORCE gotcha's cousin; grep -i error, not
error C).
Remaining (task open): ranking-window overlay draw (L4VIDRND stubs),
operator-app camera-seat row, shot polish.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
arcattackandClaude Fable 5
|
17176058cc |
First 4-pod session VERIFIED + the EntityID-cast diagnostic trap
4 pods, relay-assigned seats, 4-pilot MP4.EGG (eggmodel-generated incl. callsign bitmaps): 4 distinct seats, full ladder, every node replicates all 3 foreign mechs (host-qualified [repl] sets are exact complements), 4 distinct spawn positions (no dropzone stacking), UDP at 4-pod fan-out (relay tx=3x rx, zero drops), all pods alive through the session. Per-host [net-rx] census symmetric: 36 NewDynamicEntity makes (mech + subsystem roster) from every host to every node. DIAGNOSTIC TRAP that cost a false bug-hunt: EntityID::operator int() returns localID ONLY, so the [repl] log's (long)GetEntityID() collapsed different hosts' mechs onto one number and read as 'missing replicants'. The log now streams the EntityID object (host:local via its operator<<). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
arcattackandClaude Fable 5
|
fad962bec8 |
Version stamping: 4.11.<git commit count> (<hash>[+])
4.10 = the 1995 arcade release; 4.11 = the win32 reconstruction; the
build number is the git commit count -- monotonic, zero-maintenance,
and every exe pins to exact source via the short hash ('+' = built
from an uncommitted tree). tools/btversion.cmake regenerates
build/btversion.h on every build (write-if-changed, no rebuild churn);
the stamp shows in the boot banner (btl4.log head, replacing the stale
'v4.10' line) and the window title (incl. the MP node tag).
Verified: build stamps 4.11.311 (980c9cd+), banner + title correct on
a live boot.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
arcattackandClaude Fable 5
|
980c9cd7e5 |
Input remap: CONTROLS.MAP binding engine + XInput gamepad support
The pod's controls reach the game through the RIO serial board; on a
desktop that hardware is a keyboard shim of hardcoded GetAsyncKeyState
reads. New binding engine (game/reconstructed/btinput.cpp) maps PC keys
and an XInput pad onto the authentic channels through a user-editable
file (content/CONTROLS.MAP, community-suggested grammar, corrected):
key/pad -> button <addr> real buttonGroup emissions, mirroring the
RIO convention exactly (press a+1 w/ mode
mask saved, release -a-1 w/ saved mask;
L4CTRL.cpp:2470-2520) -- aux/preset banks,
hotbox, panic, reverse thrust all reachable
key/pad -> axis Throttle rate (lever), pedals/JoystickX
deflect (turn/twist) into the existing
virtual-controls integrators (feel, gait
detent, spring-centering all unchanged)
keypad pilot|external <n> keyboardGroup key values ('0'-'F')
pckey <char> any authentic 1995 typed hotkey
action <name> port dev controls (view, all-stop, ...)
Keys claimed by a binding are SUPPRESSED from the legacy WM_CHAR/KEYUP
feed -- ends the historic double-dispatch ('w' drove AND selected pilot
0; F5's key-up value 0x74 aliased to the 't' hotkey; letter key-ups fed
the developer fake-event dispatcher). Unbound keys keep their authentic
meaning. The dual-use 'V' is split: V = view toggle, B = look behind.
Default profile = WASD classic (compiled-in twin; delete the file to
restore). CONTROLS_NUMPAD.MAP ships the corrected community layout
(keypads are NOT buttons 0x50-0x6F -- that space doesn't exist; no
clickable cockpit exists so everything needs a binding; keyboard fire
buttons added; 0x36/0x37 are hotbox not 'config'; missiles moved off
Ctrl). XInput loads dynamically (1_4 -> 9_1_0), disconnected-pad
probing rate-limited; pad sticks write the axes as absolute positions
(the spring is physical), triggers/buttons per the file.
Verified live: bindings load (43), W and NumPad8 drive (speedDemand 0 ->
61.5), X all-stop (spd -> 0), aux-bank emission (D1 -> [input] 0x2f
PRESS/release under the numpad profile), suppression both directions
(posted 'r' reaches [keych], posted 'w' swallowed), full-keyspace
WM_CHAR+WM_KEYUP fuzz x3 survived with sim advancing, XInput graceful
with no pad, 2-node relay session un-regressed (full ladder + UDP).
Pad-in-hand testing still needs a physical controller.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
arcattackandClaude Opus 4.8
|
e2c21c4db2 |
Fix the tester 'buttons crash the game' report: two keyboard killers
Reproduced by full-keyboard fuzz (every WM_CHAR + WM_KEYUP posted to the game window, per-key liveness; delivery proven by the new BT_KEY_LOG [keych] trace). Two distinct issues: 1) '&' == Shift+7 is the engine's dev-console STOP-MISSION keystroke -- one shifted-key slip while hunting unmapped panel keys (MAP zoom '+' is Shift+'=') instantly ended the session, indistinguishable from a crash. Now env-gated (APP.cpp): default ignored with a log line; BT_KEY_STOP=1 restores the authentic stop (verified both ways live). Same hazard class as the arrow-release '&' alias already swallowed in L4CTRL.cpp:1516. 2) '\' (the developer fake-event key) was a REAL wild-jump crash: Entity::Dispatch STAMPS entityID/interestZoneID into the message at Entity::Message offsets (ENTITY.cpp:236), and the '\' case dispatched a bare Receiver-sized ReceiverDataMessageOf<ControlsButton> at the Mech -- the stamp wrote past the stack object and corrupted the frame (cdb: call to eip=1 out of Receiver::Receive). The 1995 binary does the identical overwrite and survived on stack-layout luck. Fixed with Entity::Message-sized placement-new backing (btl4mppr.cpp); the only such call site (grep-verified). Verified: full fuzz (95 chars + F-keys + letter/digit keyups, 118 keys delivered) survives end-to-end; '&' stops cleanly under BT_KEY_STOP=1. KB: reconstruction-gotchas.md gains gotcha 19 (Entity::Dispatch message stamping) + the '&' note. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
1ed8b05160 |
Radar view-wedge tracks the torso twist (Gitea issue #1)
The SECTOR radar's view cone read viewHorizontalRotation, wired by the MapDisplay ctor from the mech's Torso -- but FindSubObject and GetHorizontalRotation were NULL stubs, so the connection was never created and the wedge sat at heading 0 regardless of twist. Reconstructed from the binary: - FindSubObject (FUN_0041f98c): a subsystem-ROSTER walk (count @+0x124, array @+0x128) matching the streamed subsystem name (sub+0xd4) with a tolower-strcmp (FUN_004d4b58) -- the 'Torso' sub-object IS the roster Torso subsystem. - GetHorizontalRotation: torso+0x1D8 == Torso::currentTwist (layout-locked), via the existing task-#56 bridge BTGetTorsoTwistAddr (Radian is layout- identical to Scalar). Verified live (MadCat, Standard mode Q/E): the wedge tracks the twist in lockstep (rot 0 -> -2.21 rad), and the semantic test passes -- body turned away, torso twisted back onto the enemy: reticle green + wedge pointing at the enemy's blip on the body-fixed scope. NB the Blackhawk's torso is FIXED (+/-0.01 deg limits) -- its wedge authentically never moves; test with a twisting mech. Diag env: BT_RADAR_LOG. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
63250aee41 |
Fix two Jul-16 regressions: BT_DEV_GAUGES crash + -net dead controls mapper
Both surfaced today (dormant ~1 day) the moment the pod launch flags
(BT_DEV_GAUGES=1 BT_START_INSIDE=1, tools/mp_launch.sh) were used to drive in
multiplayer -- which made the same-day paint change look guilty. Confirmed on
the pre-paint build too; the trigger was the Jul-16 audio attribute work.
1) BT_DEV_GAUGES crash (cdb: CoolingLoopConnection::Update, ~15s in as the gauge
builds lazily). The dev-gauge cooling-loop lamp reached the cooling master by
RAW attribute index -- GetAttributePointer(3) + *(master+0x1d4). The audio
commits (
|
||
|
arcattackandClaude Fable 5
|
e0474ff92a |
Per-pilot mech paint: wire the color/badge/patch substitution end-to-end
- Mech::resourceNameA/B/C -> real CString members (the binary's 16-byte CStringRepresentation; deep-copy bind from the MakeMessage = FUN_00402a98, implicit member dtors) + paint-name accessors - SetupMaterialSubstitutionList reads the real egg names ([paint] log); TearDown clears the callback first (FUN_004d11e8) - dpl_SetMaterialNameCallback is real now (L4VIDEO registry); bgfload MaterialResolver::resolve() applies it to every material name -- the port analogue of the dpl board rewriting names at load - MP_BHMC.EGG: color=Red -> Crimson (vehicletable has no Red; binary Fail()ed) Verified live 2-node MP: crimson MadCat with hip hazard stripes + yellow VGL leg emblems; white Blackhawk + emblems; replicants painted on both nodes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
ebdfa40d95 |
HUD (task #68 follow-up): authentic reticle pip GROUPS -- front vs rear
The binary reticle registration resolves each weapon's RearFiring attribute and registers its pip in group 1 (front) or 2 (rear) (part_014.c:5429-5434) [T1]; the reticle draws the group selected by the mech's reticleElementMask low bits (= binary mech+0x390, driven by the weapon-update view switch part_013.c:5588-5595: forward |1&~2, look-back |2&~1). Port: BTBuildReticle passes the real group (was hardcoded 1 on the disproven "no BLH weapon is rear" belief); BTCommitLookState drives the mech's reticleElementMask low bits per view (mech4's HUD tick already publishes them as gBTHudGroupMask, and the reticle Draw already filters on it). Resolves the user-reported "only 2 ERM dots but the mech has 3": ERMLaser_1 (front) and ERMLaser_2 (rear) both author pip position 1 -- with every pip drawn in one group the two red dots sat exactly on top of each other. Now: forward view = 5 pips (2 PPC + ERM_1 + 2 SRM), look-back = the 2 rear lasers' own group layout. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
38febae36b |
Rear-fire + look views (task #68): the pod's rear arsenal reconstructed
The user's tip ("some mechs actually do fire backward") checks out end to
end. Binary ground truth [T1]:
- weapon+0x334 (attr 0x1B "RearFiring"): the ctor tests the MOUNT SEGMENT's
page name for the marker 'b' (@0x511aa2, part_013.c:6913-6930) -- the back
gun ports sitelbgunport/siterbgunport. The old reading ("EXT in the
weapon model name") was a double misread (wrong string, wrong name).
- mech+0x410 (attr id 50 "RearFiring"; the old `stateFlags` label): the ctor
ORs every weapon's flag (part_012.c:10220) -- "carries a rear arsenal".
- The mapper's five-state LOOK machine (part_013.c:396-459): on a state
change it re-aims the eyepoint (mech+0x360 = EyepointRotation -- consumed
by DPLEyeRenderable, already live in the port) and re-arms each weapon's
viewFireEnable(+0x3E0): FORWARD view = the non-rear weapons, LOOK-BACK
(yaw pi + lookBackAngle pitch) = the REAR-mounted ones, side/down = none.
+0x3E0 is the same flag the emitter's Loaded->Firing gate reads (the old
`useConfiguredPip` label) -- pips and fire permission both follow the view.
Port: rearFiring derived from the mount segment name (BTWeaponMountIsRear);
mech rearFiring ORed in the roster pass (the old SubProxy::IsDerivedFrom
stub returned 0 -- that loop never ran; now bridged through
BTWeaponIsRearFiring, which also fixes the weaponRoster fill); the look
commit is LIVE (BTCommitLookState: eyepoint EulerAngles from the authored
per-mech look angles -- now real members, were Wword scratch parks -- +
per-weapon view enables); MissileLauncher/ProjectileWeapon FireWeapon gate
on viewFireEnable like the emitter; RearFiring attrs (mech + weapon) bind
real members. Keyboard: HOLD 'V' = the pod's rear-view button.
Live-verified on the default blackhawk: ERMLaser_2 -> siterbgunport rear=1,
ERMLaser_3 -> sitelbgunport rear=1, PPCs/SRMs/torso mounts forward -- the
blackhawk authors TWO REAR LASERS (owens also has back ports). [rearfire]
trace under BT_PROJ_LOG.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
arcattackandClaude Opus 4.8
|
ab6ea83e3b |
Missiles (task #67): launch through the WEAPON MOUNT frame -- the
backward-firing rack User report (madcat): missiles sometimes leave the mech BACKWARD; lasers always fine. Root cause: only missiles fly the authored MuzzleVelocity vector, and BTPushProjectile rotated it through the mech BODY basis (localToWorld) -- but the madcat's racks ride the TORSO. The muzzle POINT was segment-resolved (tracked the twist) while the launch DIRECTION followed the LEGS: twist the torso far enough and rounds left the back. Lasers/ACs aim straight at the designated pick (no launch vector) -- unaffected, exactly as observed. Binary ground truth [T1]: the fire builder FUN_004bcc60 spawns the missile with the FULL muzzle-segment frame (the real GetMuzzlePoint fills an AffineMatrix into the descriptor, :8762-8764), composes the authored MV with the z-NEGATION (:8759-8761 -- confirming the 2026-07-12 telemetry finding) onto the mech's own localVelocity (FUN_004b9cbc = owner+0x1c4), and the dumb seeker re-aims 100u ahead of the MISSILE's own frame each frame (0x4be9a0 disasm) -- the mount orientation IS the launch direction. Port: BTPushProjectile takes muzzle_seg and rotates the launch vector through the mount segment's world frame (segment-to-entity x localToWorld, the same matrix the muzzle point already used), keeping the z-negation convention, and inherits the shooter's world velocity; body-basis fallback for callers without a segment. All four call sites pass GetSegmentIndex(). Bonus decode banked for the full Missile-entity revival (KB-worthy): the three authentic performances -- Seeker 0x4be9a0 (aim = target-frame offset / 100u-ahead dumb + loft/lead 0x4beae4), Thruster 0x4be474 (quaternion-slerp BODY TURN toward the aim at turnRate deg/s), MoveAndCollide 0x4bef78 (velocity aerodynamically aligned to thrust via signed-square per-axis gains, ballistic droop as fuel burns, PROXIMITY FUSE on seeker rangeToTarget, max-range + altitude-floor retire). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
c51d64a6b8 |
Gyro tail + audio (task #66): the INSTABILITY MODEL -- mech+0x3F0 reconstructed
Byte-decoded the un-exported master-perf block @0x4aad3d-0x4aaf14 (capstone;
the same gap that held the F5 footstep code) [T1]:
instab = (min(|AccelerationLastFrame| / maxUnstableAcceleration, 1)
x unstableAccelerationEffect)^2
instab += clamp((demand - legCycleSpeed)/demand, <=1) # "gun the engine"
x unstableGunTheEngineEffect # (demand clamped to
# [gimpStride(neg), runMax2])
if (legAnimationState == 4 /*turn-in-place*/) instab += unstableStopedTurnEffect
clamp to 1 -> mech+0x3F0 -> gyro->swayBias (gyro+0x3A8)
Every piece resolves to already-reconstructed structure: the model-record
tuning block rec+0x80..0x94 (ctor copy @0x4a2593 -- the six authored
Unstable* fields, previously parked in the Wword scratch bank, now real
members); AccelerationLastFrame@0x82c = the snapshot of the ring-derived
localAcceleration (copied at the perf tail @0x4ab142); CurrentSpeed@0x348 =
legCycleSpeed; the trn state 4 gate; and the gyro feed lands in the
EXISTING swayBias member + GyroscopeSimulation consumer (task #56) --
GyroFrameJointWrite's "0.0f model TBD" argument is now the live value.
UnstablePercentage (binary id 52 @0x3F0) binds the real member: the LAST
dead audio attribute is live -- the authored instability alarm (start
thresh 0.01 + volume = the fraction) sounds under hard maneuvers, and the
cockpit ambient sway now scales with reckless driving.
Live verification (30s, 0.6-throttle run): instab 0.38 during the walk->run
chase (cyc 22.2 vs demand 33.6), settling to 0.002-0.12 per-stride ripple at
steady run; attribute binds with live float values; [instab] trace under
BT_GYRO_TRACE. unstableSuperStopEffect/unstableHighVelocityEffect writers
remain unlocated (plausibly the airborne perf variant) -- noted on members.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
arcattackandClaude Opus 4.8
|
a11a697824 |
Audio: footsteps arrive on the FIRST stride -- the 10-20 s warm-up bug
User report: footfalls silent for the first 10-20 s of every mission (all
mechs), then solid. Root cause was three interlocking layers, each measured
with timestamped traces:
1. The authored footstep volume chain (LocalAcceleration [0,10]->ctl100 +
LocalVelocity [0,0.6]->ctl101 through authored N=30/N=15
AudioControlSmoothers, fill 0) hangs off the SOURCE's watcher chain
(scale watches smoother watches mixer watches source), and an idle
source's chain executes only at Start attempts -- one smoother sample
per stride.
2. Each hop is frame-gated (AudioComponent::ExecuteWatchers,
DefaultAudioFrameDelay), so any burst collapses to one execution.
3. The transient drop gate (vol < 0.3, AUDREND) rejected every Start while
the smoother average crawled up 1/30th per attempt -> ~25 dropped strides
before the first audible step, then per-frame execution while playing
kept it warm forever ("solid after that").
Fixes (engine-level, each documented in place):
- AudioScaleOf<T>::Execute now sends EVERY poll (scales are continuous
value-feeders; the base bitwise change-gate -- Motion::operator== is
memcmp -- froze on our deterministic gait math, where the original's
noisy physics floats never bit-repeated. Triggers/matchers keep the
change gate: their semantics are edge-based).
- Component/AudioComponent::PrimeWatchers(passes): recursive, GATE-FREE
watcher pump; AUDREND runs 30 passes on every transient Start request so
the authored smoothers evaluate at their true steady state before the
drop gate reads the volume.
- localAcceleration derives via the binary's exact structure: 15-sample
ring buffers of the raw position derivative + dt (ctor part_012.c:9836,
derive :15169-15195), in the PerformAndWatch tail so it runs every frame.
- AttributeWatcherOf::GrabCurrentValue private -> protected (the scale
override calls it).
Verified (30 s walk from cold start): drops 25 -> 3 (the survivors are
authentic quiet-stride gating: first gentle strides at vol ~0.28 vs the 0.3
gate), footfalls deliver from the first stride, 43 delivered with live
per-stride gain variation. Diag traces added: [accwatch]/[fsscale]/
[smooth]/[smoothcfg]/[motionscalecfg] + timestamps on DROP/volset.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
arcattackandClaude Opus 4.8
|
0e2401fb52 |
Audio Phase 4d (AUDIO_FIDELITY F5): footStep is the authored CONTACT LEVEL
The binary's per-frame perf (disasm @0x4a9e80-0x4a9eb6 leg / @0x4aba86- 0x4abab9 body) computes footStep@0x394 = (jointlocal.y <= *footStepThreshold) with the threshold pointer = SequenceController+0x20 = &ANI hdr[2] -- the header word the engine's own AnimationInstance captures (JMOVER.cpp:1415) and our SelectSequence skipped. States 0/1 retain the value. Port: SelectSequence captures hdr[2]; PerformAndWatch evaluates the contact level per frame from the cached jointlocal root joint (leg channel drives the pose); the 150 ms clip-transition pulse + decay are RETIRED (steps fired at clip boundaries with a fixed width; clips whose root crosses twice or never counted wrong). Live verification (30s walk): the authored threshold decodes real (-0.232 root height); rootY oscillates across it per stride (-0.26 contact / -0.19 swing) with clean 0->1->0 transitions per leg state (5/6/7); 34 footfall deliveries at stride rate with per-stride varying gains. Also closes F23(2): the 17 authored AnimationState trigger states fire empirically -- the EngineShiftFwd/Rev heard during the gait dead-band hunt WERE states 10/11/14/15; the runtime clip numbering is correct. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
9dcb4752de |
Audio Phase 4c (AUDIO_FIDELITY F17/F19): impact scaling + the authored footstep feed
F17 CollisionSpeed (binary id 24 @0x4B4): real member captured as |worldLinearVelocity| when the contact accumulator arms (0->1) -- the authored AttackVolume [0.9,1] / Brightness [0.7,1] scales over impact speed [0,25] now make harder hits sound louder and brighter. ReduceButton (id 46 @0x340): real watchable member (the keyboard rig never presses it). UnstablePercentage stays deferred: its sway/overspeed model @0x3F0 is the known gyro-ledger gap (live writer unexported); binding without the model would be a stand-in. F19 footstep feed (the invention is dead, long live the authored chain): new [motionscalecfg/motiontrigcfg] traces recovered the authored configs -- EVERY motion watcher extracts |linearMotion| (motionValue=3); the footstep volume mixer is fed by LocalAcceleration [0,10] -> ctl100 (per-stride kick) + LocalVelocity [0,0.6] -> ctl101 (0.4 base while moving). The port never wrote Mover::localAcceleration, so ctl100 read 0 and the old mech2.cpp step-intensity broadcast (patch-sniffing, invented curve) fought the live authored scale. Now: localAcceleration.linear = d(published velocity)/dt -- EXACTLY the binary's derivation ((avgVel - prev)/avgDt into +0x1e4, part_012.c:15186-15195) -- and the broadcast is REMOVED. Regression (30s, walk throttle): stable; footfalls deliver through the wholly-authored chain with per-stride VARYING gains (0.61/0.72/0.62 -- real step dynamics, impossible under the old constant-curve invention). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
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> |
||
|
arcattackandClaude Opus 4.8
|
cc2b109cc8 |
Audio Phase 4a (AUDIO_FIDELITY F6/F7): coolant-leak warning + missile alarm
F6 ReportLeak (the largest dead authored block -- 38 of 54 match watchers):
recovered the binary HeatSink attribute table (16-byte {id,name,off+1} rows
@0x50e438..0x50e4c8, ids 3..12) [T1] -- it confirms EVERY existing heat
binding (CurrentTemperature@0x114 .. CoolantMassLeakRate@0x130, HeatSink@
0x164) and adds the one row we never published: ReportLeak (id 12) ->
+0x138 = coolantActive, the INT leak hysteresis flag UpdateCoolant
(@004adbf8) drives 1/0 around draw 0.003/0.0025. PoweredSubsystem derives
from HeatSink, so the single row serves all 19 authored leak watchers
through the chained index, exactly like the binary. MechWeapon's pinned-id
pad absorbed the +1 chain shift (0x0E -> 0x0F, tripwire fired as designed).
F7 IncomingLock/DistanceToMissile (missile alarm): binary Mech table walked
in full (ids 21..56 [T1] -- also settles FootStep@0x394, CollisionSpeed@
0x4B4, UnstablePercentage@0x3F0, ReduceButton@0x340 for the next findings).
IncomingLock id 54 @0x3fc, DistanceToMissile id 56 @0x400; the old
"maxSpeed @0x400 = FLT_MAX" member was a MISREAD of the far default and is
retired (its 1000.0f "override" was RadarRange id 47 @0x404, already
published). Real members + accumulators: Missile::MoveAndCollide reports
target + range each tick (BTReportIncomingMissile bridge); PerformAndWatch
latches per frame. The authored beeper (match 1/0) + range->TEMPO scale
(100..800 -> 600..10, accelerating as the missile closes) read them
unchanged. Drive is intent-level [T3]; init 0/FLT_MAX matches the binary
reset (part_012.c:9446-9447).
Regression (30s): stable; ReportLeak binds real on every subsystem (0 pad
redirects); DistanceToMissile binds with FLT_MAX live; attrnull 41 -> 3.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
arcattackandClaude Opus 4.8
|
aa004eb7b8 |
Gait: keyboard detent snaps the lever out of the walk/run DEAD BAND + KB
Byte-decoded finding [T1]: the gait SM has no stable state for a demand in
(walkStrideLength@0x534, reverseSpeedMax@0x538). Cap semantics settled from
LoadLocomotionClips @0x4a80d4: 0x538 is the walk->run TRANSITION CLIP's exit
speed (the run ENGAGE threshold -- not a reverse max) and 0x34c (run-cycle avg
root speed) is the mapper's continuous demand multiplier (FUN_004afd10). The
finished-callbacks up-shift when tgt > 0x534 but enter/sustain run only when
tgt >= 0x538, so a demand parked between them (Blackhawk: 22.02-30.87 =
throttle 36-50%) hunts walk -> shift-up -> shift-down forever, firing the
authored EngineShiftFwd/Rev sounds each swing -- the user's repro, faithfully
reproduced by all-authentic logic + data. Likely masked on the pod by
MECHANICAL throttle-quadrant detents ("5 speeds" lore; the software path is
notch-free) [T4] -- added to get-from-Nick.
Accommodation (keyboard = our stand-in lever): at key REST, snap the lever to
the nearer dead-band edge (walk cap, or run engage + margin since the cont
check is >=). Sweeping THROUGH the band while held stays continuous -- an
authentic moving lever; the single shift it fires is the authentic shift.
BT_GAIT_TRACE logs [gaitdetent] snaps.
KB: locomotion.md gait-dead-band section, pod-hardware.md mechanical-notch
hypothesis, open-questions.md Nick item.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
arcattackandClaude Opus 4.8
|
537749cae3 |
KB: audio fidelity Phase 1+2 settled facts -> context/wintesla-port.md
wPreset patch numbering, SF2 v1.0 pitch generators + EMU8000 44100 base rate + the WAV bake formula, inverted SBK attenuation, full-zone/key-select/loop- region/release-fade architecture, distance/gain/doppler model, the audio-clock origin (FUN_0044e19c = ApplicationManager::GetFrameRate; frames were clock ticks), and the ConfigureActivePress base-attribute resolution. Annotated the mech4.cpp velocity smoothing as AUTHENTIC [T1] (binary Mech::Execute AverageOf filters, part_012.c:15169-15179). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
691e88569a |
Audio Phase 2 (AUDIO_FIDELITY F1/F2/F13/F14): full-zone soundbank -- key-splits,
layers, baked tuning, loop regions, release fades Extractor rewrite (tools/sf2extract.py): every sample-bearing instrument zone becomes a SAMPLEINFO slot -- 603 zones / 241 presets (68/115 + 94/126 multi- zone, matching the audit exactly). Per zone: keyRange(43), sampleModes(54), SBK samplePitch(55) + rootKey(58) + coarse/fineTune(51/52), attenuation(48, INVERTED SBK scale, 0.375 dB/step [T3], baked into the PCM), releaseVolEnv(38), pan(17), shdr loop region. F2 pitch (algebraically exact): WAV rate = round(44100 * 2^(((6000 - rootCents) + tune)/1200)) -- EMU8000 v1 base 44100. Cross-checks: FootFall 17300 Hz (the audit's +4.2 st), MissileLoaded low zone 88200 (-24 st), Warnings01 8-way klaxon split w/ 3 looped zones, Death01 162 Hz extremes. F1 zone selection: SetupPatch/PlayNote take the authored note; attach/play only zones whose [keyLo,keyHi] contains it (detach the rest so a rewound source can't replay a stale buffer). Live-verified: LaserLoaded/ MissileLoaded note 36 -> low clunk zone, note 84 -> high blip zone (pitch 4); LaserCFire plays all 3 authored layers incl the looping sustain. Stereo-pair zones pan via listener-relative AL_POSITION (distance model is AL_NONE). MAX_PRESET_SAMPLES=25 (AllExplosion); fixed PRESET_isImplemented's >=5 bound. F13 loops + releases: authored [loopStart,loopEnd] applied via AL_SOFT_loop_points at buffer load (0 rejections; kills the latent boom-loop on MechExplosion's 1.5% sustain slice + the ~2.4 Hz LaserBSustain wrap tick); StopNote now honors the authored releaseVolEnv (1.1-3.9 s on ~20 looping presets) with a dB-linear fade serviced from AudioHead::Execute; restarts reclaim fading sources. One-shots keep the instant stop (faithful). Regression (40s drive+fire): stable, loop points accepted, key-splits + layers verified in the delivery trace, chirp still dead, footfalls fire. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
fc7f311771 |
Audio Phase 1 (AUDIO_FIDELITY F3/F4/F10/F15/F18/F20 + KB): the quick wins
F3 distance: alDistanceModel(AL_NONE); restored the commented authored distance multiply in Dynamic3D::CalculateSourceVolumeScale, added the same override to Static3D, dropped the (now inert) AL_MAX_DISTANCE writes. Far battle audio follows the authored knee/rolloff curve again, and the volume cull / voice steal / ducking chains are distance-aware. F4 volume law: AL_GAIN = volume_scale^2 at all 3 per-frame sites (Direct/ Dyn3D/Static3D) -- the GM CC7 squared curve; linear was ~+6 dB at mids. F10 doppler: alDopplerFactor(0) (AL's model ran wrong constants + sign- inverted velocity: approaching sources pitched DOWN); the AUTHORED dopplerCents (AUDIO.INI range/speed-of-sound model, decomp-proven consumer part_008.c:7466) now adds into the Dynamic3D pitch chain. F15 ConfigureActivePress: published at the MechSubsystem BASE (binary id 2, descriptor @0x50de5c -> +0x110); renamed the misnamed vitalSubsystemIndex member (the weapon ConfigureMappables handler already drives it 0/-1). Removed the invented Sensor/Myomers duplicates and RESTORED their byte- exact layouts (0x328/0x358 allocs + asserts). MechWeapon's pinned-id pad absorbed the +1 chain shift -- which matches the binary's own numbering. F18 cook-off warning: AmmoBin FireCountdownStarted -> the existing cookOffArmed @0x18C (binary table @0x512600); the countdown klaxon can fire. F20 zoom blip: L4MechControlsMapper publishes TargetRangeExponent -> the live @0x1a4 zoom member (own table chained to MechControlsMapper). KB: replaced the bogus divisionParameters+0x10 rate read with SystemClock::GetTicksPerSecond() (FUN_0044e19c is GetFrameRate -- original audio frames were CLOCK TICKS). Regression (35s drive+fire): stable; ConfigureActivePress binds real on all 9 subsystems (idle -1, zero pad redirects); FireCountdownStarted + TargetRangeExponent bind live members; attrnull 53 -> 41; chirp still dead; footfalls still fire (gain now correctly squared). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
c68307ad53 |
Audio: kill the per-footfall static -- smooth the PUBLISHED velocity (task #50)
User pinpointed it: the per-stride 'static' was NOT the footstep sample -- it was the ambient engine hum being interrupted in time with the footfalls. Diagnosis (live tape): EnginePower01 was caught in a rapid Play->Stop cycle (80x/session). The idle-hum is gated by authored LocalVelocity triggers (hum ON in speed [1,20], OFF above 20) -- and the port's localVelocity is a RAW per-frame position derivative that pulses with every stride (gait acceleration + ground-snap bob). At walking speed |v| straddles the 20 band edge, so the trigger Start/Stop-flapped the hum on every foot plant; at run |v| >> 20 keeps it off (matching 'goes away at higher speeds'). Fix: ~0.25s exponential filter on the PUBLISHED localVelocity.linearMotion (fwd + vertical) -- kills the stride ripple, tracks real speed changes within a couple strides. The physics worldLinearVelocity (StaticBounce, collision damage pricing) is untouched; update records + the impact gate get the smoother value (both benefit). VERIFIED: EnginePower 1 play / 0 stops for the whole run (was 80 stop-cycles); FootFall cycles normally per stride; gear shifts/windup lifecycle intact. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
be626c71ce |
Audio: KILL THE CHIRP -- ConfigureActivePress backed real (idle -1) on Sensor+Myomers (task #50)
The obnoxious always-on clicking was the cockpit CONFIGURE-MODE ticker: an
authored looped sequence gated by an AudioIntegerTrigger with threshold -1 on
<subsystem>.ConfigureActivePress (the held-configure-button index; -1 = none).
The attribute was one of the inert-pad redirects -- the pad reads 0 = "button 0
held forever" -> the ticker Start-fired at load and pulsed 2.7/s eternally.
Found via [sendcfg]/[seqstart] traces: the first seq start immediately follows
the trigcfg(thresh=-1, onID=Start) construction on the pad address.
Fix: real int configureActivePress = -1 APPENDED to Sensor ("Avionics") and
Myomers, registered in their attribute tables. Both classes are byte-exact
factory allocs, so the sizeof locks AND the placement-new alloc constants are
bumped TOGETHER (Sensor 0x328->0x32C, Myomers 0x358->0x35C) -- the tripwire
caught a mid-layout insert (seekVoltage@0x330 shift) and a fixed-alloc overrun
before they shipped; member moved to the true tail. Wiring the live value
(EnterConfiguration/ExitConfiguration sets/clears the index) restores the
authored hold-to-configure tick later; idle -1 is the correct silent state.
VERIFIED: ProgramButton01 plays ZERO times (was the 2.7/s chirp);
ConfigureActivePress binds real (vtbl=FFFFFFFF = the -1); FootFallInt at 0.98
gain; stable.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
arcattackandClaude Opus 4.8
|
847b9b85cd |
Audio: target the step-intensity send at FOOTSTEP sources only (task #50)
The output-filtered broadcast still fed EVERY volume/brightness mixer -- the
always-on ambience pulse's own volume mixer got cranked to step intensity on
every stride ('a stuck button', 3/s, loud). The send now identifies footstep
sources by authored patch (FootFallInt/Ext: bank2 37-39, bank1 106/107) through
mixer->GetTargetComponent() -> AudioSource -> PatchResource LOD bank/patch
(new accessors: GetTargetComponent, GetBankID/GetPatchID,
AudioResource::PeekAudioLevelOfDetail).
Also: step intensity curve raised (speed/25, floor 0.55 -- a mech stomp is
never subtle; it was firing at ~0.4 gain and masked under 0.9-gain layers,
heard as an unrecognizable 'orchestral hit').
Verified: FootFallInt at 0.78 gain in the live tape; the ambience pulse back
to its brief authored form (absent from 1/s snapshots).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
arcattackandClaude Opus 4.8
|
e454e97617 |
Audio: fix step-broadcast misfire -- feed ONLY volume/brightness mix stages (task #50)
The blind foot-plant broadcast hit every entity-registered component; mixers whose authored OUTPUT control is Start forwarded the send as a Start and fired their sound on every stride (the per-step ProgramButton 'chirp'). Added GetOutputControlID() to AudioControlMixer/Multiplier and the broadcast now feeds only stages outputting Volume(3)/Brightness(5) -- the footstep loudness inputs -- directly (mixers are entity-registered, no splitter hop needed). Verified: FootFallInt01 delivers on BOTH gaits now (11/run, walk input included); ProgramButton deliveries 188 -> 38 (the remainder are authored looped-sequence cockpit ambience, not the broadcast); stable 28s drive+fire. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
90f99fe4b5 |
Audio: FOOTSTEPS WORK -- reconstruct the lost game-side step-intensity broadcast (task #50)
The final link: the footstep source's volume + brightness mix from two AudioControlMixer inputs (ctl 100 walk / 101 run) behind an entity-registered AudioControlSplitter. The object stream only ZERO-initializes those inputs (AudioControlSend one-shot initializers; mixer ctor inits 0.0) -- the runtime feed was BT game code (lost with the source), using the engine's game-facing Entity::AudioSocketIterator broadcast (the only path to those anonymous components; the splitter registers via entity->AddAudioComponent). Reconstruction [T3]: on each foot plant (the SetBodyAnimation locomotion-clip pulse), broadcast the step intensity (live ground speed on the authored 0..40 -> 0..1 velocity-curve family, floored at 0.35 to clear the 0.3 transient-drop gate) on the gait-appropriate input (run-family clips 0x0a..0x0f -> 101, walk family -> 100; the other input zeroed so gait changes don't stack). Patch-source components (VDATA 1001/1002/1005) are skipped -- AudioSource::ReceiveControl Fail()s on input-range ids. VERIFIED: FootFallInt01.wav (bank2 patch39) delivers + plays per stride; mixer sums nonzero (vol=1 at run speed); 30s drive+fire regression clean -- weapon charge/fire/sustain cycles, ready dings, buttons, engine loops, state audio (0 skips), gait advancing normally, no crashes, no stuck loops. Also this session: [seqcfg] sequence config dump (decoded the authored event streams: ctl 8=note/6=attack-vol/1=start/2=stop patterns), BT_AUDIO_NODROP diagnostic (force low-volume transient delivery at a 0.7 floor). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
f4b2a7f87f |
Audio: fix POISONED calibration rate (raw-offset garbage) + calibrated audio clock (task #50)
Two real bugs found + fixed chasing the footstep volume: 1. BTL4Application::MakeAudioRenderer read sample_rate from a raw 1995-layout offset (divisionParameters+0x10) -- the databinding trap: it yielded -1.6e14 (measured), poisoning Renderer::calibrationRate for the ENTIRE audio system. Every AudioTime conversion (sequence event scheduling, compression curve durations, Seconds_To_Frames) was garbage. Sanity-clamp to the authored 1000 frames/sec default (BT_AUDIO_LOG logs the value). 2. AudioHead::Execute fed audioFrameCount raw OS ticks; now converts ticks -> calibrated frames via SystemClock::GetTicksPerSecond (1000ms fallback when the static isn't measured yet), so AudioTime consumers see the rate they were calibrated for. With rate=1000 + ms ticks the units now align end-to-end. Footstep status: chain verified through pulse -> matcher -> Start -> renderer; the volume mixer's two inputs receive only value-0 AudioControlSequence events even with correct timing -- the authored event VALUES need decoding next (sequence tempo/divisions ctor dump; possibly Verify()-stripped tempo garbage or the events are resets and the true volume rides another control id). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
1d019e8109 |
Audio: footstep pulse VERIFIED end-to-end to the matcher; volume chain traced (task #50)
Footstep chain progress (each step empirically verified): - The FootStep watcher is an AudioMatchOf<Logical> (AudioLogicalTrigger extends AudioMatchOf, NOT AudioTriggerOf): authored config match=1 -> Start(2.0) on a DirectPatchSource. [trigcfg]/[matchcfg] ctor dumps added. - The pulse was pinned at 1: the decay lived in IntegrateMotion, which the current gait path NEVER CALLS. Moved to Mech::PerformAndWatch (provably per-frame) with a time-based 150ms window sized to the ~10Hz watcher poll. The matcher now fires per stride (14/run, was 1). - Every footstep Start is DROPPED at the renderer: the source's volumeScale is 0 (five VolumeAudioHandler sends of exactly 0 = inert/one-shot primes). The volume arrives through the authored control chain (AudioControlMultiplier inputs ctl 100+; one 0 input pins the product). Chain scales identified on this entity: LocalVelocity (live), LocalAcceleration (live), Myomers. SpeedEffect (=1.0 healthy; one authored scale maps [0,1]->[1,0] INVERTED), UnstablePercentage (INERT PAD -- always 0!), HeatSink.CurrentTemperature. PRIME SUSPECT: an UnstablePercentage-fed multiplier input primes 0 once and never updates (the pad never changes), pinning footstep volume at 0. - SF2 numbering fact recorded: 38 presets in AUDIO1 / 5 in AUDIO2 have wPreset != file index (gap at preset 77); my table keys by wPreset. The 184x ProgramButton01 (bank1 patch83) storm at ~7/s needs an identity check against index-numbering (it may be the wrong sample for that patch id). Diagnostics added (BT_AUDIO_SPATIAL/BT_ATTRBIND_LOG): [trigcfg]/[matchcfg] ctor dumps, [matchfire] with component ptr+class, [volset] VolumeAudioHandler, [mult0] multiplier zero-products, scale sends with authored boundaries, [fswatch] dedicated footstep watcher tracer (g_btFootStepAddr), SetupPatch ENTRY with bank/patch/state, Simulation::DebugAudioWatcherCount. NEXT: back UnstablePercentage with a real (live) member -- it is the mech's stability 0..1 (the stabilityAlarm/gyro family) -- or confirm via a one-run chain dump which multiplier input pins the FS source; then the footstep transient should clear the 0.3 drop gate at walking speed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
ba3040ea09 |
Audio: footstep-chain diagnostics -- every link verified except the final trigger fire (task #50)
Instrumentation (all BT_AUDIO_LOG/BT_AUDIO_SPATIAL-gated): mech watcher-poll probe (delayed flag + socket count via new Simulation::DebugAudioWatcherCount), per-sim audio-socket size in ExecuteWatchers, trigger notifications (val>0), watcher poll-rate/change probes, footstep pulse address trace. VERIFIED working: FootStep binds to the real member (pulse addr == bound ptr, same run); pulses fire per stride (40/run); the watcher registers on the mech (audioWatchers=20 after audio-object creation); the mech's poll runs (delayed=0, simFlags=0x1110); Logical == int (STYLE.H:132) matches the member type. The idle<->moving engine crossfade (AudioMotionScale on LocalVelocity through the restored watcher poll) is CONFIRMED audible in play. REMAINING: the FootFall transient still doesn't reach SetupPatch -- next probe is the trigger's streamed threshold/inverse config and the speed-scaled transient volume at the renderer drop gate (LowAudioVolumeThreshold=0.3). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
744ef8cc16 |
Audio: restore the dropped ExecuteWatchers poll -- polled audio watchers were ALL dead (task #50)
User: "when I start moving all the sounds fade away, no footsteps." Diagnosis chain (all empirical, BT_AUDIO_SPATIAL/BT_ATTRBIND_LOG traces): - The audio head DOES track the mech (listener-relative positioning verified while driving) -- not a spatial bug. - The idle sounds correctly STOP on leaving the standing state; the MOVING sounds never started because every POLLED audio watcher was dead: the reconstructed Mech::PerformAndWatch replaced the engine performance but dropped the ExecuteWatchers() step from the engine tail (Simulation:: PerformAndWatch = Perform -> ExecuteWatchers -> WriteSimulationUpdate). Only PUSHED StateIndicator watchers (SetState->Execute) ever fired -- which is exactly why state sounds worked but footsteps/motion-scaled audio didn't. FIX: poll ExecuteWatchers() (AreWatchersDelayed-gated) before the update write. Immediately unlocks the polled family: MissileLoaded01/LaserLoaded01 ready dings, ProgramButton01, motion scales (PlayNote 15 -> 30 per run). - FootStep (0x1e) backed REAL: was the inert attrPad (an AudioLogicalTrigger polls it -- threshold-crossing pulse per foot plant). New footStep member, pulsed by SetBodyAnimation on entering any locomotion clip 1..0x17 (runtime stride alternation MEASURED as body states 12<->13 -- the enum-name numbering does not match runtime clip ids), decayed by IntegrateMotion (~1/3 s). - Footstep volume is speed-scaled (AudioMotionScale on LocalVelocity): at standstill the transient start computes volume 0 and the renderer drops it (LowAudioVolumeThreshold) -- so footfalls are audible at real walking speed. Diagnostics kept (BT_AUDIO_SPATIAL): spatial dist/vol per source, CLIPPED/DROP/ START at the request gate, vol=0 factor breakdown, scale->0 sends, trigger notifications, watcher poll-rate probe. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
ea8555480e |
Audio: fix stuck MissileLoading loop -- ProjectileWeapon never reached a ready state (task #50)
The runaway loop the user heard was MissileLoading01: the ProjectileWeapon (SRM/ballistic) state machine set Firing(0)/Loading(3)/Jammed(5)/NoAmmo(7) but NEVER a ready/Loaded level, so at idle the launcher parked in Loading(3) forever. Its WeaponState audio (weaponAlarm, now StateIndicator-firing) therefore looped MissileLoading indefinitely -- the loop stops only when the alarm LEAVES the loading state. (The laser sibling was fine: the Emitter DOES reach Loaded when its charge tops off, so LaserACharge stopped.) Fix: in ProjectileWeaponSimulation's default (idle/ready) branch, drive the state from readiness -- Loaded(2, charge + ammo up = silent ready) once ReadyToFire, else Loading(3, reloading). SetLevel fires audio only on a real change, so this yields the natural Firing -> Loading(reload) -> Loaded(ready) cycle and the MissileLoading loop now stops when the launcher finishes reloading. Verified: weapon cycles Loading(3, recoil>0)->Loaded(2, recoil<=0); the only remaining continuous loop is EnginePower (correct). Fire path unchanged. Also: master volume default kept; richer BT_AUDIO_LOG StopNote/SetupPatch traces. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
c27af4800b |
Audio: fix stuck weapon charge/sustain/loading loops -- maintain GaugeAlarm54 oldState (task #50)
WeaponState -> weaponAlarm (mechweap.cpp:149), and the weapon's looping audio (LaserACharge/LaserASustain/MissileLoading, all SF2 sampleModes=1) is STARTED by an AudioStateWatcher on the firing/charging state and STOPPED by an inverse AudioStateTrigger that keys on old_state (== the state being LEFT). The subsystem-state commit fired GaugeAlarm54 watchers on SetLevel but deliberately left levelB (the oldState slot @0x10) untouched to avoid disturbing the weapon's LevelCountB read. Consequence: the audio watcher's StateChanged(oldState,newState) saw a stale oldState, so the inverse/STOP triggers never matched -> the charge/ sustain/loading loops played forever. Fix: SetLevel now sets levelB := level (oldState := currentState) before the change, exactly like StateIndicator::SetState. The stop triggers now match on leaving the state and StopNote the loop. This is also authentic: in the binary the 0x54 alarm +0x10 IS oldState, and the weapon's LevelCountB()/weaponIdle read of +0x10 is that same oldState (the old static-count reading was the reconstruction's accident). weaponIdle is only consumed in the MP replicant record-apply path, so single-player firing is unaffected; the value is now the authentic oldState-based one. Subsystem state audio unaffected (0 skips). Diagnostics: BT_AUDIO_LOG now traces SetupPatch src/file/loop + StopNote. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
41c8ac120d |
Audio: fix runaway loops -- read SF2 sampleModes, not loop-point presence (task #50)
Weapon fire (and ~all one-shots) played FOREVER: sf2extract flagged a sample as looping whenever the SF2 shdr had loop points -- but almost every SoundFont sample has loop points; whether to actually loop is the instrument's sampleModes generator (igen oper 54): 0/2 = one-shot, 1 = loop, 3 = loop-until-release. The old heuristic looped 239/241 samples, so SetupPatch set AL_LOOPING=1 on fire/explosion/step sounds. Read sampleModes at the same igen zone as sampleID and loop only on 1/3. Now 166 one-shot / 75 loop: LaserAFire/BigExplosion/BasicClick -> ForceStatic (one-shot), EnginePower/EngineMotor/coolant -> LoopAtWill (correctly sustained). Regenerated audiopresets.cpp; the WAV PCM is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
dcdd7dd0a7 |
Audio: register Generator.GeneratorOn -> generatorOn (@0x1D4) (task #50)
The last cleanly-backed subsystem audio attr: GeneratorOn (AudioLogicalTrigger) now resolves to the real generatorOn member instead of the inert pad. Static for now (init 1, no shutdown writer drives it to 0 yet), but bound correctly. Remaining inert attrs (ReportLeak/ConfigureActivePress/MotionState/ SpeedOfTorsoHorizontal/TargetRangeExponent) have no modeled backing member in their size-locked subsystem layouts -- they read the inert pad (silent, no crash) until those members are reconstructed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
0e05a22a55 |
Audio: AmmoBin AmmoState + chain its attribute index -> ZERO state-watcher skips (task #50)
AmmoBin::AttributeIndex was a bare, default-constructed static with NO parent chain, so nothing resolved on an AmmoBin -- even the inherited SimulationState came back NULL (the audio AmmoState + SimulationState watchers were skipped). - Chain AmmoBin::AttributeIndex to HeatWatcher::GetAttributeIndex() and give it a real AttributePointers[] with AmmoState -> ammoAlarm (@0x194, the 6-level 0x54 StateIndicator-compatible feed alarm, already SetLevel'd Feeding/Loaded/Empty/ Dumped by the sim) so reload/empty/feed audio fires on the ammo transition. With this every StateIndicator audio attribute across the mech + all subsystems binds to a real indicator: audiostate skips 85 -> 0. Remaining audio gaps are the inert Logical/Scalar/Enum subsystem attrs (ReportLeak/GeneratorOn/ConfigureActive Press/MotionState/SpeedOfTorsoHorizontal/TargetRangeExponent), which read 0 (silent, non-crashing) pending backing members in their size-locked layouts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
5ba541ed56 |
Audio: subsystem STATE sounds -- GaugeAlarm54 IS a StateIndicator; register Generator/Condenser/Reservoir state (task #50)
The audio subsystem binds AudioStateWatchers (class 28) to per-subsystem state attrs (GeneratorState/CondenserState/ReservoirState) BY NAME. Recovered the watcher TYPE per attribute via a MakeObjectImplementation ClassID trace. Root cause of the subsystem-state crash: the binary's 0x54-byte subsystem alarm (FUN_0041b9ec, reconstructed as GaugeAlarm54) IS a StateIndicator -- its "three sub-indicators" @0x18/0x2c/0x40 are the audio/video/gauge watcher SChains, and level@0x14 is currentState. The reconstruction had modeled that tail as an opaque `_tail`, so the sockets were never constructed -> AddAudioWatcher AV'd on 0xCDCDCDCD. - GaugeAlarm54: give it the three REAL, constructed SChainOf<Component*> sockets + AddAudioWatcher/Video/Gauge; SetLevel now fires the watchers on a level CHANGE (empty sockets = no-op, so the ~all other alarms are unaffected). levelB (weapon LevelCountB "reset source") is left untouched -- weapons unchanged. sizeof stays 0x54 (static_assert holds -> SChainOf<Component*> is 0x14, layout exact). - Register the state attrs -> the subsystem's own alarm (own AttributePointers[] chained to the parent): Generator.GeneratorState->stateAlarm, Condenser. CondenserState->condenserAlarm, Reservoir.ReservoirState->reservoirAlarm. Those alarms are already SetLevel'd by the sim, so the state audio fires on transition. - AudioStateWatcher guard now validates the +0x18 SOCKET (what AddAudioWatcher touches), not the +0 vtable -- GaugeAlarm54 is non-polymorphic at +0 (raw header) but has a real socket at +0x18. audiostate skips 85 -> 10 (only AmmoBin AmmoState/SimulationState left). The Logical/Scalar/Enum subsystem attrs (ReportLeak/GeneratorOn/ConfigureActivePress/ MotionState/SpeedOfTorsoHorizontal/TargetRangeExponent) stay inert (read 0, silent, non-crashing) -- they need backing members in size-locked layouts (a polish wave). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
7b1e469ffa |
Audio: in-game TRIGGERING works -- real StateIndicator attrs + audio-watcher databinding (task #50)
Enabling audio unlocked L4AudioRenderer::CreateEntityAudioObjects, which binds AudioStateWatchers to entity/subsystem state attrs BY NAME (attribute-pointer databinding) and calls AddAudioWatcher on them. The reconstruction pointed the Mech's state attrs at the scalar read-pad `attrPad` (fine for gauges that READ a value, fatal for a state watcher that calls a METHOD) -> AV in SChainOf::Add on 0xCDCDCDCD. Root-caused via cdb + a BT_ATTRBIND_LOG trace in AttributeWatcher. Mech-level state audio now REAL + driven (verified: walking fires SetupPatch + PlayNote/alSourcePlay, patches 78/80/116): - AnimationState (0x1f) / ReplicantAnimationState (0x20): real StateIndicators (0x21 states covering MechAnimationState 0..0x20), driven from SetBodyAnimation so footstep/gait/transition sounds fire on animation change. - CollisionState (0x16): real 4-state StateIndicator driven from ProcessCollision via collisionTemporaryState (the deferred @4aa741 per-frame zero + the part_012.c:15406-15413 contact tail, InitialHit accumulation; the 1-vs-2 Slide split awaits the 0x240/0x244 floats still stubbed by fieldAt()). - @0x44c CORRECTED: "ammoState (0/1 leaking/2 dry)" was a mislabel -> it is collisionTemporaryState (never read as ammo). Bring-up guards [T3, temporary, self-clearing] so audio-on is STABLE while the subsystem state models are still stubs (Generators/Condensers/Myomers/Torso/ Avionics/Reservoir/ControlsMapper -- ~15 subsystems, ~40 attrs: GeneratorState, CondenserState, ReportLeak, ...): a NULL subsystem attr redirects to an inert pad (was a fatal Fail); an AudioStateWatcher on an unconstructed StateIndicator (null/ 0xCDCDCDCD) skips instead of AV. Both pass automatically once the subsystem is reconstructed. Those subsystem sounds stay silent until then (their audio wave). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
5b46655b82 |
Audio: ENABLE sound -- real OpenAL + in-tree WAV loader; both backend DLLs were no-op STUBS (task #50)
Root cause of "no sound, ever": the two audio backend DLLs shipped in the repo are fakes. libsndfile-1.dll exports 15 funcs BY ORDINAL ONLY (no names) and sf_open() always returns NULL; OpenAL32.dll (72KB) imports only KERNEL32 -- no dsound/wasapi/winmm -- so it is a pure no-op that returns fake handles (ctx=0x00000001, alGenSources->0) and never touches the hardware. The whole render->device->buffer->source->play chain ran clean and silent. Fixes: - OpenAL32.dll: replace the stub with the real OpenAL Soft 1.25.2 Win32 build (imports AVRT/ole32/WINMM, real WASAPI backend). The exe imports the 25 AL funcs by NAME so it is a drop-in; alGenSources now yields a live source and alSourcePlay reaches AL_PLAYING. - libsndfile: DROPPED entirely. It is replaced by LoadWavPCM() in L4AUDRES -- a tiny RIFF/WAVE fmt+data reader that loads our soundbank WAVs (16-bit PCM) straight into the AL buffer. Removed the .lib/.dll from the link + copy and git-rm'd the stub. (This also kills the "ordinal 50 could not be located in libsndfile-1.dll" load-failure popup: adding an sf_strerror import bound to an ordinal the 2..16-only stub could not satisfy.) - Soundbank: 241 samples cracked from AUDIO1/2.RES (SF2 v1.0) by tools/sf2extract.py into content/AUDIO/*.wav + the allPresets[2][128] table (audiopresets.cpp), replacing the zero-init btstubs stub. All 241 now load (alErr=0). BT_AUDIO_TEST plays buffer0 as proof-of-life; BT_AUDIO_LOG traces the chain. Remaining: in-game triggering (AudioEntities on fire/step/engine/explosion) so PlayNote fires during play -- next audio wave. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
52440e13b0 |
Audio: ENABLE the engine (relax dead AWE-card gate) + diagnose the real silence (task #50)
User reported never hearing any audio. Root-caused: the KB "Audio: DONE" was wrong. The OpenAL playback chain IS fully implemented (device/buffers/sources; PlayNote really calls alSourcePlay), but three gaps kept it silent: 1. GATED OFF (the "no sound" root cause): BTL4Application::MakeAudioRenderer returned NULL unless the pod's AWE_FRONT/AWE_REAR AWE32-card env vars were set -- authentic 1995 pod behavior, dead on modern hardware, so the renderer was NEVER created. FIXED: default audio ON (BT_NO_AUDIO=1 restores silence; AWE vars still force-on). Verified: the OpenAL device now opens with no env vars ([audio] device OPENED). 2. Soundbank STUB: allPresets[2][100] (btstubs.cpp) is zero-init -> PRESET_isImplemented false -> 0 buffers load. Sample data exists (AUDIO1/2.RES: EnginePower/LaserAFire/...) but the event->sample map is gone (not in the decomp). STILL OPEN. 3. No triggering: the reconstructed game never creates AudioEntities on events. STILL OPEN. So the device opens but nothing loads/plays yet -- enabling real sound needs the soundbank reconstructed + the game triggers wired (a proper audio wave). Added a BT_AUDIO_LOG trace harness across L4AUDRND/L4AUDRES/L4AUDLVL. KB corrected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
3224009dc1 |
MP: peer accel/decel "snap" MEASURED ~0.64u (not ~2.9u) -- effectively resolved (task #50)
Went after the flagged ~2.9u peer-motion snap. Added a BT_SNAPLOG diagnostic
(mech4.cpp: logs the re-anchor drift eMag = |authority - dead-reckon| absorbed per
frame) and ran a controlled accel/decel soak: node B BT_AUTODRIVE + BT_DRIVE_SWEEP0
sweeping the throttle through STOP, node A observing, affinity-pinned.
Result: peer drift maxes at ~0.64u (median 0.54u, 18 events >0.5u over 48s), gently
absorbed at k~0.24/frame -- SUB-UNIT, at the noise floor. The ~2.9u figure was stale:
it predated the peer body-channel swap (
|
||
|
arcattackandClaude Opus 4.8
|
aab7a8a137 |
Combat: FIX weapon effectiveRange -- it degraded with heatLoad, not host-zone damage (task #50)
MechWeapon::UpdateTargeting computed effectiveRange = (1 - heatLoad) * weaponRange, reading the weapon's own inherited HeatableSubsystem heatLoad. The authentic decomp (@004b9bdc:6983) reads *(weapon+0xE0)+0x158 = Subsystem::damageZone->damageLevel -- i.e. effectiveRange = (1 - HOST-ZONE DAMAGE) * weaponRange. Same @0xE0-DamageZone-vs- heat misattribution already corrected in HeatSink::UpdateCoolant (heat.cpp:803). Impact: for a charge/discharge weapon (ER laser) the weapon's OWN heatLoad swings 0..1 every fire cycle, so effectiveRange collapsed toward 0 and the weapon was perpetually "out of range" -> Emitter::FireWeapon's `if (dist <= effectiveRange)` gate skipped SendDamageMessage -> NO damage submission and hence NO impact explosion. The beam still rendered (beamFlag/beamEndpoint set before the gate), so the shot LOOKED like a hit but did nothing -- the user-reported "lackluster/absent laser hits, esp. the ER medium, on mechs AND buildings". PPCs mostly worked only because their heatLoad happened to sit low/stable. Fix: read the QUALIFIED this->Subsystem::damageZone->damageLevel (the MechSubsystem shadow is a shim -- heat.cpp:812) so an UNDAMAGED weapon holds its full, STABLE weaponRange, and range shortens only as the weapon's host zone takes battle damage. Verified (parked in range of a building, autofire): laser effRange 500 STABLE (was fluctuating 0/59/340/424 -> mostly out of range); impact explosions 13 in 22s (11 laser id=16 + 2 PPC), up from ~2. Lasers now consistently damage + spawn FX. Also adds env-gated diagnostics used to root-cause this: [fireW] range trace + per-weapon explID (emitter.cpp), and BT_FIRE_AT_STRUCT (mech4.cpp) which designates the nearest world structure so weapon-vs-structure fire can be tested without the screen aim ray. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
de8f6d02c1 |
MP: world structures (garages/walls) TARGETABLE -- boresight ray-tests the static collision tree (task #50)
The boresight's non-mech pick only sampled the VISUAL heightfield (BTGroundRayHit), which on arena1 is a single flat 'sky'-named ground mesh (and class-42 BuildTables likewise holds only 'sky') -- so shots passed THROUGH the garages/walls and only mechs moved the HUD range axis (user-reported regression: "buildings used to move the range axis; now only mechs do, and you can only fire at a peer"). Real fix: the boresight now ALSO ray-tests the ZONE'S STATIC COLLISION SOLID TREE -- the same geometry that already blocks the mech's walk. Authentic engine mechanism: Mover::FindBoxedSolidHitBy already tests the static world via zone->GetCollisionRoot()->FindBoundingBoxHitBy(line). Factored its "static world" tail into Mover::FindStaticSolidHitBy(Line*) (static solids only, no movers), wrapped by Mech::WorldStructurePick(start,dir,range,&hit) (builds the world-space Line, reads the entry point back via line->FindEnd since HitByBounded clips line->length=enter). Boresight pick order is now: closest MECH (PickRayHit, damage zones + lock) -> closest STRUCTURE (WorldStructurePick; occludes a mech BEHIND it; designates the gBTTerrainEntity sentinel + entry point, so the range caret reads the structure distance and NO lock ring draws, mech4.cpp:4529) -> flat ground (BTGroundRayHit) -> sky (fire-at-nothing). Also un-skips arena1's misnamed-'sky' flat ground so the ground tier works (btvisgnd geometry-aware skip + [mapent]/[rendent] census). Verified headless: a BT_WSWEEP horizontal ray-fan on arena1 tracks position (3/24 hits near the boundary -> 17-21/24 inside the interior garage cluster -> 3/24 past it = DISCRETE interior solids, not an enclosing box), no crash/assert/AV. Interactive aim (BTGetAimRay) can't run headless (no window -> noRay), so the sweep is the headless proof; interactive aim is user-verified. Note: FindBoundingBoxUnder (the ground/containedByNode BoundingBoxTree) is DOWNWARD-only (gravity/ground-snap: *height = FindDistanceBelowBounded), useless for a horizontal boresight; the static SOLID tree's FindBoundingBoxHitBy is the only ray-vs-world query. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
ee6e19e86e |
Combat: RESTORE authentic fire-at-nothing + non-mech range axis (task #50 / Discord report)
Determined the authentic behavior from the decomp (HudSimulation + Emitter,
part_013.c:5619-5670 / 7689-7778) and fixed two regressions the players hit:
(A) You could only fire when a MECH was locked (couldn't fire at nothing).
(B) Buildings/structures/ground stopped moving the range axis; only mechs did.
AUTHENTIC (T1): a weapon discharges iff the target slot mech+0x388 != 0
(Emitter::FireWeapon FUN_004bace8:7727), and 0x388 is whatever the BORESIGHT
designates -- mech OR world geometry -- NOT a manual mech lock. The RANGE readout
(HUD+0x1ec) moves for ANY designated target (mech OR structure/ground); the LOCK
ring is mech-only (target has a damage-zone table, HudSim :5619). So the pod
'fired freely at nothing' and buildings moved the range caret.
ROOT CAUSES (both content-triggered, not a targeting-code change):
1. arena1's ONLY class-42 world entity is the 10000x10000 FLAT GROUND plane at
y=0, MISNAMED 'sky' -- SkippedName filtered it out by name, so BuildTables
ingested 0 geometry and gBTTerrainEntity stayed null -> nothing groundable ->
mech-only targeting. (LAST.EGG rewrite ~bb795e2 lost whatever terrain the
working scene had.)
2. A boresight that hit nothing set MECH_TARGET_ENTITY=0 -> no discharge.
FIXES:
- btvisgnd.cpp: geometry-aware skip -- keep a wide, near-flat, near-ground plane
even if name-skipped (it is the arena floor); still skip true domes/backdrops.
Adds mesh y-bounds. arena1 now ingests 1 ground instance (was 0).
- btl4vid.cpp: capture ANY world-geometry entity as the non-mech pick sentinel
(the default render case is world-only), not only Terrain-derived ones.
- mech4.cpp: FIRE-AT-NOTHING -- when nothing pickable is hit, designate a
max-range point (1200, the HUD default 0x44960000) along the boresight using
the world sentinel, so 0x388 != 0 and the weapon discharges (no zone damage /
no lock ring, since the sentinel has no damage-zone table -- mechs only).
Verified autonomous: arena1 ground ingested; [target] shows 'fire-at-nothing
(max-range designate)'; weapon discharges at empty space ([fire] explode
resolved); range axis (sShownRange->BTSetHudTargetRange) slides to the designated
distance. Diagnostic: BT_GROUND_LOG (world-geometry ingest + skip reasons).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
arcattackandClaude Opus 4.8
|
49d73dc8e2 |
MP: peer shakiness ROOT-CAUSED as single-box packet jitter (rig, not game) + affinity launcher (task #50)
The residual RANDOM peer shakiness on accel/decel was proven (BT_RXJIT record inter-arrival probe) to be TEST-RIG packet jitter, not the game: two Debug btl4 nodes on one box contend for CPU, so Windows batches their TCP delivery -- records arrive in bursts (max 56-226ms gaps, burstiness 3-7x) instead of even ~17ms. The peer dead-reckons across the gaps then snaps -> random shake. Pinning the nodes to disjoint cores restored even ~17ms delivery (burstiness ~1.0) and the shakiness vanished (user-confirmed 'that was it'). Real pods = dedicated machines, no contention -> never see it. So NO un-authentic jitter buffer -- the coupled body-channel peer (96a896a/f094d78/23f1532) is the authentic + correct finish. - mech.cpp: BT_RXJIT record-arrival-jitter probe (env-gated). - tools/mp_launch.sh: 2-node launcher that pins nodes to disjoint cores (bakes in the fair-delivery condition; documents why). - context/multiplayer.md: the finding, so it is not re-litigated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
arcattackandClaude Opus 4.8
|
23f1532fb0 |
MP: peer true-mirror cadence -- drive the body clip from actual replicated motion (task #50)
Toward a truer mirror (user: peer 'hesitates/skips on accel/decel, master has
smoother transitions'). The body channel FOLLOWS the master's replicated STATE
(
|