Our game has a custom loading screen between teleports. According to our poll results, around ~25% of people (around 10k ccu average) are sometimes or multiple times getting stuck during the teleport. They have said that they arent able to press escape to open the roblox menu at all, meaning it’s getting stuck somewhere during the internal teleport. We have checked error reports, but they havent given us much of an idea of the underlying problem.
Unfortunately, we don’t have enough information from your report to locate the cause of this issue.
Could you please provide more information, like the crash log or error reports you mentioned, a video or some other thing that would help us investigate? I tried to reproduce this issue within the experience myself but wasn’t able to.
If you need more info about which info/files might be useful for us and why, check the How to post a Bug Report.
Thanks for the response! I was hoping you would be able to see some internal details that we’re not able to see, but here are the error logs filtered with Teleport in them. They haven’t been of much help, though.
It’s a bit hard to reproduce since it’s inconsistent but players have reported that it has started happening after a couple of matches played. They will get stuck on the custom loading screen provided in the main post. For now though, we’ve disabled the custom loading screen in hope to get more information.
Sadly we don’t have any videos of it at the moment but I will be trying to get one. Is there anything else I could do to help you track it down?
I’ve been able to get 2 clips of the issue so far.
Code for the TeleportInitFailed event:
TeleportService.TeleportInitFailed:Connect(function(player, teleportResult, errorMessage, placeId, teleportOptions)
self._notificationService:Push(player, {
Duration = 15,
Message = "That's no good. We're going to try that again...",
})
if teleportResult == Enum.TeleportResult.Flooded then
task.wait(FLOOD_DELAY)
elseif teleportResult == Enum.TeleportResult.Failure then
task.wait(RETRY_DELAY)
else
-- if the teleport is invalid, report the error instead of retrying
warn(("Invalid teleport [%s]: %s"):format(teleportResult.Name, errorMessage))
self:_OnTeleportFailed(player)
return
end
self:_TrySafeTeleport(placeId, { player }, teleportOptions)
end)
Code for the _TrySafeTeleport method:
function TeleportServiceServer._TrySafeTeleport(self: Types.TeleportServiceServer, placeId: number, players: { Player }, options: TeleportOptions): boolean
local attemptIndex = 0
local success, result -- define pcall results outside of loop so results can be reported later on
repeat
success, result = pcall(function()
return TeleportService:TeleportAsync(placeId, players, options) -- teleport the user in a protected call to prevent erroring
end)
attemptIndex += 1
if not success then
task.wait(RETRY_DELAY)
end
until success or attemptIndex == ATTEMPT_LIMIT -- stop trying to teleport if call was successful, or if retry limit has been reached
if not success then
warn(result) -- print the failure reason to output
end
return success
end
All teleports are initiated using the _TrySafeTeleport method.
So there seems to be a few different issues going on here. Some of the bottom ones, such as Game 312 and 212, have to do with user authorization issues or connection issues. Those are bound to happen occasionally for high volume games.
We should focus on the top two most frequent issues as they are more specific to your game. The first one, “The previous teleport is in processing” could potentially be resolved by double checking Enum.TeleportResult.IsTeleporting before retrying the teleport.
The second most common issue, “raiseTeleportInitFailedEvent: Teleport failed because A Http error has occurred” could be a server issue. Could you provide the userId for the user who recorded those videos so that we could look into this further? I tried using your account’s userId but it doesn’t seem to be the correct one.
I can offer some information that I’ve noticed about teleports that failed when I was researching the issue some years back. It may or may not be relevant to your issue, but you never know.
If the player client freezes, no menu access, have to manually kill the app, etc. More than likely, their client ran out of RAM. I’ve seen it happen a lot more on mobile players because they have less device RAM to work with, but the only conclusion I’ve been about to make from my research is that the app RAM usage was not cleared before loading the teleport to the next area of the experience. I don’t believe this will create a log event that the teleport failed, since the destination experience does start a new server without any issues and it just waiting for the player to arrive, which they never do, which then triggers a closing of that game server with no players. But because the player did not “exit” the game in a proper sense (because of a direct crash), it’s possible your retry attempts then try to teleport a “zombie” player to a new server, which then might trigger a failed teleport. There is no easy way to test this, so it’s all just speculation on my part.
I’m not sure what the default timeout is, but Roblox does eventually disconnect a “crashed” player from the server, but I’ve seen it vary from several seconds to a full minute that the zombie player remains in the game frozen before they are finally kicked out.
About the closest thing you can do, which is what I did long ago in testing, was to have some type of system to record when a player stops “responding” to your game and record what happens in more detail after that point, like, did this happen right after a teleport, right before, in the middle of arriving at a new server, etc. You get a lot of data points this way, but it’s still difficult to say what is actually the cause short of guessing.
That all makes sense. Thanks for looking into the issue! I believe my userid hasn’t encountered that exact issue before, but here are the userids from the people in the last 2 clips in order:
The code is posted above. However, we switched to a global matchmaking solution that prevents us from needing to have an extra teleport. The issue seems to have resolved itself after implementing that. Maybe it had to do with too many consecutive teleports?
