Task.wait(n) vs wait(n)

[Katrist]

I’ve heard a lot of people say to use task.wait(n) instead of wait(n). Is there any situations where you would use wait(n) over task.wait(n) or is task.wait(n) just definitively better? Any help is appreciated.

[HugeCoolboy2007 (omega)]

I can’t think of a situation where you’d want to use wait() over task.wait()

@WallsAreForClimbing

task.wait

Yields the current thread until the given duration (in seconds) has elapsed and then resumes the thread on the next Heartbeat step.

elapsed task.wait(duration=0)

Since the actual yield time may vary, this method returns it for convenience.

local elapsedTime = task.wait(2) -- wait for 2 seconds
print(elapsedTime) --> 2.0792941

If no duration is given the duration will default to zero meaning the thread will automatically resume on the next step.

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

task.wait is an improved version of wait which schedules the current thread to be resumed after some time has elapsed without throttling.

[LucasMZ_RBX (lucasmz)]

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:

@dukzae

wait() also returns a second value which describes the time that it finished yielding (basically os.time()). An example of this can be found in the Roblox default animate script. Note that it’s not worth using wait() over task.wait() specifically for this reason. You can simply call os.time after your yield to replicate the behavior.

Just note that task.wait, just like wait is still a code smell, usually indicates a bigger structural problem with your code.

[dukzae]

wait() also returns a second value which describes the time that it finished yielding (basically os.time()). An example of this can be found in the Roblox default animate script. Note that it’s not worth using wait() over task.wait() specifically for this reason. You can simply call os.time after your yield to replicate the behavior.

[LocalWE (SteamboatOrchard)]

task.wait(...) is based off of RunService.Heartbeat meaning that task.wait(...) is == RunService.Heartbeat. If you add parameters, it will keep yielding RunService.Heartbeat until the number you replace with ...'s time is up. Idk how wait works, but DONT USE IT. It is old, legacy, and will become deprecated soon.

[Katrist]

Thanks for the help you guys! If anybody else wants to add more info, feel free to do so.

[WallsAreForClimbing (Climber)]

Just wanted to chime in and say that while we haven’t deprecated wait yet we intend to do so in the future. That’s not to say it will stop working, just that you should use task.wait going forward.

[anon40242271]

Oh I thought you meant you’d remove wait() one day.

[Katrist]

He said in his post:

@WallsAreForClimbing

That’s not to say it will stop working

[QuinnMcChief]

Why didn’t you just change the function of wait() to be equivalent to RunService.Heartbeat:Wait() instead of choosing to create a new syntax for it?

(you chose to create task.wait() instead of just changing what wait() does. why?)

[HugeCoolboy2007 (omega)]

This is to preserve backwards compatiblity with older games (and even some modern ones).

If they just changed/updated the wait function, many games on Roblox will start to experience inaccurate yield times.

[QuinnMcChief]

I thought task.wait() was a more accurate yield? how would it be inaccurate?

[HugeCoolboy2007 (omega)]

It does, I was referring to wait. task.wait runs at 60 Hz while wait runs at 30 Hz. For example, running wait(0.1) is not the same as task.wait(0.1).

This would break older games that rely on a 30 FPS yield time rather than a 60 FPS yield time

[kaabzuag]

If you have command bar open, type in:

print("wait: ".. wait(),"task.wait: " .. task.wait())

output:
wait: 0.030285800000001473
task.wait: 0.000014499999998918156

[QuinnMcChief]

you make an excellent point lol

[Pokruk]

if you try close coroutine that waiting by wait(), youll get error “cannot resume dead coroutine” without any information about error source

[WallsAreForClimbing (Climber)]

Just to clarify we do not guarantee that task.wait will resume at 60 Hz, otherwise your explanation is correct.

[brainfartimus]

(post has been removed by author)

[Kazisito (Kazi)]

agree with this. there are many situations where yielding is the only sensible answer, and event based programming is sometimes an unnecessary application

[Phoenix1205555]

I replaced every repeat loop in my game to reduce lag or such with game:GetService(“RunService”).Stepped:Connect(function() --code end) and the loops worked faster but every wait stopped working putting anything with wait(?) to not continue.