math.floor can be used for rounding the value because the tick() function has quite a bit of decimal places. you can also wrap it in math.ceil instead if you want
Out of curiosity - what is the use case for you doing this? I’m honestly suspecting an incoming micro-optimisation. It takes a few miliseconds to instance a part at best. Do you have any use for this information?
Yes, these are miliseconds. Might as well use os.time in this case because it doesn’t include miliseconds.
Er, no, it’s not. tick on the client returns time relative to the machine’s time zone. The server returns time relative to the server’s time zone. The client and server do not have synchronised ticks.
Creating a part is only an example for this question, this is probably for my game Pen Tapping Simulator, I need the elapsed time of a beat playing in a server.
EDIT: Unsolved
I just realise that the time is always 0, my ultimate goal is to find the time that needed to create the part because there’s the lag between the client and the server.
There are two ways you can resolve this kind of problem. I still don’t quite see where checking the time to instance a part matters or how lag plays a factor in this, but whatever I guess.
The first way is to create a RemoteFunction and count the seconds between invoking it and when the server returns a value, indicating it is done.
-- Client
local now = tick()
local done = RemoteFunction:InvokeServer()
local later = tick()
local elapsed = later - now
-- Server
RemoteFunction.OnServerInvoke = function(player)
Instance.new("Part")
return true
end
The second is just to create the parts on the client. Fire information to the server, validate it, fire it back to clients. Have the clients manage the parts. Part creation will then be a bottleneck relative to their machine and network specs, not anything to do with cross-server communication.