I can see this being a neat feature, can’t wait to see!
When can we expect this service to exit seclusion and enter the public scene for all developers?
Does anyone have an official deadline or an ETA?
5 Likes
I am really excited to use this feature. I’ve been relying on third party services to communicate between servers. Hope everything goes smoothly and gets released soon!
2 Likes
Woohoo, something I’ve waited for for a while. Goodbye https. :))
Question, its probably obvious but I’m horrible at understanding new things: Would this allow us to shut down all servers in a running game at the same time from inside one of the servers? Having it work a little bit like a game wide BindableEvent.
Really cool feature to implement. I like this idea.
Yes you can absolutely do that.
Someone made a module for MessagingService that acts like BindableEvents lol
3 Likes
UEVENT is returning nil, I’m guessing this is because I’m not in the beta test programme?
Are you trying it in studio?
if game:GetService("RunService"):IsStudio() then
return { new = function() end }
end
This would be a reason why it would return nil. Idk what you are doing tho.
MessagingService:SubscribeAsync() The “Sent” variable is NOT unix. This value is influenced by the server’s timezone. This can be proven by:
Which shows the offset (The [=xxx] in the print line) from the other server to the true unix timezone as determined by combining os.time() and the decimal of tick().
My function for true unix time (Or as close to it as it can get):
local function True_Unix()
local Unix = os.time()
local Tick = tick()
return Unix+(Tick-math.floor(Tick))
end
2 Likes
How you get the offset.
the source server who sent the message filled the **sent** field with the return value of **tick()**. That shouldn’t be influenced by the timezone.
tick() is influenced by timezone of the calling machine (Be it client or server). It’s os.time() that isn’t.
1 Like
thank you for reporting this issue. I’ll work on it.
1 Like
Any ETA on the full release of this service? Pretty excited for it!
2 Likes
I made a module for helping others calculate the estimated size of their messages based on the estimated bit weight (Rounded up from the tenths place.) If you want to use it the module is posted below. Posting it here so those that are messing with MessagingService can see/use it to ensure their messages are within size constraints before passing them to MessagingService. (All data calculated with the assumption that MessagingService only allows strings with 1kB or less of data to be sent)
Valid UTF-8 characters are string.char(1) through string.char(127)
Example of use:
function Can_Send_Message(Message)
local Weight = WeightModule.Calculate_Byte_Weight(Message) -->“Hello world” = 11.287125
return (Weight<1000)
end
print(Can_Send_Message(“Hello world”)) → true
7 Likes
How long does it take for a server to receive the data from a server sending the data?
On average, it takes less than a second for other servers to receive data.
2 Likes
Been a few months since this was announced. Is there an ETA on when everyone will get access to this feature?
2 Likes
Will the 10,000 per-universe subscription limitation be increased during actual release?
I’m currently only using the service for cross-server announcements from game administrators.
I don’t want to implement any of my other ideas because of fears of reaching limitations.
As someone else deep in this thread stated: it essentially ensures top games can’t use it.
3 Likes
I agree, the “per universe” limit is worrying. For potentially traffic heavy games, implementing game features with this API is a risky move as if a game spikes in popularity it almost ensures that the feature will be broken.
Perhaps this will be addressed with the “Universe Scripts” feature that’s on the roadmap.
3 Likes