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

You can use BaseValues too? (and on ReplicatedStorage) That’s essentially what I did.

It’s just fine for the most part, you don’t need to handle replication for it then, what’s the problem with using that?

But oh my god. Yes, I agree with you then, but that’s not what I mean.

I mean just creating a os.time IntValue object inside ReplicatedStorage when the server launches, that value is NOT updated ever, it’s only set once so that clients can grab it and know when the server actually started. The counting is only handled by the client then.

ValueBases are even worse. They’re artifacts of the older engine and are just more shortcuts. It’s a highly concerning problem and extremely dangerous mindset to get into that entraps newer developers.

By using ValueBases you’re telling Roblox to listen for event connections and add unnecessary instance metadata that consumes more resources.

For anyone reading this, I highly suggest you take in this golden advice:
Don’t use ValueBases. Please.

“It’s just fine” is not the problem. It’s bad practice and should not be used if a better and more granular solution exists.

This bickering is clogging up the thread and I provided more than enough information in my replies, including some good long-term advice, to help OP solve his problem.

What’s wrong with them? It’s like rejecting something just because it’s a bit old, BaseValues aren’t bad? They just hold values and that’s fine.

Then you can just use attributes.

Using RemoteEvents / Functions are still instances, give you the almost same result, there’s meta-data like Names, etc. It’s not much different than a ValueBase or Attribute.

Plus it’s not like .Changed connections are polling every frame or something. That’s just not how events work, and it wouldn’t change anything anyhow. The value or anything on it is not changing.

Yes I agree, but also please just edit your existing replies to add what you wanna say instead of making a completely new reply then.

Yes that is true, but that’s not what were doing here. It’s only one value keeping a os.time value, and that’s that.

Same with Remotes, they end up being the same thing, and just being more annoying to code.

In my reply, I explained a multitude of things wrong with them.

It’s not. I’m not advising against ValueBases simply because of their age. ValueBases have a ton of caveats and are almost always misused. Better and more robust solutions exist to keep track of information.

ValueBases are instances so they have a plethora of metadata attached to them that the engine needs to keep track of. With a few ValueBases this is negligible in terms of the performance difference, but if you’re excessively using them, it can become concerning.

You don’t need 95% of this metadata when using ValueBases, so essentially you’re creating more information than you need. Why would you ever do this?

ValueBases appeal so much to newer developers because of their ease of use, and they begin to adopt them as they grow. It’s not talked about much and usually takes a long time before you realize how bad they are.

I literally explained the issue with using attributes for this use case.

I for some reason didn’t think of using values… Anyway, this mostly helped me out, alongside @riverman56’s replies, which were pretty useful. I apologize for keeping you waiting, I was offline for most of the day.

1 Like