Is "wait()" really deprecated?

Help and Feedback Scripting Support
#1

So i have been hearing for some years that “wait()” is deprecated

Ive also heard some people saying that you should make your own wait function since wait is deprecated(If it now is). I would really love some help. Because i dont know which side to belive?

So i tried making my own wait function in case its deprecated

function wait(NUM)
	local START = tick()
	print(START)
	while true do
		if tick() - START >= NUM then
			break
		end
		wait()
	end
end
1 Like
#2

it’s deprecated for a reason, so why remake it? instead, use task.wait

4 Likes
#3

Oh i didnt even know they had that. Thanks then :slightly_smiling_face:

1 Like
#4

Your still using wait() in your code so it would be still deprecated.

Also

game:GetService("RunService").Stepped:Wait()

Would be better to use.

2 Likes
#5

I suggest looking into CloneTrooper’s fastwait if you want a reliable wait system. I use it in my newer games. You can easily implement it into older games by replacing local function fastWait(t) with _G.wait(t) then replace everything that uses wait() with _G.wait()

Update: Stress tested task.wait(), and a custom wait is still better when a dev needs to use hundreds/thousands of wait() a second like in RPG or FPS games. Most games will be fine with using task.wait(). You can stress test them with this. Apologies for no comments, I randomly threw this together. Demonstration.rbxl (43.4 KB)
Clonetrooper’s custom wait demonstration:

Custom wait script:
https://gist.github.com/CloneTrooper1019/4ae7113f6ccfa666caa0c3991398e21a

1 Like
#6

Ye i noticted that 2 minutes later…

Not sure what i was thinking while typing the code :sweat_smile:

1 Like
#7

I’m personally not a big fan of it, the problem is that it uses os.clock, that’s bad because it doesn’t follow a behaviour most people would think it does, especifically if you wanna get the DeltaTime it returns and calculate something with it.
Most people would think that if you have two wait calls which were called at the same time, they should be resumed with the same Delta, and at the same time.
This is not the case when you’re using os.clock;
And like I mentioned it can be resumed at a later frame, which isn’t expected behaviour.

To be fair, task.wait I believe does use Heartbeat’s DeltaTime, but it ends up cutting off the start. It counts DeltaTime since the time it was called, which isn’t too useful.

Another thing is that the order is always gonna be off, it should resumed from the last wait called to the first called wait, but with arrays that isn’t possible without being way too expensive.

I personally have BetterWait, which is similar, but fixes the two problems listed above, it is a bit slower to go through all yields, but it uses a linked list and respects DeltaTime, behaves pretty much just like a standard wait function, with the performance improvement.

But if were being honest, overall heavy wait usage is not something that should even happen. Projects should be made with the proper events for everything in mind, all these wait libraries are just quick fixes to a much bigger architecture issue, most people are fine with using task.wait as long as they start to use custom events more!