Warp Bug

[vilarion]

I have now logged the warp bug in the server.

[0x10] <-- requests to move north with NORMALMOVE
[0xDF] --> moves to (359, 875, 0) with NORMALMOVE
[0xBD] --> was moved to (359, 878, 1)
[0x10] <-- requests to move northwest with NORMALMOVE
[0xDF] --> moves to (358, 877, 1) with NORMALMOVE

• The client asks for two moves
• First one is onto a warp, which gets handled and sent back
• Second one is just away from the warp destination
• It also gets handled and sent back
• That is where the client freezes up

This cannot be reproduced on demand, you have to walk on warps until you get the freeze.

[Asyxian]

I found a possible cause in the movement state handling that could explain the reported sequence.
Incomplete movement reset during a warp
Movement.executeServerLocation() resets stepInProgress and calls animator.cancelAll().
However, MoveAnimator.cancelAll() clears the task queue and stops the animation without clearing uncomfirmedMoveTask or confirmedMoveTask. A cancelled task can therefore remain referenced even though it is no longer queued for execution.
Possible sequence

1. The client schedules the first predicted step to (359, 875, 0).
2. The server confirms it before the render update executes the corresponding task.
3. The warp to (359, 878, 1) clears the queue, but the references to the unexecuted task survive.
4. The client requests the second step. Movement.updateImpl() sets stepInProgress = true and sends the request.
5. No predicted movement is scheduled for this step. This can happen if getMovementDuration() returns -1, for example because the destination tile is not available locally. See scheduleEarlyMove() and getMovementDuration().
6. The server confirms the step to (358, 877, 1). MoveAnimator.confirmMove() still finds the old, unexecuted uncomfirmedMoveTask and only updates confirmedMoveTask. It does not enqueue a replacement or report readiness for another step.
7. No movement animation starts, and stepInProgress remains true. Subsequent updates return immediately at the step-in-progress check.
   This explains a movement lockup. It does not establish that the entire UI freezes, or that these exact timing conditions occurred in the original report.
   Possible changes

• Make warp cancellation reset the complete movement state, including both task references and the animation/readiness flags. Take care with ordering: stopping an animation can invoke callbacks synchronously.
• Serialize warp handling with movement confirmations. Currently, executeServerRespMove() submits work to the movement executor, whereas executeServerLocation() modifies the state immediately. Queued work from before the warp must not subsequently restore obsolete state.
• Make confirmation handling recover when the referenced prediction is neither queued nor executing, rather than attaching the confirmation to an orphaned task.
• Add regression coverage for a warp before a predicted animation starts, followed by a confirmed step without a local prediction, as well as cancellation during an active animation.