Are strings passed through this service null-terminated? Are there any other odd encoding quirks to worry about?
While waiting to be teleported, create a subscription on the server the player is in that will wait for the proper teleportation data (Place ID, Server ID, etc.)
Make sure to disconnect the subscription for when the player leaves the session, and after the player has been teleported (Shouldn’t affect the dedicated server, hopefully)
I assume all places, since there are limits for a universe as a whole. Although I have not tested this yet.
It’s also not possible to do Cross Server chat for EVERYONE to chat because of filtering restrictions. There is no current way using Chat or TextService that you can see if 2 players are allowed to chat because of their settings due to them having to be in the same server for this to work.
I also believe that matchmaking is something listed under the “Universe Scripts” on the roadmap. I can see Universe Scripts being more useful than this and I hope this isn’t the replacement of it and that the wait will be worth it
This is a great update. been wanting something like this for awhile
Why isn’t using FilterStringForBroadcast not an option?
You still have to make sure that the user you are showing the message to hasn’t blocked them or something preventing them from seeing the message normally.
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
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.
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.
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.