erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(anim): stop ACE echo from clobbering player's speedMod; synthesize sequencer velocity

Browse source 
Two related bugs in the motion/animation pipeline:

1. Player's local animation was getting reset to speedMod=1.0 every ~100ms.
   ACE's BroadcastMovement echoes the player's own motion back via
   UpdateMotion. When ACE's ForwardSpeed == 1.0, the ForwardSpeed flag is
   omitted (InterpretedMotionState.BuildMovementFlags), so our wire parser
   returns null and we default to speedMod=1.0 — clobbering the
   locally-authoritative 2.375 × runRate that UpdatePlayerAnimation just
   set. Legs would crank up to full cadence for one frame then get slammed
   back to walking rate.

   Fix: for the player's own guid, skip the wire-echo SetCycle entirely.
   UpdatePlayerAnimation is the authoritative driver for the local
   player's animation; the server echo is only useful for observers of
   other characters. User-confirmed: legs now hold their full cadence.

2. Remote entities teleported between UpdatePositions because the
   sequencer's CurrentVelocity was always zero (Humanoid dat ships every
   locomotion MotionData with Flags=0x00, so EnqueueMotionData leaves
   CurrentVelocity at Vector3.Zero). Dead-reckoning's Priority 1
   (sequencer velocity) never triggered, falling through to EMA which
   has bootstrap lag + gets polluted by teleport-class server snaps.

   Fix: synthesize CurrentVelocity in SetCycle from the retail locomotion
   constants (WalkAnimSpeed=3.12, RunAnimSpeed=4.0, SidestepAnimSpeed=1.25)
   × speedMod, matching the decompiled get_state_velocity (FUN_00528960)
   which uses these same constants directly instead of MotionData.Velocity.
   The dat's HasVelocity field is reserved for non-locomotion motions
   (kick-off velocities, flying creatures, etc).

   Diag confirmed synthesis fires and DR picks it up with src=seq and
   correct magnitude. More visual polish may still be needed for the
   "lagging remote" symptom — see follow-up.

Also adds `PlayerMovementController.BodyVelocity` utility getter for HUD/
debug use, and `ACDREAM_ANIM_SPEED_SCALE` env var as a tunable knob for
visual pacing overrides.

All 717 tests green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik 2026-04-19 16:22:35 +02:00
parent 795d9c8a88
commit 00c8a4feb5
3 changed files with 110 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

67
src/AcDream.Core/Physics/AnimationSequencer.cs
View file

@ -426,8 +426,75 @@ public sealed class AnimationSequencer
CurrentStyle = style;
CurrentMotion = motion;
CurrentSpeedMod = speedMod;
// ── Synthesize CurrentVelocity for locomotion cycles ──────────────
// The Humanoid motion table ships every locomotion MotionData with
// Flags=0x00 (no HasVelocity), so EnqueueMotionData leaves
// CurrentVelocity at Vector3.Zero. That matches the literal retail
// dat, but retail's body physics uses CMotionInterp::get_state_velocity
// (FUN_00528960) which returns RunAnimSpeed × ForwardSpeed for
// RunForward, independent of the dat's HasVelocity flag. The dat
// velocity is a separate additive source (kick-off velocity, flying
// creatures, etc) not the primary locomotion drive.
//
// For our sequencer's <see cref="CurrentVelocity"/> to be usable by
// consumers (local-player get_state_velocity via Option B, remote
// dead-reckoning in GameWindow) it must carry the retail-constant
// locomotion value when the dat is silent. Synthesize it here,
// post-EnqueueMotionData, only when the cycle is a locomotion cycle
// AND the dat didn't populate it.
//
// Constants match <see cref="MotionInterpreter.RunAnimSpeed"/> etc —
// decompiled from _DAT_007c96e0/e4/e8. The velocity is body-local
// (+Y = forward, +X = right); consumers rotate into world space via
// the owning entity's orientation.
if (CurrentVelocity.LengthSquared() < 1e-9f)
{
float yvel = 0f;
float xvel = 0f;
// Low byte of the ORIGINAL (non-adjusted) motion tells us which
// intent the caller signalled. adjust_motion may have remapped
// TurnLeft → TurnRight / SideStepLeft → SideStepRight /
// WalkBackward → WalkForward, encoding the sign into adjustedSpeed.
// The speed sign is preserved in adjustedSpeed so we multiply by
// it rather than re-deriving per-case.
uint low = motion & 0xFFu;
switch (low)
{
case 0x05: // WalkForward
yvel = WalkAnimSpeed * adjustedSpeed;
break;
case 0x06: // WalkBackward — adjust_motion remapped to WalkForward
// with speedMod *= -0.65f, so adjustedSpeed already
// carries the factor. But the motion arg we see
// here is the original (pre-adjust) 0x06, so we
// still use WalkAnimSpeed — the negative sign of
// adjustedSpeed flips the direction correctly.
yvel = WalkAnimSpeed * adjustedSpeed;
break;
case 0x07: // RunForward
yvel = RunAnimSpeed * adjustedSpeed;
break;
case 0x0F: // SideStepRight
xvel = SidestepAnimSpeed * adjustedSpeed;
break;
case 0x10: // SideStepLeft — remapped to SideStepRight with
// negated speed; same handling as backward walk.
xvel = SidestepAnimSpeed * adjustedSpeed;
break;
}
if (yvel != 0f || xvel != 0f)
CurrentVelocity = new Vector3(xvel, yvel, 0f);
}
}
// Retail locomotion constants — mirror of MotionInterpreter.RunAnimSpeed
// etc. Kept here to keep AnimationSequencer self-contained for the
// synthesize-velocity path above. Values decompiled from _DAT_007c96e0/e4/e8.
private const float WalkAnimSpeed = 3.12f;
private const float RunAnimSpeed = 4.0f;
private const float SidestepAnimSpeed = 1.25f;
/// <summary>
/// Scale every cyclic node's framerate by <paramref name="factor"/>, mirroring
/// ACE's <c>Sequence.multiply_cyclic_animation_framerate</c>