If progress == Distance, we must not move again on the same tick,
but still 'return true' to avoid losing a tick in the case
when this is the last Move tick followed by a different activity
(or a new queued Move, for example via waypoints).
There were 2 issues at work here, both when progress
would overshoot Distance (which is the usual case,
rather than the exception):
- the overshot progress was passed on by MoveFirstHalf, however
OnComplete would make the next MovePart start ticking the
same tick on which the old MovePart reached Distance,
but move by carryoverProgress +(!!!) terrain speed instead of moving
by just the left-over carryoverProgress.
- MoveSecondHalf would not pass any overshot progress to the
next MoveFirstHalf queued by parent Move, leading to
the next MoveFirstHalf performing a full-speed move the same tick
MoveSecondHalf finished its last move.
InnerActivity and UpdateCenterLocation made this
overly complex and hard to read & debug.
This also fixes a bug that would make an outdated
facing being passed during OnComplete (because
InnerActivity was cached before UpdateCenterLocation
could set the correct final facing).
While they may be only 'visual' in terms of influence/cell grid,
they all do update CenterPosition, which is essentially the
actual world position of the actor.
'Visual' would imply that it only affects the position where the
actor is drawn, which is inaccurate.
Furthermore, using the term 'Visual' here would make
naming future methods/properties related to visual interpolation
unnecessarily complicated, because that's where we might
need a real 'Visual(Only)Position'.
While individual trait look-ups may be cheap,
if a large army that is currently standing still gets
its first move-including order, the look-ups of dozens
or even hundreds of actors may happen on the same tick.
Therefore this may help reducing that first-order lag spike,
at least a little bit.
