Hello, I have this day and night cycle, which I intended the clocktime between 12am-8am would be 4 minutes in the real world, while the clocktimes from 8am-12am would be 6 minutes in the real world with a shift in time every 1/30th second. I’ve done all proper calculations to determine what this takes, and written out the code like so:
local lighting = game:GetService("Lighting")
local storage = game:GetService("ServerStorage")
local skystorage = storage.Skies
local timeShift = 1/15
local starttime = tick()
while true do
if lighting.ClockTime >= 8 and lighting.ClockTime <= 24 then --once 8am time ingame time goes faster (6m)
endttime = tick()
print(endttime - starttime)
timeShift = 4/45
--youcanstop = true
elseif lighting.ClockTime >= 0 and lighting.ClockTime <= 8 then --once 12am ingame time goes slower (4m)
timeShift = 1/15
--[[if youcanstop == true then
break
end]]
end
local minutesshift = game.Lighting:GetMinutesAfterMidnight() + timeShift
lighting:SetMinutesAfterMidnight(minutesshift)
task.wait(1/30)
end
-Please note these calculations were done when I was using a 1/3rd Second time shift, the code and variables above is changed to be for a 1/30th interval.
So the problem is that the timing is not correct. Through different trials and the tick() function seen in my code, the clocktime between 12am and 8am averages to 350 seconds, which is well over the 4 minutes I want. I’m not entirely sure what to do at this point. I’m pretty sure my calculations are correct, but something is wrong with my code that does not let me get the time I want for my system.
I’ll try but I’ve never been to great with graphs haha. But some more clarification, one whole day should last 10 minutes. I’ll be referring to the game time as clocktime to make the roblox property. And when I just say “minutes” I’m referring to the real world. So 24hrs clocktime should be 10 minutes long. However, I specifically want the clocktime from 12am to 8am to be 4 minutes long, while the time from 8am to 12am to be 6 minutes long. In my code and calculations, what the proper clocktime minute shift (hence the getMinutesAfterMidnight() + timeShift) code needed to be to reach 8am in 4 minutes. Same thing for the time between 8am and 12am. Here’s the calculations done under the proper 1/30th tick. Apologies for the poor handwriting - I never intended this to be read.
I’ve had a problem like this before. You need to compensate for the inaccuracies of task.wait. For example, here is the wrong way to make a 5-minute timer using a loop:
-- theoretically this should wait for 300 seconds, but it will actually wait for a little longer
for totalTime = 0, 300 do
task.wait(1)
-- do stuff
end
The problem with this timer is that task.wait(1) doesn’t wait for precisely 1 second, but rather it yields for approximately 1 second. This is fine if you don’t need to be super accurate, but when you’re running task.wait in a loop for several minutes, the inaccuracies add up to seconds upon seconds of extra time waited.
This is one way of fixing that timer:
local totalTime = 0
while totalTime < 300 do
local deltaTime = task.wait(1) -- task.wait returns the actual amount of time waited
totalTime += deltaTime -- add up the more accurate amount of time elapsed to account for errors
-- do stuff
end
I just tested the accuracy of task.wait(1/30) on my laptop, and if my calculations are correct, task.wait(1/30) experiences inaccuracies ranging between 5% to a whopping 42% error on my machine (15% to 30% on average). Add up these % errors 30 times a second over four minutes and you can guess what happens.
I also tested task.wait(300) and got a 0.0014% error, so it seems it becomes more accurate the longer you yield. task.wait(1) averages around 1% error, so after two minutes you’ll be well over a second behind.
So setting a variable to task.wait(1) is basically the equivalent of setting a variable to equal a number, in this case being one. Making a variable equaling task.wait(2) would be the same as “var = 2” and so on? Does setting the variable equal to task.wait(x) make the time waited occur? I’m just kind of confused on which part of the fixed code is actually “waiting”. Does setting a variable equal to a task.wait(1) cause it to wait?
task.wait is a function like any other. Functions get called and they optionally return a result, and task.wait actually does have a result. Take a look at the documentation for task.wait, you’ll see that the function returns the actual time elapsed. This means we can store whatever number is returned in a variable for further use.
When you call task.wait(1), the function returns a result but you don’t store that result anywhere. If you want to store the result of the function, you just assign it to a variable local dt = task.wait(1). This will still wait one second, the only difference is you’re now storing the result of task.wait(1) into the variable dt after task.wait(1) is done. You can see it in action if you type this into the command bar:
Note that you can also use a variable to store a reference to a function:
local spaghetti = task.wait -- without parentheses, we are referencing the "task.wait" function itself instead of calling it
spaghetti(1) -- this is now the same as task.wait(1); try it yourself
Here’s another explanation:
-- Hey, let's store the function, task.wait, inside of "spaghetti"
local spaghetti = task.wait -- "spaghetti" is a function, i.e. task.wait
-- Hey, let's run task.wait and after it's done, store its result in "dt"
local dt = task.wait() -- "dt" is a number, i.e. the result of task.wait()
