Os.clock() time is different in the studio than it is in-game?

[ShubaPonCR (ShortPeople Saver)]

I have this simple line of code that tells me the time taken between remote events. (Code is written in a localscript)

This is what it prints on the Studio

but this is what it prints in-game???

The time should be that of DeltaTime, does anyone know a workaround to this?

[Modern_Developer2201 (ModernDev)]

Try using the tick() function on studio

[AlternativeOrNot]

Where do you assign bul.DelayServ?

[ShubaPonCR (ShortPeople Saver)]

Using tick got me the same result

[ShubaPonCR (ShortPeople Saver)]

Its the os.clock defined in the server script

RE:FireClient(plr, os.clock)

–local

RE.OnClientEvent:Connect(function(DelayServ)
local dt = os.clock - DelayServ
end)

Thats more or less the idea

[AlternativeOrNot]

Well then, do you fire the actual event?

[detourious]

os.clock() returns a high-precision amount of CPU time used by Lua in seconds, intended for use in benchmarking, as found on the docs: os | Documentation - Roblox Creator Hub

The reason why it works in studio as intended is because the server and the client are using the same CPU on your local machine.

For the purpose you described, you’d want to use tick().

[icy_oasis]

As previously mentioned, os.clock reports precise time Lua has been using the CPU.

But using tick is almost certainly not a reliable choice due to potential discrepancies and the likelihood of deprecation.

What discrepancies?

@zeuxcg

tick() sounds perfect - it has a high resolution (usually around 1 microsecond), and a well-defined baseline - it counts since UNIX epoch! Or, well, it actually doesn’t. On Windows, it returns you a variant of the UNIX timestamp in local time zone. In addition, it can be off by 1 second from the actual, real UNIX timestamp, and might have other idiosyncrasies on non-Windows platforms. We’re going to deprecate this in the future.

_{(From Luau Recap: June 2020)}

time() depends on when the game instance started running (varies between server and clients), while os.time (no milliseconds) is not precise enough.

On the other hand, DateTime (converted with ToUniversalTime) or workspace:GetServerTimeNow (synced on server and client) would be more suitable for your needs.

If you are working on a ping display.

Take into account that:

1. This is one way latency. I’m pretty sure client-server and server-client communication isn’t always symmetrical, so remote event latency multiplied by two isn’t necessarily an accurate representation of ping time.

Perhaps player:GetNetworkPing is what you are looking for instead.

2. Each observed set of remote event delays exhibits some dispersion/spread, such as occasional spikes/prolonged delays. They typically don’t affect the average much, so it’s better to present average latency.