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
does this help out?
2 Likes
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. 
2 Likes
had to go on google to find it, came up as the second result
I wonder when it will become searchable
2 Likes
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
2 Likes
Will core scripts get updated to use this library anytime soon? There’s usage of legacy wait,
spawn, delay in them
2 Likes
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.
1 Like
Could someone do a before and after in performance, so i can see how much the task library actually helps?
1 Like
I’m really loving the modernization of the lua language, great work team
1 Like
Are there any thoughts about this issue? I do not feel safe using the task library because this makes it very easy to leak threads or have obscure bugs. Would like to know if there is any talk about changing it or if it will definitely not be changing.
1 Like
We’re looking at fixes for this. It won’t be until the new year now, but I’ll be sure to leave an update when we have one.
3 Likes
Really good job Roblox! Is there going to be more functions to the library.
Is task.wait or this module better : Custom wait - the best solution to yielding!
1 Like
My module is meant to fit for niche usecases where you need to have hundreds of accurate yields managed at once; in 99% of the usecases, you should use task.wait.
I released the module because I had the misfortune of having to optimize a very laggy codebase in a very short period of time, whose issues stemmed from having an absurd amount of wait calls.
2 Likes
I see thanks for answering me.
2 Likes
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.