Common causes for lengthened wait() time?

[DalekAndrew99]

My game relies on the wait() function quite heavily, but for some reason the delay time to wait() can be highly inaccurate. Usually this inaccuracy is small (0.03 sec), but in some cases it can get as long as 3 seconds! This is a huge problem for my game when it happens, since it basically makes the game unplayable.

I can use alternatives to wait(), but I would rather try to fix it before trying to avoid it completely.

This topic has been asked before, but people only answered with why it happens internally, and not the general causes for it.

What could increase the time for wait() to delay?

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 her…

[sloss2003]

Wait will wait as short as it possibly can, at a minimum of the time you tell it to wait for. But, your question has already been answered. How long does wait() wait for?

It can happen because of lag, and a multitude of things. It’s extremely difficult to narrow down to one thing.

[steven4547466 (Steven)]

Not exactly answering, but wait() is really, really bad

Avoiding wait() and why

This is an adaptation of a Twitter thread I made a while ago. This is simply a better formatted and more fleshed out version. Let’s talk about wait(). Not wait(n) (although if you are using small n values to where it’d be barely distinguishable from wait(), you’re probably going to hit the same issues mentioned in this thread). We probably learned about wait() at first as the solution to “why are my infinite loops crashing me?”. It’s a super easy solution and it works! This starts a bad habit…

[Jackscarlett]

Using wait() can result in a lot of inaccurate effects, especially if the game relies on a lot of performance

Alternatively, you can use a RunService event which would be way faster than just using wait()

[SummerEquinox (Riley)]

What I use, courtesy of DanzLua.

function safeWait(seconds)
	local waitTo = tick() + seconds;
	while (tick() < waitTo) do
		game:GetService("RunService").Heartbeat:Wait()
	end
end

[DalekAndrew99]

Can there be any performance issues with this wait function? since it updates every frame.

[Ultramariner (Ultra)]

The link posted above gives a general idea for why wait() can be terrible in practice, but it doesn’t exactly explain why. The reason wait() has different length times is because there is no guarantee for when it will resume. If you are unlucky and need a ton of tasks to be regularly resumed, you can go over the per frame quota and the wait() may take a second rather than the ~0.03 seconds.

This is also why I’m an advocate for yielding on events using the provided :Wait() command. It is much better practice and will give you the results you want. However, if you need a custom accurate wait function then you should use a timer that runs on each frame like Heartbeat.

[SummerEquinox (Riley)]

Not performance issues that are a result of the function, this will work fine.

[Jackscarlett]

Similar posts:

Is repeat wait(.5... etc) bad in a script?

I don’t think it’d be “bad”, as long as you implement some sort of long delay I suppose you should be fine You could also compare 2 values using RunService's Events, & quickly checking if the “NewValue” is greater than the number you want to detect for using tick() (Which I don’t know would be more efficient or not) local RunService = game:GetService("RunService") local Connection wait(30) --Or add some delay before starting the current time & checking its difference local CurrentTime = tick(…

Is repeat wait(.5... etc) bad in a script?

It’s only bad if you care about the downsides. Remember that the reason people are doing RunService.Stepped:Wait() and similar is because the thread scheduler (the one that makes wait(), spawn(), delay(), Debris etc. work) can sometimes throttle for unexpectedly long. Like a wait(2) waiting for 5 seconds instead. This leads to bullet hole decals on walls staying for too long, and other oddities. The thing is, if you don’t care about that- if you just want your wait(1) loop to just run at whate…

[dthecoolest]

Yep no major performance issues with that wait.

The explanation is that Runservice is newer and simply runs faster in 60 Hz therefore is more likely to resume paused code faster and have less delay than wait(). This delay with resuming code causes the lag (for others new to the issue it’s shown here in this video by clone trooper).

Evaera

spawn , delay , and wait are all artifacts from Roblox’s 30hz pipeline, and they don’t resume at a consistent rate. In fact, there is no guarantee that they will ever resume at all .

[DalekAndrew99]

Well, it might be better to just switch to the Heartbeat wait function then.