User correctly called out: 'why workarounds? Nothing wrong with ACE,
our client is wrong.' Three of the four workarounds in B.6/B.7
(arrival margin, re-send-on-arrival, AP flush on arrival) exist
because our client sends 1Hz position heartbeat. Retail sent every
tick. ACE's CreateMoveToChain polls WithinUseRadius every ~0.1 s
using the latest Player.Location — at 1Hz we leave up to 1 s of
stale position data on the server, so ACE rejects re-sent actions
as still-out-of-range.
Fix: bump heartbeat to ~10 Hz when the body is actively moving
(auto-walk OR user pressing W/A/S/D). Idle still 1 Hz.
ACE sees us approach in near-real-time; server-side MoveToChain
converges normally; CreateMoveToChain's own callback fires the
action when in radius — no client-side re-send needed.
This SHOULD make the existing workarounds redundant:
* Arrival margin (0.2m) — can shrink toward 0 since position
drift is bounded by 100ms instead of 1s
* Re-send on arrival — ACE's chain completes on its own
* AP flush on arrival — included in normal heartbeat
Plan to retire them in a follow-up commit once we verify the
heartbeat bump alone is enough.
301281d8d0