CInstanceBase::SetMoveSpeed only guards moving_speed > 1100 -> 0; the local
player's set_server_speed() was additionally floor/ceil-clamping the scale to
an arbitrary [0.25, 3.0] band with no basis in the reference or in this
project's already-fixed remote-entity equivalent (EntityStore::motion_move_speed).
A heavy haste stack or slow debuff on the local player would silently diverge
from what everyone else sees. Removed the extra clamp; kept the moving_speed<=0
early-return guard against pre-spawn/malformed values.
audit: movement.keyboard.motion/server-speed-scale-clamp closed with reference
citation, regression test, and full related-suite pass; contract stays PARTIAL.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Investigated the prior round's flagged gap ("CanAct()'s Paralysis/Faint/Sleep
movement doors not wired into net_play.gd") via exhaustive reachability
tracing of the 40250 reference source. All three resolve to non-gaps:
- Paralysis: its only setter (__Shaman_SetParalysis, InstanceBaseEffect.cpp:821)
has zero callers anywhere in the reachable source -- dead code, never true
in live gameplay.
- Sleep: the AFFECT_SLEEP case in SetAffect() is commented out; the only live
setter is the AFFECT_STUN case (SetSleep(), InstanceBaseEffect.cpp:932-933),
i.e. IsSleep() is just an alias for AFFECT_STUN -- already covered by the
existing `stunned` field and _can_process_network_state()'s dead/stunned/
knock_down gate.
- Faint: only setter is chrFaintTest(), a debug-only Python binding operating
on GetSelectedInstancePtr(); unverifiable from the available 40250 checkout
(no root/ UI scripts) -- evidence-blocked, left unresolved per the skill's
reachability rule.
Byproduct finding while tracing IsStun(): main-character GC_STUN routes to
Die() in the reference (RecvStunPacket), not Stun(); verified this causes no
movement.keyboard.motion discrepancy since CanAct() blocks movement equally
on IsDead()/IsStun() and the current client already blocks movement equally
on dead/stunned. The Die()-vs-Stun() distinction only affects death-system
semantics, already tracked under combat.affect-status.md (Remaining #2, rows
63/67) -- not duplicated here.
No implementation code changed. Removed the resolved item from manifest.json
and movement.keyboard-motion.md's Remaining list; documented full evidence
in the contract doc and remediation roadmap. Contract stays PARTIAL
(AccumulationMovement root-motion, OnMove/OnMoving event-source parity,
sync/hit/death/warp gate stacking, and real-model bone-flip test remain open
for future rounds).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
40250 parity: CPythonPlayer::NEW_MoveToDirection's m_isCmrRot branch
continuously rolls the camera toward the held movement direction every
frame while a direction key is down, independent of whether a new
translation target was just set. Add _camera_auto_rotate() to replicate
this (forward/back = no rotation, strafe = max rate, diagonal = half
rate), called unconditionally after the frozen/locked/shop/emotion gate
in _process(). Godot's yaw-increase handedness is opposite the
reference's D3D Roll(), so the sign is flipped as a platform adaptation;
verified by convergence invariants in keyboard_motion_timeline_test.gd
rather than bit-for-bit angle matching.
Closes movement.keyboard.motion/camera-auto-follow-rotation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
