A few days ago, I used print(wait()) and it waited for .79 seconds. The game wasn’t laggy from builds, but I did have a loop that uses RunService.Heartbeat:Wait() before and after the wait().
General Idea of the code
local i = 0
–open the door
while i < someNumber do
Part1.CFrame = someCFrame
Part2.CFrame = someCFrame
i = i + RunService.Heartbeat:Wait()
end
–wait a bit
wait() --this is the wait with the bad delay
–close the door
i = 0
while something do --repeat loop from above here also
end
What affects the delay for wait() in any game, not this just one specifically?
I tried wait(.5), wait(.05), and just wait(), they all waited for around .8 seconds
I know how long the loops before and after the wait are, I used print(wait()) to see the delay
Also, I don’t need an alternative, I already replaced it with another loop that uses RunService.Heartbeat
That’s not what wait() does. All scripts run line-by-line, regardless of whether you have a wait. wait() is a function that takes an argument for how long you want to wait, so not giving any argument will make it wait the minimum amount of time, which is about 1/30th of a second.
To the main post: wait() isn’t always exactly the time you ask it to wait, it’s at least that much time.
Lua is single threaded meaning it can only do 1 task at a time. As such Roblox has what’s known as the Task Scheduler, this is what defines what script and coroutine is executing at what time. When you call wait(), what you’re really doing is telling the task scheduler to pause this current lua thread and execute another. This means that the lua thread which called wait() may not be executed again for any length of time. So if you made a call to wait() and then somewhere else in your code did an operation that took a long period of time, the task scheduler wouldn’t run the code after that wait() until that other lua thread either ended or called wait() itself.
That explanation is a bit long winded so feel free to ask for any clarifications.
wait() is tied to frame rate, it is guaranteed to yield for atleast the specified amount, but can also yield for more.
If you put this in a normal script and started play solo, it doesn’t seem suprising. The game just started, and for me waiting for 1 hearbeat right away will take about 1 second usually.
I know it’s already been said a few times, but I feel that the point is slightly obscure and drawn out. To make matters simple, think of wait like this: you ask the scheduler to wait n seconds and until a spot in the scheduler is open to run my tasks.
Anything from framerate, expensive loops and computations and heavy operations in general can offset the time. Wait will never wait n seconds exactly.
That all being said, your problem is pretty abstract. Is there something specific you’re wanting to do in which the excess wait time is not negligible and incurs a noticeable performance difference, or are you asking for the sake of knowledge?
it supposed to open a door for a small time and close it, but it’s staying open too long, removing wait is too fast and doing wait() is too long
also, the other running threads are simple stuff, like the default camera movement, character animate, and character movement
For a bit more info than what everyone else has said, here’s an excerpt from evaera describing what’s happening:
wait is not resumed consistently in roblox … has an implicit “optimization” which stops resuming threads if it has spent too much time in execution thus far, so wait() can end up taking 5 or 6 seconds in worst cases
Basically, make sure you don’t spend too much time in execution in each frame.