This doesn’t exist in vanilla LUA and would have to be implemented by ROBLOX directly.
This would yield the current thread until the specified coroutine function is resumed by a separate thread.
It would turn this code:
local c
local function Wait()
local bindable = Instance.new("BindableEvent")
local args
local function x(...)
args = {...}
bindable:Fire()
end
c = x -- simulates adding x to the table of Waits to call when an event occurs
bindable.Event:Wait()
return unpack(args)
end
spawn(function()
local secret = Wait()
print(secret)
end)
wait(2)
coroutine.resume(coroutine.create(c),"hi")
Into this:
local event = coroutine.create(function()
return select(2,coroutine.yield())
end)
spawn(function()
coroutine.resume(event)
--later on
local secret = coroutine.yieldwait(event)
print(secret)
end)
--to fire
wait(2)
coroutine.resume(event,"hi")
The only way you could make one via script was using the RbxUtility library, which was deprecated and deleted recently (including the LoadLibrary function).
Unless you are referring to using a BindableEvent?
Your code could be simplified to the following in order to function in vanilla Lua.
local t
local function Wait()
local t = coroutine.running()
return coroutine.yield()
end
spawn(function ()
local secret = Wait()
print(secret)
end)
wait(2)
coroutine.resume(t, "Hi")
Unfortunately, the Roblox scheduler will attempt to resume certain threads automatically. As such yield behaves as wait in many places. I spent some time during summer looking at just this problem, I believe I found the problem and implemented a fix but somebody else would need to take this further.
This feature request makes a lot of sense, but I instead decided to design my game in a functional signal-based way that avoids yielding and spawn/coroutine.wrap all-together. You might want to try the same thing. If delays are needed I use a custom scheduler.
I haven’t had any issues thus far with this. Upon creation of a new thread and coroutine.yield()ng in it, the thread will yield appropriately and with a reference to it via coroutine.running I can resume it fine.
EDIT: On a side note, coroutine.kill(thread) would be great!
coroutine.yield being broken was intentional? There’s no way to yield for other threads without yielding for the next frame now. Why would anyone want coroutine.yield to behave exactly like wait()?
A useful feature was removed because it didn’t match documentation. Why not just update documentation?
coroutine.yield pushing the thread to the back of the stack is important for timing certain things. For example if the parent of an object changes and you want to immediately change it to something else, you now have to wait an arbitrarily long amount of time (however long a frame takes) before you can perform that action. With coroutine.yield in working order, that operation is simple and easy to perform in a single frame.
Generally, I want full control over what order my code is executing in. With a broken coroutine.yield, my only option for performing operations like that is to just toss the thread onto the next frame, where it gets executed in whatever order roblox decides on. The less control I have, the more problems appear due to unknown behavior within the engine, and the more time I have to spend diagnosing and working around these problems. In this case, there isn’t a workaround at all.
Oh, I wasn’t aware that RbxUtility was deprecated. It would be intresting if ROBLOX allowed for custom Signal creation, as Signals are pretty useful in general.
I’m normally against ROBLOX modifying vanilla Lua functions and the same is true for this feature request. I think that fixing the behaviour described by @woot3 is a far better fix than introducing a new function.
Something I just realized:
wait(2^127) would act exactly like this (you can resume the thread as though that paused it - and to get the current thread you would just use coroutine.running())
Example usage to create an event:
local args
local create = coroutine.create
local resume = coroutine.resume
local unpack = unpack
local huge = 2^127
local thread
local function Fire(...)
args = {...}
resume(thread)
end
local function Wait(timeout)
thread = coroutine.running()
wait(timeout or huge)
if args then
return unpack(args)
end
end
spawn(function()
wait(1)
-- fire thread after 5 seconds
Fire("hi","after 5 seconds")
end)
wait(0.1)
print("hi","before wait")
print(Wait())
Issue is when the wait() finishes running, it will throw an error if the thread has been resumed (signal fired)
I don’t think it matters, but does anyone know a way to avoid it?
You’re going to run into some serious bugs doing this.
local t = coroutine.create(function ()
wait(2)
print(coroutine.yield())
end)
coroutine.resume(t)
coroutine.resume(t)
wait(2) will be resumed by the second call to coroutine.resume and then the call to coroutine.yield will be resumed ~2 seconds later by the Roblox scheduler. I advise against this completely if you can’t ensure the wait time is longer than the expected lifetime of the thread.
I don’t think what you’re saying is true because wait() only works in roblox threads - where coroutine.yield() doesn’t (and acts as wait()) - and it will also convert all threads it is in to roblox threads (so your coroutine.create() will be converted to a roblox thread - and hence coroutine.yield() will act as a wait())
But yea wait can definitely be unreliable if you’re working in coroutines and will need to yield later. However, for my use case it satisfies it (trying to make my own RBXScriptSignal).
Edit:
local args
local create = coroutine.create
local resume = coroutine.resume
local unpack = unpack
local huge = 2^127
local thread
local function Fire(...)
args = {...}
resume(thread)
end
local function Wait(timeout)
thread = coroutine.running()
wait(timeout or huge)
if args then
return unpack(args)
end
end
spawn(function()
wait(2)
-- fire thread after 5 seconds
Fire("hi","after 5 seconds")
wait(3)
print("yayyayay")
Fire("hi","after 5 seconds")
end)
wait(0.1)
print("hi","before wait")
print(Wait(3))
print(Wait())
Just discovered this (not sure if it was what you were saying and I just misinterpreted), but it turns out that past waits will mess up future ones.
I would appreciate it if you tested my code before assuming what it does in future.
Calling wait inside of a coroutine will add it to the list of yielded threads in the roblox scheduler, after the time has elapsed the thread will be resumed. Upon its next yield the scheduler will review the reason for the yield and make a decision. Specifically in the case of coroutine.yield the scheduler will add it to the list of waiting threads with the duration for resume being the minimum wait time.
The code I have given you will indeed be added to the roblox scheduler. The scheduler however won’t see the second call to coroutine.yield since this happens before the 2 seconds elapse, all it knows is that the thread is yielded and needs to resume after 2 seconds.
I am suggesting that the error you are seeing, you won’t always see. In some cases it’ll actually resume another yield.
It’s not ideal to shove undead threads into thread scheduler forever though; they won’t get garbage collected and may result in memleaks (esp since they may contain a large stack).
I did try this code, I got confused by the fact that you were using wait() in a coroutine and then yield after - something that doesn’t work (it produces the same results as just having one resume):
local t = coroutine.create(function ()
wait(2)
print(coroutine.yield())
end)
coroutine.resume(t)
--coroutine.resume(t)
But I think I understand what you’re saying now.
Also @Shining_Diamando, this is a stack of size 100 with 10,000 different yielded wait threads concurrently and I don’t lag at all:
local resume = coroutine.resume
local create = coroutine.create
local huge = 2^127
local wait = wait
local function makeStack(x)
x = x or 1
if x > 100 then
local thread = create(function()
wait(huge)
end)
resume(thread)
resume(thread)
else
makeStack(x+1)
end
end
for _=1,10000 do
makeStack()
end
You can try changing the numbers and it will still work (there’s only an initial delay of actually creating everything in 1 frame / however ROBLOX does it (idk))