We’re thrilled to let you know that teleport error handling has been improved significantly with a recent update! TeleportInitFailed is an event that can be used to catch and handle teleport failures. Previously TeleportInitFailed did not tell developers which invocation it came from and relied on the developer to track the player’s destination. Now developers can directly retry the teleport using TeleportInitFailed’s new additional parameters.
New Parameters
placeId - The target place ID of the original teleport.
teleportOptions - A TeleportOptions object that can be passed back to TeleportAsync to retry the failed teleport.
This example retries failed teleports that are one-time hiccups and drops ones that are potentially invalid:
local Players = game:GetService("Players")
local TeleportService = game:GetService("TeleportService")
local function handleFailedTeleport(player, teleportResult, errorMessage, targetPlaceId, teleportOptions)
if teleportResult == Enum.TeleportResult.Flooded or teleportResult == Enum.TeleportResult.Failure then
-- pause and retry if it's a one-time hiccup
task.wait(2)
-- teleportOptions automatically have the reservedServerCode filled up
TeleportService:TeleportAsync(targetPlaceId, {player}, teleportOptions)
else
-- throw an error if something else is wrong
error(("Invalid teleport [%s]: %s"):format(teleportResult.Name, errorMessage))
end
end
TeleportService.TeleportInitFailed:Connect(handleFailedTeleport)
-- teleport all players to a reserved server
local teleportOptions = Instance.new("TeleportOptions")
teleportOptions.ShouldReserveServer = true
TeleportService:TeleportAsync(game.PlaceId, Players:GetPlayers(), teleportOptions)
Please note the sample code above excludes some error handling for simplicity purpose. For a more in-depth example of proper error handling, see this example.
In addition to the API improvement, the teleport documentation has been revamped with more up-to-date information and best practices. Check it out here!
We hope you enjoy this update! Please let us know if you have any feedback.
Happy programming,
The Roblox Creator Services Team
Thanks for paying attention to TeleportInitFailed and giving us more options! Teleporting is a very vital part of my current project so I’m always glad to see improvements to the technical experience.
Could we be allowed to disable the teleport notification to enhance the TeleportInitFailed usage experience sometime? Right now, systems built around TeleportInitFailed are mostly moot because of that notification.
As I mention in the motivation of that feature request, teleport failures are not uncommon for experiences heavily reliant on them. Rejoining after a failed teleport has become part of ingrained Roblox player culture because of how often some developers do not implement retry logic and instead tell the player to rejoin. The notification is dangerous as a player may take that as a cue to exit and not all players will rejoin immediately especially if it takes some time to get to actual gameplay.
We as developers should be able to convey our own information about how we’re handling a failed teleport through a custom notification of sorts like what we can do with paused gameplay for streaming. This can also interface with our own UI and allow us to improve the user experience for failed teleports.
I second this; if a teleport fails and you want it to retry in the background wouldn’t it be weird to have the “Teleport Failed” notification while it’s retrying? Shouldn’t you get an option to not make it appear and make your own notification saying “Retrying” or “Joining”?
Does using this prevent the “teleport failed” popup window to show? It’d be great if we could disable that and silently handle teleportation errors without the player being notified. Either because we want to keep it silent or because we want to implement our own UI to handle this.
Thanks for these improvements, error handling was always a pain point of TeleportService so this will be a real benefit!
Are we likely to see an improvement too to the current group limit of 50 players?
Many royale games would benefit from this, such as Squid Game which frequently sees over 10,000 concurrent players, and for example an elimination-showdown we’re working on which starts with 100 players and ends with 1.
Currently teleporting 51+ players requires multiple calls of TeleportService. This just makes the processing, transfer of data, and error handling of these teleportations unnecessarily cluttered and complicated.
Roblox can now comfortably handle 100-200 player servers which is a massive step-up to when this was first released a few years ago; it’d be great to see this updated too.
High player, sociable environments, are some of the greatest driving factors behind engagement and player retention making a feature like this all the more important.
I started getting reports of players failing to load into my game around the time this was announced, I experienced it myself and noticed this in the client console (they server console won’t display anything, weirdly):
Is this related? note: my game doesn’t use any TeleportService API.
It seems the event documentation code sample spells ‘Failure’ wrong, which throws an error, also the code sample doesn’t make use of the new parameters and still relies on a predefined placeId parameter.
I have tried implementing a similar script to this but it seems like the retry system is throwing an error that the teleport failed because the previous teleport is still processing even though it has already failed.
There’s no need to impose a small, arbitrary 50 player limit when Roblox can already handle significantly more. No one’s saying it’s impossible, it just makes error handling unnecessarily more complicated.
@jjoke_jkl@AbstractAlex Yes, you should be wrapping all teleports in a pcall - that was excluded from this example for the sake of simplicity. The Teleporting Between Places article has a code sample that’s much more fleshed out.
Please let me know if you run into errors with the article’s code sample as well.
