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
Sometimes, when a non-device (networked) player is falling, they appear to be falling in slow-motion and teleporting back up.
Determined to not be an issue with network updates (yellow = expected behaviour, red = issue noticed)
explored @jushg's theory, that differences in screen sizes causes foreign player entity to collide with local entities, such as clouds, which may be in different positions under absolute (x, y) positioning.
Switching to relative positioning can mitigate the issue, unlikely to solve due to loss of accuracy during conversion, as well as current plans to only resolve via scaling width. If this is something we can live with, that's okay.
Considered other possibilities:
Should player entities from other devices be affected by local device non-player entities?
Should player entities from other devices be affected by local device gravity?
An approach that looks like this also appears to fix the issue:
The text was updated successfully, but these errors were encountered:
As for other possibilities you mentioned, I believe that we should maintain the gravity (to make the UI smoother in case any one player is lagging). However, the player affect by other player should be changed, as it currently leads to a funny situation when a player standing on top of another player on a cloud is valid.
Sometimes, when a non-device (networked) player is falling, they appear to be falling in slow-motion and teleporting back up.
Determined to not be an issue with network updates (yellow = expected behaviour, red = issue noticed)
explored @jushg's theory, that differences in screen sizes causes foreign player entity to collide with local entities, such as clouds, which may be in different positions under absolute (x, y) positioning.
Switching to relative positioning can mitigate the issue, unlikely to solve due to loss of accuracy during conversion, as well as current plans to only resolve via scaling width. If this is something we can live with, that's okay.
Considered other possibilities:
An approach that looks like this also appears to fix the issue:
The text was updated successfully, but these errors were encountered: