Updates to Teleport sessions

I do not see any related errors in the documentation for this change, but TeleportAsync yields, so if your script continues to run after being yielded from a teleport, you should be able to check if that player is still in the place.

On there other hand, there is an event TeleportInitFailed, but I notice another event locked for corescripts that sounds related but may have always existed and will remained locked MenuTeleportAttempt


This is a horrible solution.

I was actually one of the people to report this exploit to @Exploit_Reports and even I believe that this solution will only cause more issues for developers that rely on players not getting teleported mid-round, the issue would have been solved much more easily by just keeping the leave game button available when teleporting. I would personally have to think about kicking players that attempt to break my game by yielding a teleport which is bad UX all around.

This decision feels like a rushed band-aid that does more harm than good, can you please reconsider this decision as by doing this you are quite literally downgrading the platform as a whole, all to simply ‘fix’ and exploit that wasn’t really a big problem to begin with, may I add that players could just close the Roblox application to get out of this ‘frozen’ state, and if that isn’t an option because you want players to not leave Roblox, simply make the X button on a teleport loading GUI appear much more quickly and make it also appear on custom teleport guis. Many experiences will not be able to update their games to account for this, I don’t care how many exploits this ‘fixes’, sacrificing the playability of any competitive game that uses teleports is just plain-out a bad idea.

Please revert this update it is quite literally the most game-breaking update added to Roblox ever

How about you just keep the report menu open as a pop-up after a teleport?


Thanks for sharing your feedback. For the matchmaking use case, would the following solves your problem: an option in TeleportAsync that allow the API to immediate error out when a user has their menu open?


“There are no actions needed from you or your users.”

I develop an experience that has matchmaking and I can tell you that there absolutely will be action needed from me and my users, especially when the thread is entirely vague on party-based teleports and what this update is attempting to resolve (i.e. the discrepancy between member of a group teleport who has a menu open and others who don’t).

I do handle the edge case of a player potentially not teleporting with the rest of the party or disconnecting suddenly so it’s not a huge detriment technically but gameplay wise it is. When a round starts, a player who teleports in late can end up affecting the revive points of the whole party by spawning in. They may also miss vital starting gameplay and cutscenes. This is bad for UX as we heavily encourage party play and going through the missions together.



If I’m teleporting 30 players into a match, one single player having their menu open shouldn’t error out or delay the function returning. Can this be done in the background so TeleportService:TeleportAsync can return without waiting for users to close their menu?

This is a major breaking change if I’m understanding it correctly.


Thanks for letting me know, I honestly thought TeleportAsync wouldn’t yield until the player finished teleporting, but if this is the case then I can check if the player is parented to nil when the coroutine resumes again.

I see now this new feature as an issue instead of solving anything, mainly because it will indeed have developers do some work around their scripts if they have an issue like mine or as the people are mentioning matchmaking.


Are you teleporting all 30 users in a single TeleportAsync call? And your match can still start even if some users couldn’t make it?

1 Like

This is fantastic news. I see Roblox experiences as a bit akin to websites; I’m of the mindset that players should have ultimate control over when and where they teleport. If I wish to block redirects on my browser, I should be able to do that. Unannounced, unprompted, forced teleports–especially to experiences outside of the same universe, are almost always terrible for players. These teleports aren’t always reliable, and may occasionally take exceptional loading time. Players (most certainly players with data or connectivity concerns) should be able to choose whether they’re willing to commit to the process of shifting servers. It would be nice if more developers would share this outlook.

1 Like

Yes, TeleportService is not reliable, so it’s expected that not all players can teleport and the match can still start, but it’s also expected that the request will return relatively quickly (never more than a minute), having teleported all players it was able to or erroring.

It’s typical to teleport all players together.


This is far from the truth, games like Doors silently use teleports to get you into sub-places. Teleports are almost always user-activated (pressing a button, etc) and otherwise are usually required for the game to function. This new update practically breaks any competitive games since a user can in-theory join the experience 5 minutes late. Also, this update does not allow users to see a prompt of where they are going to get teleported to, so there’ll be unsolicited teleports for anyone not currently with their core GUI open.


