I have done this and it errored out.
That’s very strange and undocumented behavior. Why would you give the function UserId parameters if they have to be in the server anyway? This should either be changed in the documention or fixed if it is not needed. Apologies.
Are there an unlimited number of topics we can have? JobIds are unique for every server.
Wonder if i can use this to have an in-game Serverlist, to make it easier for players to pick a specific server to join if the game has a main menu.
No, but is there necessarily a reason for you to keep track of all JobIds?
Unless you are doing something I am not understanding you will just need to send the user the JobId through the Message, not the topic
Each server needs to subscribe to their JobId topic for them to get the message to teleport that servers player in the queue to the new ReservedServer.
Not Necessarily, Just name the Topic something like… [player.Name … “TpData”], so the matchmaking server can call that when it is ready to teleport that player. Then disconnect that Topic after it has been called properly
I suggest adding in a party system so players can be in a party together and teleport to places with their friends, could increase player retention and decrease the stress brought onto the matckmaking server.
Wow, great addition! Can’t wait to use this!
My overview of MessagingService Beta Release
Use Cases
Great for server-wide shutdowns, custom matchmaking (across servers), cross server partys (especially nice), game-wide shouts, game-wide crate announcements. I’ve been waiting for this for so long. Definitely a ton of possibilities and cool game mechanics.
Problems
The 10,000 subscriptions per game universe is a problem, especially if using multiple topics for data. This could be worked around by sending all data through one subscription, but that might reach the 1kB limit. Hopefully this will be removed / improved when released. The documentation’s formatting needs to be fixed, but this was already noted and should hopefully be fixed soon.
Summary
Overall, this beta release has many cool possibilities, but a few problems that will hopefully be dealt with before release. However, I do believe the possibilities overcome the problems, and hope to see tons of cool concepts with MessagingService.
Just preference, but would recommend using userId as it’s shorter and stays the same if a player changes their name. Yes, I know it’s temporary, but just in case.
Now I can stop completely clogging HTTPService and setting up these bulky systems, thank you for this!
Since this variable is only used in the time between the player sending the request to be put in a server, and the player actually getting teleported, I don’t think it is possible for the player to change their name.
I also don’t think this would reach the max topic lengths regardless. Although I suppose it is just Personal Preference.
The timing for this feature could NOT have been any better. Thank you so much!
Holy documentation Batman
Apparently SubscribeAsync returns a table like said above somewhere, with Data being what was sent (JSONEncoded string in my case) and Sent being the os.time() of the sent/received message?
I am currently working on my Matchmaking System (Will be public once it is finished)
Did you send the ‘Data’ Variable and the ‘Sent’ Variable or was the ‘Sent’ Variable added on and ‘Data’ being what you initially sent?
Ok, can confirm, this can be used for cross server matchmaking. Just need to polish this up a bit and it should be golden! (Video cuts out at the end as I was teleported to the ReservedServer!)
External MediaGlad to see it worked out for you!
Hopefully I can help you out with stuff like this later on in the future!
inb4 New forum created INSIDE a RBX game.
Amazing, can’t wait to try new possibilities!
Yea I mentioned that a few hours ago. Not wanting to berate the person writing the wiki as it does take a lot of writing, but it should proofread before published.