Yesterday, we released our V3.10 update in Emergency Hamburg, introducing reserved servers (Created by TeleportService:ReserveServer()) for console players on XBOX and PlayStation.
When initially creating the server, we save a matchmakingType in the reserved server data. Then, each time a private server is joined, we compare the current player’s server matchmakingType with the target server data matchmakingType. The player can only join if the matchmakingType matches, so we can separate the different player groups correctly and prevent the issue with multiple game servers starting up for the same reserved server id. A server therefore should never be able to start up with a game.MatchmakingType property which does not match the matchmakingType in the data.
But it happens. Our internal logging system received 1854 logs since yesterday, informing us that the private server data has matchmakingType=“Default” (indicating that with our game logic, it is only joinable for players on a default server and therefore with crossplay enabled), but has been started up as PlayStationOnly. In some rare cases, we also noticed it’s the other way around with matchmakingType in the server data being “PlayStationOnly” but the server was started up as Default. This issue impacts our game by causing multiple servers with the same private server id to start up, risking data loss or private server owners being unable to join their own servers.
I am extremely sure that this is an issue with Roblox and not with our ingame code because the issue only occurs to PlayStation Players and not to XBOX Players, and our game does not make any difference between them. That means that Roblox must be setting the MatchmakingType property somehow incorrectly for PlayStation players.
Possible Reproduction (not sure if it works 100% of the time):
Thanks for submitting a bug report. We did some testing to try to reproduce the issue, but were unable to. It seems like you disabled Private Servers on your experience as well, which means we couldn’t test directly with your experience’s code.
We tested using this test experience, where you can type /platform or /p to get the current MatchmakingType and /teleport or /tp to reserve the PlaceId and teleport to it again. The MatchmakingType always matched the user’s cross-play setting, so we were unable to figure out what’s going wrong in your experience.
I have a few questions that came up during the investigation, and it would be helpful if you could provide answers:
When initially creating the server, we save a matchmakingType in the reserved server data.
Does this mean each server is assigned a matchmakingType? For example, you have three servers, one for Default, XboxOnly, and PlayStationOnly?
Then, each time a private server is joined, we compare the current player’s server matchmakingType with the target server data matchmakingType. The player can only join if the matchmakingType matches, so we can separate the different player groups correctly and prevent the issue with multiple game servers starting up for the same reserved server id.
Let’s say a player’s server’s MatchmakingType doesn’t match the target server data’s MatchmakingType; how do you handle this case?
When are you making the server data check compared to when you write the log? I assume the same time?
A server therefore should never be able to start up with a game.MatchmakingType property which does not match the MatchmakingType in the data.
This doesn’t make sense to me because you began the case with “each time a private server is joined”. The player has already joined the private server, and the server has already spun up; they could have a matching or non-matching MatchmakingType to the reserved server data. Do you maybe mean when the player has joined a lobby/server explorer first and then try to connect to a reserved/private server?
How are you testing Xbox and PlayStation Private Servers on your experience? There’s no way to join Private Servers on Consoles besides through joining a friend. I assume it’s your code that teleports users but wanted to double check.
Thanks for taking the time to check this. I’ll try to explain the issue as much as I can.
The reason we have private servers disabled in our experience is that we use custom private servers using TeleportService:ReserveServer(). Players are teleported to these servers from normal public servers using our in-game code.
Yes, the private server data associated with the server contains the field matchmakingType. This field is set once when the player purchases the private server product and TeleportService:ReserveServer() has returned the PrivateServerId. It takes the PrivateServerId from it and creates the private server data, including the matchmakingType field. It is set to the MatchmakingType of the current server to match users cross-play settings.
I do not handle this case except for printing a log, simply because it should not happen. The only possible teleports to our private servers are done by my server code, and it compares the matchmakingType of the server to teleport to with the current servers matchmakingType every time. If it doesn’t match, the teleportation is blocked and the user receives a message.
Yes, I do the check when the private server data is loaded.
If for example joining a private server via a link (for example: Roblox) you can see that it first joins a “normal” public server before joining the private server. Joining a custom private server on Roblox is generally not possible directly, but must always be done via TeleportToPrivateServer. Therefore yes, this comparison of the matchmakingType of the private server data and the current DataModel is done before joining the private server. This is why I assume a custom private server should never start up with the wrong matchmaking type.
You can join reserved servers created by TeleportService:ReserveServer() through a friend??? Or do you refer to “normal” Roblox Private Servers? According to TeleportService | Documentation - Roblox Creator Hub, reserved servers can only be joined by using TeleportService:TeleportToPrivateServer(). If this joining through a friend would be possible, it would not match the described functionality from the documentation, allow players to join private servers without permission and, if the cross-play setting doesn’t match, cause the issues. Could you clarify which type of private server you meant with this? But yes, our code does the teleportations using TeleportToPrivateServer - as this is the only way according to the documentation.
Let me know if you have any follow-up questions!
~ Felix
As you suggested, I originally thought you were using “normal” Roblox private servers; thanks for explaining your use-case more in-depth. It helps narrow down what could be happening a lot.
This field is set once when the player purchases the private server product
Just to double check, what happens when a player makes a private server purchase on their Desktop and then tries to access the private server on their cross-play disabled PlayStation? Alternatively, what if a player sets cross-play to enabled after purchasing a private server with cross-play disabled? Do they get blocked in both cases because the MatchmakingType doesn’t match?
The Matchmaking team has found some edge cases where it is possible for a PS crossplay-enabled player to join a PS-only game. I assume this is not intended behavior, although one could argue that it should be allowed.
Thus, imagine this happening:
Player with cross-play enabled joins a PS-only game.
They buy a private server, which stores the MatchmakingType as PS-only
They then join the private server while in the PS-only game, which causes the server to be created as Default
This causes Server Data = “PSOnly” but started up server is “Default”
I have a hard time imagining how the reverse could happen though, because players on the “Default” servers shouldn’t be able to start up a “PSOnly” server. I asked for more info from Matchmaking but they haven’t responded. That said, the above case already breaks your use-case so we need to resolve that, of which I have been told the work will be non-trivial.
While they work on a fix, I have some ideas that may help mitigate the issue:
When a player purchases a private server, reserve a new server, teleport them to the server, and then write down the MatchmakingType from the server they teleport to. Hypothetically, this should accurately record the kind of MatchmakingType that the player will create from joining a private server. This should then mitigate the number of erroneous servers you get.
Alternatively, allow a player to join a reserved server from anywhere. By anywhere, I mean any platform / MatchmakingType. Then, once the reserved server has started up, lock it down to the MatchmakingType you get from that server (i.e. overwrite the MatchmakingType data for that reserved server). When all players leave the server, rewrite the MatchmakingType to a default state to allow a player to join from anywhere again.
Record if a reserved server instance already exists; if a player spins up a reserved server with a different MatchmakingType, teleport them back to a public server (basically, kick them out with a message). This might prevent most duplicate private servers issues retroactively if you kick the player out right when the server starts up so then the server shuts down immediately.
Sorry that these potential solutions all probably involve extra work for you. I was hoping that exposing the MatchmakingType would allow us to handle cross-play cases but it seems that some edge cases slipped through the cracks. Let me know your thoughts.
what happens when a player makes a private server purchase on their Desktop and then tries to access the private server on their cross-play disabled PlayStation?
Its the same as with all other joins to private servers where the crossplay type does not match: In both cases, they are blocked from joining their own server.
The Matchmaking team has found some edge cases where it is possible for a PS crossplay-enabled player to join a PS-only game. I assume this is not intended behavior, although one could argue that it should be allowed.
This is of course a big issue, because as you said it can cause servers to be classified incorrectly because the server the player is on does not represent their current matchmaking type. I cant imagine that is intended, as the MatchmakingType is called “PlayStationOnly” and not “PlayStation”. As there is no way to check the crossplay status of the individual player currently, i believe the matchmaking type on the game should be applicable to all players.
About your fixes:
Great Idea for the time while this is being fixed!
This could become an issue with more popular public servers - if an XBOXOnly player joins first, they would lock down the entire server for everyone else.
Already implemented that now with a session lock!
Thanks for your ideas, and let me know when these issues on PlayStation have been fixed.