MessagingService additions and changes

Feature Requests Engine Features
#1
  • As a Roblox developer, it is currently impossible to maintain a real time “party” system across server without using some methods from the bulky DataStore/HttpService and techniques like long polling, which is kind of hacky.

Adding MessagingService:GetAsync()

For example, someone sends a message to another player using MessagingService, from one server to the other, but the player has left, and I’d want the player that left to see the message when he/she joins. Using DataStore or HttpService is very tedious and overcomplicated, so we should have a new method,

<String> MessagingService:GetAsync(string topic)

Which will help greatly in this case as someone can join while still in the party, and with a little help from DataStore to provide a key for the topic, MessagingService:GetAsync() can make them get back to what they were in.

Increasing MessagingService size limit

Also, MessagingService’s limits, from this thread;

I find the message size to be a bit, small. I find that the limit for the message size is <970 characters or even less. Sure the Roblox devs intended it to be a fast packet send between servers, and should only be meant for sending messages between servers and none else;
but in this case, for this party system, I’m wanting to have a 200+ player cache of the PlayerIds in that party, and for even the best compression system, even I can’t seem to fit a budget with the 1kB packet limit.

Solution? Simply increase the size to a reasonable amount, for example, 5kB; which is enough to fit 400+ player IDs with my compression system, or 10kB, which is enough to fit 400+ player IDs without. Either way, it should be flexible for MessagingService to be lighting fast to communicate within servers.

Conclusion.
Add MessagingService:GetAsync();
Increase the size limit of the data being sent.

3 Likes
#2

According to the platform roadmap, there will be ephemeral datastores coming in quarter 4 which seems to be the perfect solution to your request.

#3

The fundamental design of the feature is to be not persistent so having this stored on our end persisted isn’t something we will be pursuing for the time being. Additionally, the platform goal is to create primitives which as a developer you can expand to create lots of varied experiences.

If you elaborate on why storing it using data stores would be tedious I would be interested in understanding more.

Re: your 2nd use case. Once we have ephemeral data stores that should get solved if I understand it correctly.

1 Like
#4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.