Avoiding wait() and why

Resources Community Tutorials
#107

I’m sorry but I still have some questions in my head I’m just asking if wait() is really useless or useful in certain cases?

#108

Oh my god am I a necrobumpers :sob:

Anyways, is ‘delay’ unreliable? Just wondering :smiley:

#109

delay runs on the same task scheduler as everything else, apparently there’ve been some improvements but I don’t see myself ever using it again.

1 Like
#110

Functionally, it’s pretty similar to wait. although one thing i’ve noticed is that it implements a small jitter of around 0.005(?) to the point you tell it, if you delay something a bunch of times, you’ll eventually see it in action.

I’d say it’s probably functionally useless though, it’s lacking in ergonemics in the sense that any use case outside of ‘delay & forget’ is basically impossible (lack of interface, can’t ‘undelay’ or anything like that.), and you also can’t pass arguments to the function you’re delaying, which makes things a lot uglier.

#111

Thanks for the info on wait(). By the way, it will be run is the correct sentence not “it will be ran”.

#112

Good news!

wait() is now getting deprecated! task.wait() is now the new method of waiting!

2 Likes
#113

I think this new library is really amazing

1 Like
#114

Finally the war between the wait team and the heartbeat team have ended in peace xD

2 Likes
#115

I’m still not sure if this library function suffers from the same issue as normal Heartbeat wait functions… which is if you have many wait calls, the scheduler might get all crazy, because you’re resuming a new thread for each wait call every heartbeat, and doing checking everytime;

Waiting for a response on that on the task thread.

(seems like yes nvm)

#116

If you simply replace all wait() with task.wait(), you have achieved basically nothing that this thread hasn’t already covered.

wait() is a code smell not because of the internals of wait. The task API is good and all, but this post is still extremely relevant.

6 Likes
#117

Old post but isn’t using delay (as well as spawn) bad practice as well because they’re slow and/or unreliable or was I just misinformed?

#118

Yes, but it was an example for the sake of showing how you can work without wait. In my own projects I had a custom delay, nowadays I’d just use task.delay.

#119

I used to use repeat wait() until but I realized that it took far too long. Thank you for the alternative suggestions.

#120

I’ve seen that guy not really like while wait() do (I don’t like it too) so my guess is that they did that so you can’t do that

1 Like
#121

Okay but what about things like

Part.Touched:Connect(function(hit)
wait(5)
print("player touched part")
end

Is it fine to use wait() in this situation? If not, then why not? A lot of people still use wait() and I don’t see that changing to be honest.

1 Like
#122

well I do
task.wait() replaces wait()
sooner or later delay(), wait(), and spawn() will get deprecated

#123

Some people say that replacing wait with something like this

while THETIME > CURRENTTIME do
RunServiceEvent:Wait()
end

It actually isn’t.

task.wait(n) is better because it is done on the C side, and because it doesn’t have to resume and yield every runservice event.

#124

I like the wait() command so no.

#125

You’ll start to dislike it the more you use it in important loops of scripts or scripts that may break if you use it too much.

1 Like
#126

Well i am still a beginner at scripting, so i guess…