Yeah, the thing is - it kind of pauses for a moment because the delay is different for different folks, so what it *tries* to do is: Store the player color Change the player (teleporting player) color to transparent Move the token to the GM layer Move the token to the new location (given by the teleport target) Move the token to the Token layer (if it didn't do this, you'd see the the token animate point to point on the token layer, kind of ruins the effect) Pings the player. The player that gets pinged is the one that controls the token. So we've seen hiccups when tokens are controlled by more than one player, or where more than one token is moved (for instance, if a player has a player token and a mook/other token, them being moved to the new page means somebody gets left behind - that's a future add to "bring all associated tokens" - when, you know, I have the time...) This ping should re-center the player view on the new token location. The player's color is reset to the original color. If there is a bug, hiccup or dropped script you can see: Player's color is not reset and is left transparent Player does not move with ping (this can happen if there is a substantial delay or other abort condition) Player is left on the GM layer I'm not sure if it's the timeout, or another bug - the teleporter I tried to make as bulletproof as I could. And by "bulletproof," I mean I made it to swallow all of its own errors, and not crash the sandbox. I don't like when that happens myself, so I figured my buggy code would be better off failing silently than crashing the sandbox mid-session. I apologize I didn't make it easier to debug problems. =============== Edited to Add ============= It looks like a few scripts that ping have all started having problems as of the Dec 21 update which included: Miscellaneous optimizations of VTT performance So I wonder if one of those miscellaneous performance improvements, or the "smoother dragging through doors" might have affected the way we use Ping.
