Task Library - Now Available!

Updates Announcements
,
#130

Awesome!. Now I can’t wait for Roblox to add more pcall(), and a few other things in Lua Globals and Roblox Globals.
Hope so!

#131

Adding onto this: does task.defer add some performance benefit over task.spawn / spawn / coroutines? Since it’s stated it doesn’t care for exact timing and all.

1 Like
#132

Changing the parent of an instance during a parent change operation will result in the following warning being shown and the parent remaining the same.

Something unexpectedly tried to set the parent of <Instance> to NULL while trying to set the parent of <Instance>. Current parent is <Parent>.

When signaling behavior is set to immediate (the default), ancestry changed events fire during the parent change operation so running the code in @tnavarts’s example, where ‘Destroy’ is called directly, will produce the warning above.

By deferring the call to ‘Destroy’, the parent change happens after the parent change operation but still within the same resumption cycle (so almost immediately).

The code doesn’t run immediately but will still be processed before the engine can move onto its next step. It’s not really any different other than it doesn’t block the code which is currently running.

5 Likes
#133

whats the advantage over coroutine.wrap?

1 Like
#134

I think you should rather replace the behavior of the old wait() with the new task.wait()

#135

Isn’t this a bug in Roblox which should be fixed?

#137

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.

3 Likes
#138

I see no need for this at all
task.wait() is fine as it is, besides if wait() is deprecated then it WON’T be updated anymore, it is still going to be useable so older games don’t break

#139

I don’t think it’s all evil in all honestly. I use spawn() mainly for its task scheduler functionality which helps performance a lot in looped events such as character leg movement replication, bullet replication and stuff which doesn’t need to be ran instantly

#140

@WallsAreForClimbing and @tnavarts, looking at the spec provide for task.wait() and docs for wait() you can see they do not return the same number of parameters. wait() returns the duration and the total game time, whereas task.wait() is only returning the duration. Devs should be aware of this difference when updating their code.

Is there any reason to not make task.wait return both parameters?

Below is the last 4 lines of the current Character.Animate script for reference. You will get unexpected behaviour assuming they are equivalent and just replace wait() with task.wait().

while Character.Parent ~= nil do
    local _, currentGameTime = wait(0.1)
    stepAnimate(currentGameTime)
end

changing to task.wait(0.1) will not give you the expected results:

while Character.Parent ~= nil do
    local _, currentGameTime = task.wait(0.1)
    stepAnimate(currentGameTime)
end
3 Likes
#141

Does this mean that task.wait() has a minimum time of 1/60 instead of wait()'s minimum time of 1/30?

1 Like
Wait Faster Than 1/60th of a Second
#142

Much less than 1/60 in fact!

game:GetService("RunService").RenderStepped:Wait() 
print(task.wait())  --> 0.00097130000000334

If you task.wait() during the Heartbeat part of the frame, then it will wait until the next Heartbeat (roughly 1/60), but if you task.wait() in an earlier part of the frame (such as on RenderStepped), it won’t even wait a full frame, it will unsuspend on Heartbeat of the same frame.

For reference, a frame works like this:

image

16 Likes
Wait Faster Than 1/60th of a Second
#143

Are you sure about this? If you create a LocalScript, do task.spawn(function() while wait(1) print(1) end), and then delete it, it will stop printing.

2 Likes
#144

Very much yes! Is this a solution to deferred events? Will this allow Parallel Luau to exist without breaking all event-handling code across all existing games?

#145

Are you able to disconnect task.delay? I want to disconnect task.delay if a certain condition is met so it doesn’t run and I’m having trouble doing that.

#146

Can’t you just add an if statement inside the function passed to task.delay and check if a certain condition met like that?

#147

This is what I’m trying to do basically. Say you press the F key, it will turn the part red, then after 0.5 seconds, it will turn the part green. However, if you press the F key while the part is red, then I want it to disconnect the current task delay, and add another 0.5 seconds of wait time before the part turns green. I can’t think of another solution, I’m probably missing something obvious, any help would be appreciated.

    local conn
    function TurnPartRed()
        if conn ~= nil then
            conn:Disconnect()
            conn = nil
        end

        Part.Color = Color3.fromRGB(255,0,0)
        conn = task.delay(0.5, function()
            Part.Color = Color3.fromRGB(0,255,0)
        end)
    end
#148

You can add a variable that stores the last time F key was pressed then check if current time subtracted by the latest F key input time is bigger equal than 0.5:

    local conn
    local LastFKeyPressTime = 0
    function TurnPartRed()
        if conn ~= nil then
            conn:Disconnect()
            conn = nil
        end
        
        LastFKeyPressTime = os.clock()
        Part.Color = Color3.fromRGB(255,0,0)
        conn = task.delay(0.5, function()
            if os.clock() - LastFKeyPressTime >= 0.5 then
                Part.Color = Color3.fromRGB(0,255,0)
            end
        end)
    end
3 Likes
#149

Thank you that works perfectly! Although my micro-optimisation brain tells me there should be a way to disconnect or stop the task.delay because a lot of them could build up. However this solution is good, wouldn’t run into any issues with loads of task.delay functions being called anyway. Thanks ;D

1 Like
#150

You normally do this with a cancellation token:

local doTheThingNumber = 0
function DoTheThing()
    doTheThingNumber += 1
    local thisDoTheThingNumber = doTheThingNumber
    task.delay(0.5, function()
        if thisDoTheThingNumber == doTheThingNumber then
            -- Do the thing
        end
    end)
end

You can even wrap the whole pattern in a higher order function (function that returns another function) if you’re going to be using it a lot:

function SingleDelayedFunc(delay, f)
    local token = 0
    local function handler(myToken, ...)
        if myToken == token then
            f(...)
        end
    end
    return function(...)
        token += 1
        task.delay(delay, handler, token, ...)
    end
end

local doTheThing = SingleDelayedFunc(0.5, function(arg1, arg2)
    print(arg1, arg2)
end)
doTheThing(1, 3)
doTheThing(4, 5)
7 Likes