Avoiding wait() and why

Resources Community Tutorials
#94 
local ready = Instance.new("BindableEvent")

delay(function()
    ready:Fire()
end, 240) -- I forget if it's delay(240, function() end)

ReplicatedStorage.Values.PlayersLeft.Changed:Connect(function(newValue)
    if newValue == 1 then
        ready:Fire()
    end
end)

ready.Event:Wait()
2 Likes
The Basics of Perlin Noise | Roblox Video Tutorial
#95

looked it up to make sure and yes you put the time first

#96

I agree with this, but what about using it in the context of wait(5)? Do I have to create an intricate RunService.Heartbeat:Wait() solution such that I repeat that 300 times?

#97

It says right at the top of the post.

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).

#98

you do know frame rate is always different making this bad practice

#99

Ah okay thank you!

Also, I believe it is Delay(time, function)

#100

yep that’s exactly what I said to them as well

1 Like
#101

Luckily, you can use ModuleScripts so that you only write the code once.

How efficient is this loading screen?
#102

May I know why are we returning these 2 values?

#103

But I thought you said not to use wait() ever?

#104

Please read the post. wait() is bad, but mostly because it’s doing long polling when you should be reacting to events.

#105

So polling on events = bad

But on other cases, it’s good?

#106

I’ve collected all my thoughts on this in the original thread.

1 Like
#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