To prevent exploiting cases, we are pausing Teleport sessions when the Roblox app menu is open, and automatically resuming them once the menu is closed. There are no actions needed from you or your users.
Currently, Teleport can be requested at any time, and if a user is in the middle of some action, it will be interrupted by a Teleport. For example, if a user is using an experience menu to report inappropriate content or behavior, a requested Teleport will interrupt that activity, effectively preventing the report from filing and all the user-filled content will be lost.
To make the user experience more smooth and prevent undesired interruptions, we are making the following changes:
Teleport requests started after the experience menu is opened will now be put on hold while the menu is kept open and will be resumed once the menu is closed.
The user will be informed about the paused Teleport, so they can close the menu if they want to be teleported without further delays (e.g. to join the next level with their groups of friends).
A teleport call made while the menu is open will only wait paused for 5 minutes, it will be cancelled after that if the menu continues to remain open.
This seems like a nuisance of a behaviour for the majority of players, whilst only being marginally beneficial for a small minority of players. For games with matchmaking, itâs not uncommon for users on desktop to tab out whilst waiting, and those users are going to be stuck & delaying the teleport, potentially slowing down the match in the new instance from starting. I think that this behaviour should be reserved purely for the report screen, or there should be different behaviour when it comes to delaying the teleport â potentially cancelling it would be better⌠Not convinced this is the right solution to the problem.
I have not tested this at all yet, but in theory, it should not. TeleportAsync is an asynchronous function meaning other code will continue to execute without waiting for TeleportAsync to finish and return a result.
Yes, I am asking if it will yield until all paused requests are completed. If that were true, this would be a major change that would seriously impact games with matchmaking.
It seems implied that it would, but itâs such a breaking change and the post says this. Maybe it means that only calls on the client to other teleporting functions will be delayed for up to 5 minutes?
I understand some players might not wait 5 minutes inside my game lobby, but please clarify this to me since I am kinda confused about it.
Currently, my game lobby shows a loading screen while they are being teleported and removes all other UI, if it fails it pops everything back. (If it gets canceled and not even triggers with an error of teleportation, the loading will be stuck)
Does this mean that if the player is just in the menu while we requested the player to teleport, this teleport action will be canceled and the player will not be teleported after passing those 5 minutes?
If âyesâ is the answer, is there any event that would trigger when this cancellation happens? I probably misunderstood the entire post, not sureâŚ
I think this should be more customizable, like after how long it will force teleport them, on what in the menu (player list, report, etc.), and if this applies to their experience.
I think a better solution would be to move the important menus (e.g. reporting) outside of the context of a specific game session, so that developers can rely on teleports occuring immediately without having to deal with weird edge cases from players keeping menus open and potentially avoiding teleport altogether.
Like, just keep the report menu open no matter how many teleports happen and when? This seems much more robust. I understand it may be difficult from a technical perspective, but as far as I can tell itâs a much better design decision.
You say the motivation is to prevent exploits, but this kind of behaviour is exactly the sort of thing that could enable different kinds of exploits or bugs in specific games where the developers did not handle and test these situations properly.
Will there be any new API associated with this new menu behavior?
This would be useful for developers. A couple examples off the top of my head, if the menu is open for 5 minutes, we could prompt a new UI to teleport back to the lobby. Or if the menu is closed, we could play a sound effect so players close the menu. Or for match making, if a player has the menu open for X amount of time, we could choose a different player from the queue.
Iâm mostly fine with these sorts of updates, as long as developers are equipped with tools to develop their games around them
âAsyncâ in the Roblox API sense means that the function will yield, for instance, HttpService:GetAsync or GlobalDataStore:SetAsync, unlike the meaning of âasyncâ in other languages or in fact conventional meaning of asyncronous.
ETA: I cannot confirm nor deny (and am unwilling to test at this time) if this affects code execution at all, let alone server execution. I presume OP will be willing to answer this and the other questions asked here to clarify.
In this case, then the update being pushed here is quite concerning because any user can now yield server execution of code for up to 5 minutes unexpectedly.
That wouldnât solve the issue of someone opening the menu after they have been queued and are actively in the process of being teleported. In theory, someone could teleport into a BedWars round 5 minutes into it now. Although there are ways to solve this, developers shouldnât have to rework parts of their games because Roblox ignores the need for backward compatibility in updates and changes.
Currently, my game lobby shows a loading screen while they are being teleported and removes all other UI, if it fails it pops everything back. (If it gets canceled and not even triggers with an error of teleportation, the loading will be stuck)
If âyesâ is the answer, is there any event that would trigger when this cancellation happens? I probably misunderstood the entire post, not sureâŚ