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
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.
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?
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.
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.
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.
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?
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).
Sigh⌠Roblox did good updates this month and than they come up with this? Imagine in a matchmaking game someone opens the Roblox menu to go away from their keyboard to get something to eat or something and than 5 minutes later they finally teleport. Disappointing to say the least. I know this is trying to prevent exploits but this actually makes it worse. I would rather not be undesirably be interrupted since that quote is so wrong. Itâs the opposite.
No offense whatsoever to what I said above. But I donât like this update. More could be improved. Upon feedback.