Task Library - Now Available!

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.

3 Likes

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!

1 Like

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

The DevHub says it returns a number:

Is that intentional?

1 Like

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?

2 Likes

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.

5 Likes

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?

4 Likes

you can do this if you want:

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

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
2 Likes

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

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

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

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

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.

1 Like

Is this library still in an early release stage?

If not, it’d be awesome to get it on the wiki with a better explanation of the more in-depth diagrams that we saw in the beta post. I couldn’t seem to find it via the search function on the site.

Edit: Forgot to mention how much I’m loving using this task library. Finger-saver, no more RunService.Heartbeat:Wait(), improved functionality (and efficiency), and a removal of unnecessary RunService GetService variables (for the sake of continuity).

1 Like

https://developer.roblox.com/en-us/api-reference/lua-docs/task

does this help out?

1 Like

Yes! Thank you very much. I think the page could still use the explanation from the diagrams when the task library was in its beta stage.

I guess it’s not a page that’s easily indexed. :confused:

had to go on google to find it, came up as the second result

I wonder when it will become searchable

1 Like

Previously, I think it actually did work even after script deletion, but someone filed it under engine bugs somewhere, so it was fixed.
Edit: found it (I think) task.wait() does not respect script.Disabled and always resumes - #6 by ZeezyRed

Will core scripts get updated to use this library anytime soon? There’s usage of legacy wait,
spawn, delay in them

1 Like

Overtime we will transition to the new methods but since the existing ones will continue to work despite their deprecation there is no need to update them immediately.

Could someone do a before and after in performance, so i can see how much the task library actually helps?

Idk if it was intented or not but…

Using task.wait in a disabled script with a while loop keeps running
Meanwhile wait properly works

Output:
image
image

1 Like