You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when moving room objects with walk() or move() you are not actually moving the object immediately, but enqueueing it to be moved as soon as possible. Consecutively moving an object will eventually make it go out of sync with whatever is issuing the movement.
You can test this by moving a user back and forth between two tiles for some time. With the walk() function it will eventually stutter with no motion for a short period of time before catching up. This desync is even more notable when using move() and updating the directions of avatars manually; the avatar will start changing direction before it finished moving to its current destination (because changing the direction manually is not tied to the enqueued movement)
One way to try mitigate this is by calling clearMovement() before all walk() or move() calls. This helps the client get caught up to speed when tabbing out and back in after some time, but does not fix the desync problem as it does not clear out the currently ongoing movement animation.
One possible fix to this would be to make clearMovement() actually stop the current ongoing movement animation to allow for walk() and move() to execute immediately.
The best solution in my opinion would be to remove (or make optional) the enqueueing of movement animations for room objects entirely. When the server (or whatever is calling the move function) tells it to go somewhere, it should drop what it's currently doing and start animating to the new destination, from the previous destination (even if it didn't get there in time) immediately.
TLDR; walk() and move() on room objects should execute immediately rather than being enqueued
The text was updated successfully, but these errors were encountered:
I realize now that the reason this desync happened so often for me is because (from what I can tell) animating an avatar from one tile to another takes longer time in shroom than the flash clients. Changing room ticks from 500 to 530ms serverside makes consecutive avatar movements pretty smooth without desyncing for a long time.
Currently when moving room objects with walk() or move() you are not actually moving the object immediately, but enqueueing it to be moved as soon as possible. Consecutively moving an object will eventually make it go out of sync with whatever is issuing the movement.
You can test this by moving a user back and forth between two tiles for some time. With the walk() function it will eventually stutter with no motion for a short period of time before catching up. This desync is even more notable when using move() and updating the directions of avatars manually; the avatar will start changing direction before it finished moving to its current destination (because changing the direction manually is not tied to the enqueued movement)
One way to try mitigate this is by calling clearMovement() before all walk() or move() calls. This helps the client get caught up to speed when tabbing out and back in after some time, but does not fix the desync problem as it does not clear out the currently ongoing movement animation.
One possible fix to this would be to make clearMovement() actually stop the current ongoing movement animation to allow for walk() and move() to execute immediately.
The best solution in my opinion would be to remove (or make optional) the enqueueing of movement animations for room objects entirely. When the server (or whatever is calling the move function) tells it to go somewhere, it should drop what it's currently doing and start animating to the new destination, from the previous destination (even if it didn't get there in time) immediately.
TLDR; walk() and move() on room objects should execute immediately rather than being enqueued
The text was updated successfully, but these errors were encountered: