I’m confused as to what is going on in your visualization. The whole point of time syncing is to synchronize an event or movement on multiple clients and the server, but your demonstration is only showing what one client sees.
Instead of calculating how many things are added to workspace every frame you can use Stats to check the Physics and game Data receive and send rate in kbps: Stats | Roblox Creator Documentation
4 Likes
I was not aware of that. That is really helpful!
Works awesome for projectiles! Thanks so much!
Some people, including me, are asking for a license, for legal reasons. Could you please add one to the GitHub?
This is a really useful module (and very clever implementation), but I think it’s time for it go soon with the addition of workspace:GetServerTimeNow() (coming soon based on the release notes).
4 Likes
Wow, that is awesome! It is flattering to think that Roblox recognizes the same problem that I saw and sought to provide an in-engine solution to it. As said in that post’s replies, the naive approach of taking round trip time of a remote and dividing by two is highly inaccurate because of the behavior of the packet buffer as it processes outgoing and incoming remotes. This is the exact thing that my module tries to account for, meaning that if Roblox engineers acknowledge this same issue, then it is very likely that their solution has a high level of accuracy 
6 Likes
I am late here but just so I understand correctly. You are syncing the client and server clock and you are able to estimate a replication delay with some calculations. With this delay you can offset the server part (or if you trust the server, interpolate the client back). What I am interested to know is how ‘getservertimenow()‘ will substitute your module. Is it because the time elapse is in milliseconds instead of seconds as in tick()
That documentation is incorrect. The function is, as far as I’m concerned, supposed to return seconds.
How will the new function be any better than tick() or os.time(). They both return seconds and asynchronized also I believe meaning that server and client wont be synched.
1 Like
GetServerTimeNow is designed to solve the exact same problem that my module solves. The function, when called at the exact same instant on the client and server, should in theory return the same number (in seconds). I have no clue what you are asking.
1 Like
My game just periodically checks the round trip time (with an increasing delay between checks), and uses the new result if it had faster ping than the current result. Is there any reason to use an average?
I assume you looked into my code and saw the averaging step. I put that there because the offset between the client tick() and server tick() should be a fixed unknown. The goal of the module is to do as best of a guess at this value as possible, so sudden movements in the value are highly undesirable.
Anyways, Roblox is thankfully releasing a much better in-engine solution to this problem so I personally will be moving my projects to that once it is out, and closing down this post.
1 Like
Hey @Fluffmiceter! I’m still unsure on whether I should continue using this module, or Roblox’s new solution. Have you ran any benchmarks to see the difference in accuracy for both the solutions?
1 Like
I did some benchmarking and the new Roblox API was surprisingly unremarkable. Its performance was comparable to the Quenty clock. Because the in-engine solution is likely to be reliable for many years, I still recommend you to use that, but for my own projects, I still use my own module due to its much better precision.
2 Likes
I must have missed the announcement, mind linking it?
Do you have the results of the precision benchmark?
And do you know if the workspace:GetServerTimeNow() function do any remote calls to return the value or is it simply doing it once and then keeping it in sync?
Hey uh for some reason in Studio, :GetTime() difference between server and client results in usually less than 1 second.
However on playing the game on website, the clientTick - serverTick results in minus thousands.
Is there a reason for this? Does the module return values in milliseconds? What have I missed out?
10 Seconds is the time sent to the Player to start counting downwards from, the -19 value is the seconds lost.
So I get calculated time in minus.
I can say for sure that the remote did not take 19 seconds, and can say that I am doing clientTime - serverTime and not serverTime - clientTime.