Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enqueueing animations for room objects are problematic #122

Closed
sindreslungaard opened this issue Feb 2, 2021 · 2 comments · Fixed by #125
Closed

Enqueueing animations for room objects are problematic #122

sindreslungaard opened this issue Feb 2, 2021 · 2 comments · Fixed by #125
Milestone

Comments

@sindreslungaard
Copy link
Contributor

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

@sindreslungaard
Copy link
Contributor Author

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.

@jankuss
Copy link
Owner

jankuss commented Feb 3, 2021

I think it would be good to remove the enqueueing aswell. It seems to create more problems than it solves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants