[v2.1.0] MatchmakingService - ON HOLD

Resources Community Resources
#210

I believe that the players are teleported server-side, so it’s as safe against exploiters (at least as safe as possible).

Correct me if I’m wrong Steven!

Edit:
I’m wrong.

#211

I don’t think teleporting server-side makes a difference.

afaik teleporting server-side just asks the client to teleport, as there isn’t a way to change the client’s connection to connect to the other server.

The client still has full control over the teleport.

1 Like
#212

Yeah, pretty sure they can. But, again (I might be totally wrong here but) I think the exploiters would only be able to change their data. And if you want it to be secured, you could add some sort of if statement to check like

if teleportData[thingYouAreChecking] == yesThing then
    -- continue your code
else
    player:Kick("why do you even exist, touch some grass to help you stop hacking")
end

Again, not sure if it’s 100%

1 Like
#213

uxr0qb_122081
uxr0qb_1220811139×410 61.6 KB

With this method, the user can’t modify the data. I suppose they could insert data from a previous teleport, but there’s not really any sensitive data in the teleport. Just the game code and the rating type. There is custom data that can be sent with it, but the documentation says it can’t be modified. Inserting data isn’t really an issue because it wouldn’t get read anyways. Only specific data is read from the teleport.

Regardless, in the future I may switch to using memory stores for this, but it is a breaking change, and if I implement it, people will need to change how their games work, but for something like security it is worth it, I agree. The main concern I have is that I added support for custom teleport data, and I don’t want that getting spoofed. I didn’t even think about switching it to the memory stores when I added the custom teleport data, but that’s mainly because, at the time, memory stores had a max limit of 1kb, which is not a lot. I got them to raise the max to 32kb, so it should be less of an issue now.

Next major update, though, I will switch these to memory stores. Thank you for pointing that out.

2 Likes
#214

My team has been working on a game since August 2021 and we will be using MatchmakingService.

It’s a great singleton that looks quite simple to implement and is always updated.

1 Like
#215

Hey, I’ve a question. Is the MatchmakingService:AddGamePlace("Map name", placeIdYouCopied) necessary?

I mean we do have MatchmakingService:RemoveGame(gameId) which is necessary, so I’m confused.

Also, is the rating thing necessary, cuz I don’t know too much about this module (even after checking the documentation)…

#216

MatchmakingService:AddGamePlace("Map name", placeIdYouCopied) This is necessary to register maps so that you can queue players. MatchmakingService:RemoveGame(gameId) this is also necessary to prevent the game from sitting in memory. It should be noted that these are not the same at all. AddGamePlace registers a map into the servers that you use when queueing players/parties. RemoveGame takes a gameId, which is passed along with players when teleported to the game, so that you remove the game from memory after it’s over, it does not remove a map from being able to queue players to. Forgetting to remove it from memory will cause you to go over the memory limit eventually.

Rating is not necessary and you can disable it using the option in GetSingleton:

3r2fkm_122181
3r2fkm_122181804×563 38.3 KB

(i.e. MatchmakingService:GetSingleton({DisableRatingSystem=true}))

1 Like
#217

How can I do this within the lobby itself before it has started? FoundGame event is great, but I can’t find an event that fires for when the player’s match lobby has added players etc.

EDIT: It appears a lobby for a game is only created when it has found enough people to start?

#218

Yes, a game is only created once enough players queue to push it past the min amount of players. That doesn’t necessarily mean the game will start, but it does mean players will be teleported. You’re looking for an event that is fired when players join or leave a lobby?

(sorry for not responding, I didn’t get a notification about your post)

2 Likes
#219

This weekend I will be making an update to v2.0.0 to address this:

So, that means this is a breaking change. Remember, you can set your matchmakingservice to get a specific major version to prevent your game from breaking when these major changes are released. You can do this by adding options to GetSingleton here’s an example of how to always get v1:

local MatchmakingService = require(7567983240).GetSingleton({["MajorVersion"]="v1"})

If you have any suggestions that you believe will require a breaking change, leave them now so that I can put them into v2 along with this, otherwise this is the notice that a breaking change will be released on Monday, the 21st.

2 Likes
#220

Yeah, people can join and leave afterwards the lobby is found, especially if a teleportation delay is configured. That’s why I think perhaps there could be events to signal for those very things.

#221

Does the event need to work globally i.e. when some player joins a game does it need to fire on all servers using matchmaking service, or is it only needed for the main server?

You can send me a pm with more details on your use case.

1 Like
#222

Probably all the servers where people who are inside that lobby are in. (sorry for that extremely weird sentence)

Mainly because I would like to show who they’re going up against in real-time, I also saw someone else wanting this, so I believe I’m not alone.

#223

Can we talk more in pms? I don’t want to keep bumping the topic for this and it should be easier to detail.

#224

This module looks amazing! The hard work is amazing! Especially how easy it is , keep up the epic work! (just ignore the guy who was yelling about his game broken XD)

2 Likes
#225

Version 2 has been released! Because no features were brought up since I asked, this update mainly just includes the change from teleport data to another memory store for security purposes. Explained here

Version 2.0.0

Changes (breaking):

  • [Removal] Removed all teleport data.

  • [Addition] Added MatchmakingService:GetCurrentGameCode(). This will get the code of the current game, if it is a game server, nil otherwise.

  • [Addition] Added MatchmakingService:GetGameData(code). This replaces the teleport data for game data. This will include the game’s code, rating type and any custom data you apply with ApplyGeneralTeleportData. You can call this without code, if so MMS will use the use GetCurrentGameCode().

  • [Addition] Added MatchmakingService:GetUserDataId(player) (and MatchmakingService:GetUserData(player), accepts player rather than player id). This replaces teleport data for players. Use this to get any data you apply with ApplyCustomTeleportData.

  • [Change] RemoveGame(gameId) is now called automatically on game close and will no longer accept a gameId parameter. This shouldn’t be called anymore, as MMS will handle it for you.

Changes (non-breaking):

  • None

Fixes:

  • [Fix] Custom user data is now applied when teleporting to existing games.

Remember you can still obtain version 1 with local MatchmakingService = require(7567983240).GetSingleton({["MajorVersion"]="v1"}) so that you can choose when to update your games! However, version 1 will not receive any new updates.

5 Likes
#226

For v2.1, can we have the ability to set our own TeleportData? It would help with backward compatibility with Bloxy Kart’s existing Multiplayer system, and all we would need to do is add this into our game.

#227

You can still add custom data, it’s just been moved for security reasons:

https://steven4547466.github.io/MatchmakingService/maindocs/#applying-custom-teleport-data-to-players

https://steven4547466.github.io/MatchmakingService/maindocs/#applying-custom-teleport-data-to-the-game

This also goes over how to retrieve the data. Explanation to why teleport data may be insecure can be found here: [v2.0.3] MatchmakingService - #213 by steven4547466

With it being fully server sided, exploiters can’t modify the data at all (unless, of course, you’re calling a remote function when setting the data which I will say I don’t recommend).

1 Like
#228

Awesome update Steven! Thanks for everything :slight_smile:

#229

This is a bit late, but TeleportData can be made secure easily:

  • Obtain it with Player:GetJoinData()
  • Check if JoinData.SourceGameId == game.GameId
  • When creating the TeleportData on the origin server, add the current os.time() and check on the destination server if os.time() - JoinData.TeleportData.Created < 20

TeleportData is actually nicer to use sometimes, since it doesn’t consume memory.

3 Likes