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

fix(anim): Phase K live-test fixes pt5 — backward + strafe animation cycle scales with Run

Browse source 
User report: when running backward (X) or strafing (Z/C) at run
speed, the visual moves faster but the animation cycle continues
playing at walk pace, looking disjointed.

Root cause: GameWindow's player-anim driver fed the sequencer's
SetCycle speed from result.ForwardSpeed, but PlayerMovementController
intentionally pins ForwardSpeed = 1.0 for WalkBackward (ACE expects
this for the auto-upgrade) and SidestepSpeed isn't used by the anim
path at all. So Forward+Run played the RunForward cycle at runRate ×
(correct), but Backward+Run + Strafe+Run used speedMod = 1.0 even
though the body was moving at runRate × velocity.

Fix: split the visual-pacing field from the wire-correctness field.
Added MovementResult.LocalAnimationSpeed — runRate when any
directional input is held with Run, else 1.0. GameWindow's
SetCycle path now uses this instead of ForwardSpeed. The wire
output stays unchanged; only the local animation cycle pace
shifts.

Effect:
  - Forward+Run:  runRate × cycle pace (unchanged behavior).
  - Backward+Run: runRate × cycle pace (was 1×; now matches
                  velocity).
  - Strafe+Run:   runRate × cycle pace (was 1×; now matches
                  velocity).
  - Anything not in Run: 1× (unchanged).

Tests stay 1222 green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik 2026-04-26 14:59:35 +02:00
parent 7d2bc8cb15
commit 0ecd4f34ae
2 changed files with 36 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

27
src/AcDream.App/Rendering/GameWindow.cs
View file

@ -4726,7 +4726,12 @@ public sealed class GameWindow : IDisposable
// command is unchanged but speed changed, we must still propagate
// so the sequencer can MultiplyCyclicFramerate — keeping the run
// loop smooth without restart.
float newSpeed = result.ForwardSpeed ?? 1f;
// K-fix5 (2026-04-26): use LocalAnimationSpeed (cycle pace) NOT
// ForwardSpeed (wire field) — backward+run + strafe+run keep
// ForwardSpeed/SidestepSpeed at 1.0 for ACE compatibility but
// need the local cycle to play at runRate × so the animation
// matches the actual movement velocity.
float newSpeed = result.LocalAnimationSpeed;
bool sameCmd = animCommand == _playerCurrentAnimCommand;
bool sameSpeed = MathF.Abs(newSpeed - _playerCurrentAnimSpeed) < 1e-3f;
if (sameCmd && sameSpeed) return;
@ -4781,19 +4786,19 @@ public sealed class GameWindow : IDisposable
// Sequencer path: SetCycle handles adjust_motion internally
// (TurnLeft→TurnRight with negative speed, etc.)
//
// Speed scaling: use the MovementResult's ForwardSpeed for
// locomotion cycles. This mirrors what the server broadcasts for
// remote observers, and keeps our own character's animation rate
// in sync with movement velocity (a 1.5× RunRate player's anim
// plays 1.5× as fast — matching retail).
// Speed scaling: K-fix5 (2026-04-26) — use LocalAnimationSpeed
// (the PlayerMovementController-computed cycle pace) instead of
// the wire ForwardSpeed. Forward+Run = runRate; Backward+Run =
// runRate (where ForwardSpeed is the ACE-compatible 1.0);
// Strafe+Run = runRate (where SidestepSpeed is 1.0). Anything
// not in run = 1.0. The animation cycle now visually matches
// the movement velocity in every direction.
if (ae.Sequencer is not null)
{
uint fullStyle = 0x80000000u | (uint)NonCombatStance;
float animSpeed = 1f;
if (result.ForwardSpeed is { } fs && fs > 0f)
{
animSpeed = fs;
}
float animSpeed = result.LocalAnimationSpeed > 0f
? result.LocalAnimationSpeed
: 1f;
// ACDREAM_ANIM_SPEED_SCALE: optional visual-pacing knob. Retail's
// animation framerate scales linearly with speedMod (r03 §8.3),
// and our speedMod = runRate. If the visual feel doesn't match