I needed some high precision clock syncing between every client and the server, and this is perfect!
It requires close to no setup and is pretty much a drop-in replacement for os.clock() or tick().
Can highly recommend!
Thank you for releasing this great module for free!
Thank you so much! I initially wanted to use Quenty’s module, but I did not want to import the entire Nevermore framework to only use one module. This is all I wanted. By the way, I gave you a star on GitHub to support your work.
Exactly how I intend people to use it! Most of my logic is timed based off of tick(), so I intentionally wrote this so it can be a simple replacement, no additional logic needed.
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
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).
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 
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.
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.
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.
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?
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.
I must have missed the announcement, mind linking it?
