Server age countdown behaves like it's client-sided, even though it's a server script

[SkyWalk1n]

Hey there!

Recently, I’ve been working on a server age UI that counts time since the start of the server. The timer part of it works well, but the issue is that it only works on the client, even though it’s a server script. By this I mean, every time a player joins, they see the timer reset and start counting from 0, even if someone else sees it as 1 hr+.

---

Code:

-- // Services \\ --
local RS = game:GetService("RunService")

-- // Variables \\ --
local start = os.clock()

-- // Main logic \\ --
RS.Heartbeat:Connect(function()
	local started = os.clock() - start
	
	local min = math.floor(started / 60)

	local sec = math.floor(started % 60)

	local hr = math.floor(min - min%60)/60

	script.Parent.Time.Text = string.format("Server age: %.2d:%.2d:%.2d", hr, min, sec)
end)

I’m well aware that this happens because of local started = os.clock() - start, however, I’m not sure what to replace it with.

[octalverse]

If you’re displaying this value in a gui, you need to do it from the client. When a client joins, they receive a copy of the contents in StarterGui inside their PlayerGui.

[SkyWalk1n]

Did you even bother reading the post? I’m trying to constantly update the value on the server for everyone to see.

[octalverse]

os.clock() returns the amount of time since the current Luau runtime has begun. When a client joins the game and by the time this code runs from a LocalScript, the environment hasn’t been running for long, and will be different between clients. The server is one computing instance, and your goal is to display the server’s age to all clients. You need to keep track of this number on the server and replicate it to clients at an interval. In layman’s terms, at certain time periods, tell clients to represent the server’s age. This is probably best accomplished with the use of RemoteEvents.

I want to also make a quick note about your comment usage. Declaring sections of code with comment headers like services, variables, etc. is partly a waste and doesn’t help readability, since any user should be able to differentiate between clusters of code.

You don’t even need your RunService counting logic, because os.clock() is a continuously counting nominal value and will always return the amount of seconds elapsed since the Lua interpreter started consuming resources.

[0Luke_Skywalker0 (Luke)]

you can literally just use time()
yes, just that

Also, Heartbeat is only available on the client since it is supposed to run every frame, and the server has no way of knowing that

[octalverse]

It doesn’t matter whether OP uses os.clock() or time() in this case since it doesn’t look like he needs precision past minutes. If he needs precision past seconds, he must use os.clock().

The RunService.Heartbeat event works in the server environment too. It makes sense, because it fires after every physics simulation job has finished.

[LucasMZ_RBX (LucasMZ)]

@0Luke_Skywalker0

you can literally just use time()

@riverman56

It doesn’t matter whether OP uses os.clock() and time()

I will say, os.clock is wayy more accurate than time.

For instance,

print(
    os.clock() == os.clock() --> false
)

print(
    time() == time() --> true
)

I have heard that time is planned to be deprecated, but can’t actually confirm, so don’t take my words for it. But for most cases, os.clock is the thing for the job.

@SkyWalk1n

local min = math.floor(started / 60)

	local sec = math.floor(started % 60)

	local hr = math.floor(min - min%60)/60

I don’t know much of converting time (i’m horrible at math), but:

would this be better?

local hour = math.floor(started / 3600)
local minutes = math.floor(started % 3600)
local seconds = ---? I don't know how to calculate this, just a second. WHY IS STUDIO INSTALLING WHAT

[octalverse]

@LucasTutoriaisSaimo

I will say, os.clock is wayy more accurate than time .

In my reply I stated it doesn’t matter, because he isn’t looking for precision past minutes

[JarodOfOrbiter]

@LucasTutoriaisSaimo

have heard that time is planned to be deprecated, but can’t actually

tick is going to be deprecated in favor of os.time, time, and os.clock.

[0Luke_Skywalker0 (Luke)]

yea, normally server age doesn’t even need precision past minutes

[octalverse]

It’s entirely dependent on what level of precision you want. I don’t think it’s an adopted concept that when displaying age you don’t “need” precision past minutes.

[octalverse]

If this is true, then yes, please use os.clock()

[LucasMZ_RBX (LucasMZ)]

@SkyWalk1n

they see the timer reset and start counting from 0, even if someone else sees it as 1 hr+.

You need have a value / attribute that kept somewhere maybe in workspace, replicatedstorage, whatever, which keeps the a os.time value of when the server launched! (must be os.time).

Then, you can use that to calculate the time properly on the client.

Something like this could work;

--\\ Client

local ReplicatedStorage = game:GetService("ReplicatedStorage")

local start = ReplicatedStorage:WaitForChild("ServerCreatedTime") and ReplicatedStorage.ServerCreatedTime.Value

game:GetService("RunService").Heartbeat:Connect(function()
    local started = os.time() - start       
 
    local min = math.floor(started / 60)

	local sec = math.floor(started % 60)

	local hr = math.floor(min - min % 60) / 60

	script.Parent.Time.Text = string.format("Server age: %.2d:%.2d:%.2d", hr, min, sec)
end)

---

[JarodOfOrbiter]

Sleitnick has advised against os.clock except in Studio for benchmarking purposes. I’ll see if I can dig up a reference.

Here you go. It’s not super enlightening, but it’s well-worded and from what I would consider a primary source.

Os.time(), tick() or time()?

Seems like there might be a bit of confusion here. Here’s a rundown of what you really need to know: time() to measure time within a game in the same environment (e.g. don’t use it to calculate time between server and client). It will return a high-precision time since the game started. Useful for finding delta times for all sorts of things. You will probably end up using time() more than anything else. os.clock() is high-precision and good for benchmarks. Also useful for the same thing time() …

[0Luke_Skywalker0 (Luke)]

Devhub api reference

1 microsecond is WAY too precise for something like server age

[JarodOfOrbiter]

But unfortunately that doesn’t say anything about performance or stability consequences if you use it in your game.

[octalverse]

This is only one way of doing it, and it’s not preferred. Attributes are intended to pertain to the instances they’re assigned to. In my reply, the best way to handle replication for this would be to use RemoteEvents.

[LucasMZ_RBX (LucasMZ)]

@riverman56

Attributes are intended to pertain to the instances they’re assigned to.

Sorry I don’t know what that means.

@riverman56

In my reply, the best way to handle replication for this would be to use RemoteEvents.

Why though…? I’m still confused.

[octalverse]

Please don’t do this.

Attributes are intended to pertain to the instances they’re assigned to. Workspace is a container holding all of the game’s view geometry. It does not make sense and is horrid practice to just chuck an attribute under Workspace that relates to something completely different from geometry simply for the sake of easiness and having Roblox handle replication for you.

RemoteEvents were created specifically for networking and communication, and are meant for these kinds of things.

Being in this mindset of relying on attributes for replication introduces code smell, and you wind up running into bugs that take a lot of resources to fix!

[octalverse]

Additionally, it would be more resource-conscious if the client asked for the value one time and then handled the counting itself. Continuously polling the server or continuously giving information to clients consumes lots of bandwidth.