I’m aware, and I agree that this particular implementation is most certainly problematic. I merely believe it to be a step in the right direction (to give players the assurance that they won’t be teleported without their consent.)

Make no mistake, I’m not advocating for the Roblox equivalent of cookie banners, but there isn’t an obvious solution to guaranteeing that these teleport ‘requests’ are being properly implemented with respect to user intent. At the very least, giving players an optional toggle to manually approve teleports, would be more than welcome for users such as myself.

1 Like

:red_circle: Another question, what would happen to those players that have the main menu opened while servers shut down and this game teleports players to another place in the meantime? Will they just get kicked out?

Yep, I don’t like this update. Currently, when servers shut down I teleport players back to the lobby, I believe those with the menu opened will be kicked out and is a player I lose if they don’t join back.

:green_circle: What about some temporary data getting saved on the client, like with the example of reporting, you guys could make it so that when they join the next place they are able to continue their draft.


Shouldn’t this only affect client sided teleports if the main concern here is reporting detection?

1 Like

That’d be a good start to have for sure. The other option I thought of is that it’d be a better experience if you instead told the player they are about to be teleported, and gave them a 5 second window to cancel the teleport & continue their report on the dialogue. This means the players eventually get teleported if they don’t act on the dialogue, and they have a chance to report if they want to. Seems like a best of both world’s option to me. Any issues with that option?


Effectively this will break soft shutdowns if a user has a menu open, effectively requiring a cooldown ‘kick’ to ensure the server shuts down as intended. If you kick a user while the experience menu is open; the user cannot continue interacting with the experience menu.

EDIT: You can ensure a server shutdown, however it would still prevent further usage of the experience menu based on how it currently operates.


Lots of games depend on matchmaking and expect all users to spawn in a match at the same time.

Imagine if Player A decided to keep their menu open for 4 minutes (purposefully or not) and then they closed it. They would be teleported to the same server that everyone else had already been playing in for 4 minutes.

This may give unfair advantages, as someone could intentionally join later to “hide” from other players so they could join later into a round with a fresh start when everyone is already exhausting their resources.


This change introduces annoying edge cases in a system I wrote just last week. Without going into the nuance problems, the general gist of the system is that parties are used in my games to keep groups of players together in universes.

I imagine this change also severely impacts Match Making systems in more competitive games.

This change doesn’t seem very thought out & appears to be a dramatic solution to a rather tame exploiting problem.


A game that requires all players to be loaded would be problematic. If a nuisance decides to delay everybody’s time and intentionally open the menu when the user is teleporting. This may cause loss of player.

I’m sorry, but just no.

Developers must HAVE FULL CONTROL of their games AT ALL TIMES. It’s not up to the player to decide. If a player doesn’t like it, then they can leave, and I doubt anyone would even care.

There’s absolutely no reason why players should have control over what developers want to make in their games. As a developer, if you want a system where players can stop teleports, you can add a button yourself.


Think of it this way; when a developer triggers a teleport request, they’re effectively asking the client to comply. A malicious exploiter, bent on breaking the experience, is already capable of declining (or perhaps worse, stalling). As such, developers should not be operating on the assumption that teleports are enforced to begin with. For cases where it’s necessary, if developers are unable to implement a timeout, then I would consider that to be the real issue here.

Given this context, I’m of the opinion that much of this doom calling is a bit unprecedented. When taking a moment to consider the matter thoroughly, I think it can be appreciated how little these changes actually impact developer freedom. Simply put, developers aren’t giving anything up here. No one can force the client to join a new server on the developer’s schedule; the potential for these requests to stall, has always posed a concern. Now, with this update, the issue has merely been brought to light. This, quite frankly, is a very good thing–as its now elevated attention, should encourage more intelligent design (both from developers, as well as from Roblox in the form of API changes).

1 Like