MessagingService Release

Are strings passed through this service null-terminated? Are there any other odd encoding quirks to worry about?

5 Likes

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)

2 Likes

I assume all places, since there are limits for a universe as a whole. Although I have not tested this yet.

3 Likes

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. :confused:

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

14 Likes

This is a great update. been wanting something like this for awhile :smiley:

1 Like

Why isn’t using FilterStringForBroadcast not an option?

5 Likes

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.

3 Likes

This is not correct. You can use FilterStringAsync (the TextService version) and CanUsersChatAsync, all you need is the UserId of both of the players.

5 Likes

I have done this and it errored out.error

13 Likes

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.

8 Likes

Are there an unlimited number of topics we can have? JobIds are unique for every server.

4 Likes

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. :thinking:

1 Like

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

1 Like

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.

3 Likes

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.

5 Likes

Wow, great addition! Can’t wait to use this!

3 Likes

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.

8 Likes

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.

2 Likes

Now I can stop completely clogging HTTPService and setting up these bulky systems, thank you for this!

7 Likes

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.

3 Likes