44f79fcbfeb66778bba89243dad8f5541e17ddba
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CydandClaude Fable 5
|
c85bf98814 |
BT410 5.3.103: the INTERIOR clip set, the duck, and why state 4 was always the turn
Three finds from one suffix table, closing the last mech2-family loader:
THE 'i' SET. The 4-char table at .data:0050d94d is the 3-char gait table
with an 'i' appended -- swri, wwri, ... squi, sqdi, trni. These are the
INTERIOR clips: the gait as seen from inside the cockpit, animating the
inside-view skeleton (they never bind the hip -- you cannot see your own
hip from the seat). LoadLocomotionClipsExt (@004a86c8) is byte-identical
to LoadLocomotionClips over that table, and is now its reconstructed twin.
THE VIEW DISPATCH (ctor tail @0x4a1674 region): a REPLICANT loads the
exterior set -- you see it from outside -- while the MASTER loads the
interior set. And the binary carries its own dev override: the L4VIEWEXT
env var forces the exterior set on a master for external-camera work.
Which is exactly what our render-bridge verification rigs need, so
pod_render_joints/limp.conf now set it -- the 1995 authors shipped the
switch our test harness wanted.
THE TAIL THE 5.3.93 LOADER MISSED: two more optional sets past the limp
probes. squ/sqd resolve into slots 3 and 2 with squatCapable -- the DUCK:
state 2 plays the squat-down, holds ducked at state 1, state 3 stands back
up (three state numbers the machines always handled but never had clips
for). And trn resolves into SLOT 4 with turnCapable -- which is WHY state
4 is turn-in-place. The slot map explains the state machine, again.
VERIFIED both paths live: L4VIEWEXT rig run measures the exterior set
bit-identically to 5.3.93 ('mad': standSpeed=5.23428 walkStride=18.5085
revStride=56.0462); the authentic default (master -> interior) measures
THE SAME CONSTANTS from the 'i' clips -- as it must, the mech covers the
same ground from either view, only the joint content differs -- proving
every madXXXi clip resolves. No fault on either run.
turnCapable is now real, which unblocks the turn-in-place dispatcher
(master perf) as the next locomotion piece.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
7c2363d89f |
BT410 5.3.96: the LIMP is real -- all twelve mech2 functions reconstructed, and the drag leg shows up on the wire
The "gimp" family had two conflicting donor readings -- limp vs jump-jet --
flagged in 5.3.94 rather than guessed at. The binary settles it: LIMP. The
mode test in every gimp function is mech+0x40 in {3,4}, the same values the
damage model documents as "limp gait graphic (left 3 / right 4)"; there is no
jump-jet control anywhere in the pod cockpit; and the donor's port routing
("graphicAlarm 3/4") was the same field under a different name. Its
"run-jump clip" mech3 annotations were the misreading that started the murk.
RECONSTRUCTED, completing all 12 of mech2's census functions:
GimpLegClipFinished @004a7970 GimpBodyClipFinished @004a6344
AdvanceLegAnimationGimp @004a71f4 AdvanceBodyAnimationGimp @004a5bf8
+ the limp branch atop both normal *ClipFinished
+ the limp pick in Simulate (replaces the normal advancers while limping)
HOW A LIMP WORKS, now from the bytes rather than description:
It replaces ONE stride. Limping left, the right stride (6) hands off to
the left limp figure (0x16 -> the self-cycling 0x18) while the other leg
keeps its normal clips. The asymmetry IS the limp.
Both machines CLAMP THEIR DEMAND while in a cycle -- the leg machine
writes the mapper's own speedDemand cell down to the damaged side's cap
(new MechControlsMapper::SetSpeedDemand, matching the binary's direct
mapper+0x128 write), the body machine clamps bodyTargetSpeed, both floor
at zero. A limping mech cannot command more than its figure carries, nor
reverse out of a forward cycle.
The limp advancers keep states 0x16-0x1b LIVE -- the normal advancers
treat those as the reset group, which is exactly why the limp flavours
must be selected while limping or the figure is neutralized mid-cycle.
No death latch, no wind-down: the movement modes are exclusive.
ALSO EXPLAINED IN PASSING: Ghidra's 3760-byte FUN_004a6344 -- the census's
largest function -- is really THREE functions. The two normal ClipFinished
callbacks (@004a6928/@004a6d8c) are reached only via data pointers, so the
decompiler folded them into the gimp-body machine's extent.
All movement-mode reads route through Mech::MovementMode() (mech+0x40 == the
simulation state), which honours a BT_FORCE_LIMP=3|4 dev hook so the gait
could be verified before the damage model's limp hook exists.
VERIFIED, two runs on the rig:
NO-REGRESSION: the normal mission's speed sequence is BIT-IDENTICAL to
5.3.95 (7.31972, 26.6726, 22.1601, ...). The branch costs nothing.
FORCED LEFT LIMP (new pod_render_limp.conf): the mapper still demands
26.9; the hull lurches at 10-23. And on the wire the healthy walk's tight
pose-count pairs (650/649 ... 434/421) BREAK to a 3x asymmetry -- the
drag-leg joint at 18 poses against its partner's 55. The limp is visible
in the data exactly the way it will be visible on screen.
STILL OPEN in this family: the damage hook (leg zone >= 0.5 -> mode 3/4, a
MECHDMG increment -- nothing sets the mode in real play yet), and
IntegrateMotion's remaining pieces.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|