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
{{ message }}
This repository has been archived by the owner on Jan 11, 2018. It is now read-only.
working on the lobby system, teleporting players back, i encountered the problem of the code being too fast, porting the player back twice or three times in a row. such functions concerning boundaries need to have a check when they were ran last, so this does not happen
The text was updated successfully, but these errors were encountered:
best would be to actually have a detached thread that actually waits for the successful teleportation or timeout and block further teleporting for that player until either happens
perhaps all issued commands should work like that, threaded and self-checking
This is going to be bigger. I'm thinking a is_teleport_valid, which searches through a teleport history to check if all criteria meet, denying the request if they don't.
will be exposed after a teleport. so we could use that to see if the player actually arrived.
So initiate teleport, block teleports for player until that line shows up or a timeout occurs, then alllow teleports again.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
working on the lobby system, teleporting players back, i encountered the problem of the code being too fast, porting the player back twice or three times in a row. such functions concerning boundaries need to have a check when they were ran last, so this does not happen
The text was updated successfully, but these errors were encountered: