Event every time os.time changes?

Is it possible to detect when os.time changes, or is there a better way to get the value instead of looping every second or so to get it? I’d like to avoid loops if possible, which is what I’m using currecnty.

I’ve looked around and haven’t seen a solution for this.

1 Like

It changes every second, I think just get the value whenever you need it

What exactly are you using it for? There could be other solutions. Also looping through every second wouldn’t cause much lag so I don’t think that would be a problem.

Having an event when os.time changes would be more inefficient than looping every second. If you’re simply using wait(1), the thread knows exactly how long to pause for and when to continue. However if you’re trying to find out when os.time changes, there’s no implemented statement that says it changes every second and thus you would technically be using more power by waiting for its form of a changed event to fire (if there is any) and then continuing.

7 Likes

Since you are asking for an event, here is what you can do:

local event = Instance.new("BindableEvent")

event.Event:Connect(function(osTime)
      print(osTime)
end)

while wait(1) do
     event:Fire(os.time())
end

However this is inefficient but I wanted to answer straight to the point.

While wait() loops are a very bad practice, I’d recommend trying to steer clear from them.

An in-depth explanation:

Will this be better than using a bindable event?

    local OsTime = Instance.new("IntValue")
    OsTime.Parent = script

    OsTime.Changed:Connect(function()
       print(OsTime.Value)
    end)

    while wait(1) do
       OsTime.Value = os.time()
    end

If you bothered to look into my code carefully, I’m not using wait() but wait(1). There is nothing bad with using while wait(1) loops.

By while wait() loops I meant any while wait(n) loop implying that what the wait() function returns has any affect on whether the loop continues or not. It also causes people to forget the actual use of while loops.

So no, if you actually bothered to look at the document I attached you’d know that while wait() do refers to any while loop in which the conditional section is being abused.

1 Like

What’s your use case for needing to know when os.time changes? Someone asked earlier but an answer hasn’t been provided. There’s almost definitely a better event-based approach that can be taken here depending on what you’re doing. A use case should always accompany a question if not apparent already.

1 Like

while wait() is not always a bad practice it really depends on the implementation.

If you wan’t to have something which for example continuesly spawn a zombie each second while wait(1) is an ok implementation. Sure there is one problem that it might not exactly run each second but that is a nother issues.

Of course event base methods are always superior but this is the few cases where while wait() is acceptable.

What would make it more superior than while true do wait() end? If you’re trying to be efficient this is most definitely the better way to go.

Oh sorry. I misread your post.

1 Like

By while wait() loops I meant any while wait(n) loop implying that what the wait() function returns has any affect on whether the loop continues or not. It also causes people to forget the actual use of while loops.

There is nothing bad with using while wait(n) do as long as you are using it for what it’s intended to. The main thing bad with is the inconsistency of the global function wait. A while loop should be used where it is supposed to be.

I’m using os.time for a custom time system, essentially every real life hour is a virtual day.

In this case, so long as the server doesn’t have any need to know the real time either (though it can always just fetch it when it needs it instead of constantly updating it), my suggestion would be to instead fetch the real time from the client and then increment time accordingly, such as in a RunService signal. This way you’re taking advantage of client-side prediction. You can always resynchronise the time by resetting the variable every now and again, not too expensive to do.