Should I use Wait() or Task.Wait()

[FroDev1002 (FroDev)]

So I looked around a bit.
And then I wondered,

---

Should I be using Wait() Or Task.Wait()?

• What are the pros and cons?

---

I would say more but there isnt much more to say, so Im gonna leave it at that!

~FROYO~

[DataSigh]

Task.wait(n) vs wait(n)

No. Definitively not, task.wait is definitively better. The differences with wait and task.wait are: wait() can sometimes delay when it resumes the thread because of performance concerns, which is actually bad because you will rarely have those because of it task.wait() updates 2x faster than wait(), therefore more accurate Also: Just note that task.wait, just like wait is still a code smell, usually indicates a bigger structural problem with your code.

[Azurethpat]

While I don’t know the cons of Task.Wait(), it is 100% better. It is definitely more accurrate than the regular Wait(). If you’re still using Wait(), would reccommend to switch.

[LucasMZ_RBX (LucasMZ)]

What are you using it for

While true do loops should be replaced with RunService.Heartbeat:Connect()

[0Tenth]

@LucasMZ_RBX

While true do loops should be replaced with RunService.Heartbeat:Connect()

task.wait() is equivalent to RunService.Heartbeat:Wait()

[WovenBreaker]

Short answer, use task.wait instead of wait
Long answer:
There are no cons to using task.wait. The task library was added to supersede the normal functions such as spawn, delay, and wait. IIRC the issue with these functions was that they were throttled to 30Hz, which isn’t the case for the task library, meaning that if you just called task.wait without a duration parameter, it’d just resume on the next frame (like Runservice.Heartbeat:Wait())

[LucasMZ_RBX (LucasMZ)]

Except that :Wait is rather expensive (or at least, much MORE than connecting) on Deferred Events; (even on Immediate mode) compared to just using Connect.

If you have a :Wait loop, it is basically every frame creating a new connection. That is not great.

task.wait() is better but it’s still not good.

If you’re trying to run something kinda of every frame, then use Heartbeat:Connect, not a while loop with task.wait(), that’s not what’s it’s supposed to be used for.

Edit: It’s actually not even the same because they return different elapsedTimes;

[2112Jay]

I set up a function to make the wait() command run through a stepped:wait() by whatever number, that seem to work better than wait() as far as lag messing up my script timing. Than I tired task.wait() and that was just the same as the funtion I created. Pretty sure that is what it is doing, so now I use task.wait().

[AustnBlox (Austin)]

There are an insane amount of posts regarding this already.

Task Library - Now Available!

Hey developers, We have just enabled a brand new library that you can use in your projects. The task library allows you to talk directly with our engine’s task scheduler to manage and schedule code. It features a number of new methods as well as some improvements to existing methods. Details task.spawn Takes a thread or function and resumes it immediately through the engine’s scheduler. Additional arguments are passed to the thread or function being resumed. void task.spawn(function | threa…

[swag4lifex (PaintedPolarity)]

you couldn’t be more wrong their is pro’s and cons of every keyword in lua wait() being shorter then task.wait in and out of itself is a pro you still shouldn’t use wait() though

task.wait longer then wait is a con also

[HugeCoolboy2007 (omega)]

@swag4lifex

task.wait longer then wait is a con also

The amount of time it takes you to type a variable/function has no effect on its usefulness; that’s not a con