Avoiding wait() and why

Resources Community Tutorials
#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…

#127

Even though you’re just a beginner, a little optimization tip will not hurt you.

3 Likes
#128

Time to click the replace button and type “wait” with “task.wait”

#129

The opposite. My custom wait module is still more accurate than task.wait specifically because of it being implemented on the C side - it has to converse back and forth between the Lua and C APIs, which slows down execution times by an ever-so-slight amount.

#130

In my years of using wait() it has never broke, so I’m not sure what you are talking about. It does exactly what it’s supposed to do.

The only difference between wait and task.wait is the fact that wait updates at lower rate making it less accurate.

#131

I’m talking about optimization and accuracy.

#132

He’s not mentioning your wait function as far as I have noticed, and the example he showed is slower, by a lot.

On yours, you handle everything in one thread, almost no allocation at all every frame, which is why it’s much faster, not having to switch from thread environments much at all.

His example code has allocation every frame for every current wait running, and that’s because a:Wait call has to create a signal listed list node, and that takes some time and memory.

I don’t really use wait because it is still a code smell mostly, but the only issue I have with your wait scheduler is the fact that I believe this line of code would resume the second wait right away, and just iteration problems which could all be fixed by using a linked list implementation.

RBXWait()
-- Thread is resumed, moving to next wait in list
RBXWait() 
-- This is the next wait, and it's resumed immediately because the time passed is higher than 0.

Reverse order of insertion here, like what happens with linked lists would fix this.

I had a situation something like that with you implementation, but I don’t remember exactly what code I used. But I do remember having an issue quite like this, and even if this little pattern is rarely used, it’s still a structural problem, one could be fixed by sacrificing speed just slightly.

#133

It would not.

local RBXWait = require(game.ReplicatedStorage.RBXWait)

-- Wait for Roblox to load in
RBXWait(1)

print(RBXWait(), os.clock())
print(RBXWait(), os.clock())

-- Output:
0.017238000000361 161779.085962
0.015033899981063 161779.1011233

I was assuming he was talking about mine, as it is the most popular custom-wait module by miles.