Task Library - Now Available!

[VortexColor]

@tnavarts

It’s not a “bug” in that coroutine.wrap / coroutine.resume propagate errors in the same way that they do in vanilla Lua, they just don’t have the extra behavior that Roblox adds for convenient debugging in Studio. It makes sense to have a separate library like this if you want the Roblox behaviors so that vanilla Lua code can be brought into the engine from other sources and work as expected.

Oh i didn’t known.

But I don’t think inventing a new function just for different debugging is good and I think we should rather port the behavior of task.spawn to coroutine.wrap

[BullfrogBait]

I understand task.wait() vs wait() but is there a difference between task.wait(20) vs wait(20)? Should wait(x) be avoided at all costs now?

[VortexColor]

@BullfrogBait

I understand task.wait() vs wait() but is there a difference between task.wait(20) vs wait(20) ? Should wait(x) be avoided at all costs now?

wait(x) bad
task.wait(x) good

Yeah basically task.wait(x) is a better wait. Though you should still remember to use event based coding when you can.

But you should replace spawn() with coroutine.wrap and delay with task.delay, wait with task.wait etc.

[Halalaluyafail3 (FindFirstChild)]

The second result is seldom used, so most people are probably unaware of it. It is very similar to the result of elapsedTime, which has nothing to do with the wait function. The wait function returning 2 values is weird, it doesn’t make sense to follow the same weird design set by wait.

[WallsAreForClimbing (Climber)]

See my reply here → Task.wait() does not respect script.Disabled and always resumes - #4 by WallsAreForClimbing

[WallsAreForClimbing (Climber)]

You should use the new methods. Here’s a quick cheat-sheet:

Before	Now	Now (Alt.)
wait()	task.wait()
wait(n)	task.wait(n)
spawn(f)	task.defer(f)	task.delay(0, f)
delay(n, f)	task.delay(n, f)
spawn(function () f(uv1, ...) end)	task.defer(f, uv1, ...)	task.delay(0, f, uv1, ...)
delay(n, function () f(uv1, ...) end)	task.delay(n, f, uv1, ...)

[vrs2210]

I forgot, does this do any performance increase with delay and spawn when switiching to task.delay/task.defer?

[VortexColor]

Of course.

The new task library uses an improved polling system.

[AridFights1 (Arid)]

I had a question.

Is wait() really deprecated?
Since then, I’ll change all my waits’ now. Else I’ll replace them later with task.wait

[tnavarts]

@AridFights1

Is wait() really deprecated?

It’s not deprecated yet so that people have some time to naturally migrate off of it before being annoyed by warnings in the script editor, but it will be at some point.

[AridFights1 (Arid)]

Well it does make sense, since wait is the only function that is used the most, so I guess it’s good to give developers some time. Thanks for the reply!

[LightningLion58]

I think there’s a small bug with the autocomplete, as the script editor says task.wait() returns void (nil)

The DevHub says it returns a number:

Is that intentional?

[LucasMZ_RBX (LucasMZ)]

@WallsAreForClimbing

The defer method schedules code for resumption at the end of the current (or next if we aren’t currently in one) resumption point. You can think of it as adding something to the back of the queue of threads we are going to resume.

So does this mean that my analogy is correct? When .defer was released I went by saying “It basically schedules threads to be resumed once there’s no other threads running anymore.” Would that mean that this analogy isn’t actually that wrong?

[WallsAreForClimbing (Climber)]

Almost, but not quite. A deferred thread is resumed when all threads that were scheduled or running when it was deferred have yielded or terminated.

[LucasMZ_RBX (LucasMZ)]

I’ve heard before that Debris uses the older ‘deprecated’ wait/delay, anything I ask forward is dependant if that’s the case, if that’s the case, any plan to switch Debris to use task.wait/delay instead? Is that something that you guys think could break some code? If so, would Debris get possibly deprecated in the near future?

[ATrashScripter (iiATx_Trug)]

you can do this if you want:

local function Debris(waitTime, Instance)
   task.delay(waitTime, function()
      Instance:Destroy()
   end)
end

[LucasMZ_RBX (LucasMZ)]

@ATrashScripter

local function Debris(waitTime, Instance)
   task.delay(waitTime, function()
      Instance:Destroy()
   end)
end

I know I can, that’s why I would expect Debris to be deprecated since it just does that anyway.
I always thought Debris was weird.

Also, even better version of this:
You could add some asserting into this, but this works just fine.

local function DestroyInstanceIn(waitTime, instance)
    assert(
        typeof(waitTime) == 'number',
        "WaitTime must be a number!"
    )

    assert(
        typeof(instance) == 'Instance',
        "Must be an instance"
    )

    task.delay(waitTime, instance.Destroy, instance)
end

[ATrashScripter (iiATx_Trug)]

@LucasMZ_RBX

task.delay(waitTime, instance.Destroy, instance)

I didnt do that because it might error like it does if you try this on remote events/functions

task.spawn(RemoteEvent.Fire, Params)

[BenMactavsin]

@ATrashScripter

I didnt do that because it might error like it does if you try this on remote events/functions

task.spawn(RemoteEvent.Fire, Params)

Yeah, because you’re supposed to pass the RemoteEvent object as the 2nd argument before Params:

task.spawn(RemoteEvent.Fire, RemoteEvent, Params)

[Kizylle]

Has anyone been having trouble using task.spawn in real servers? I don’t mean testing in studio, I mean in real games. I tried switching to using task.spawn not too long after the task library became available and it had what felt like a 40% chance of just not working in a real game in server scripts.
I’d like to know if these issues have been ironed out since this update was last pushed.