Oh nice, what’s the module? I may use it. I thought task.wait()
was way more accurate compared to wait()
Yes, when you set task.wait()
s duration to 0, it doesnt actually wait 0, it you decide to print it, you will notice that it will be set to around 0.01
for yielding, however if you dont add the Argument at all, it would actually be faster than task.wait(0)
print(task.wait()) --> 0.014155100000039056
print(task.wait(0)) --> 0.01539900000000216
-- the number can be different each time its printed.
Interesting. Does simply using task.wait()
with no aguments wait 1 frame or is there another way to do that (That is, without Heartbeat?)
You probably already discussed this
What’s the difference between simply doing task.wait()
and task.wait(0)
?
As far as I’m aware, they both do the exact same thing.
In fact, it seems like task.wait(0)
takes longer…
local t = os.clock()
for i = 1,10 do
task.wait(0)
end
print(os.clock()-t)
t = os.clock()
for i = 1,10 do
task.wait()
end
print(os.clock()-t)
Out:
1.378110799996648
0.20563579999725334
Well it depends what kind of frame.
Render frame? No, you will need to use RunService.RenderStepped/PreRender
for accurate pre/post-render frames.
Physics frame? No, you will need to use RunService.Heartbeat/Stepped
for accurate pre/post-physics frames.
task.wait()
AFAIK simply waits until the next loop in the task scheduler, which can happen regardless to physics/render frames.
task.wait is based on PostSimulation (Heartbeat) frequency. After the given amount of time has elapsed, the thread resumes on the next Heartbeat. It’s not an arbitrary “task scheduler loop”. PostSimulation:Wait() == task.wait with no argument.
Ah okay, that clears things up.