[Live] Changes to coroutine.yield


#1

Hey Developers,

Over the coming weeks, we are going to be making changes to the way coroutine.yield works. If you are using this method in your game you could be affected. Below are details on how to update your game to avoid being impacted by this change.

What is the change?

Currently, calling coroutine.yield will (in certain situations) cause the thread to yield for the default wait time, and then automatically be resumed. With this change, we will no longer automatically resume any threads which have yielded through the use of this method. Instead, you must explicitly resume these threads yourself.

Why are we making it?

The behavior in its current form is inconsistent depending on where the method is called.

  • If it’s called from a Roblox thread, it will yield for the default wait time.
  • If it is called from a user-created thread, it will yield the thread until the user explicitly resumes the thread.

We have decided to make this change in order to unify the behavior, regardless of where the method is called. This is already reflected in the developer hub.

There are also benefits which stem from this, such as the following example which allows you to wait for multiple events to complete before you continue running your code.

local function waitForEvents(events)
    local thread = coroutine.running()
    local c = 0
    for i = 1, #events do
        local listener
        listener = events[i]:Connect(function ()
            listener:Disconnect()
            c = c + 1
            if c == #events then coroutine.resume(thread) end
        end)
    end
    coroutine.yield()
end

What should you do?

Those of you who are affected by this change are relying on the behavior where coroutine.yield yielding for the default wait time. If this is the case, then in a few weeks you will start seeing a warning in the output and developer console. To ensure your games continue to function as expected, please substitute these calls to coroutine.yield with a call to wait instead.

When will this happen?

You will start to see the warning if you are relying on this behavior. On the 10th of September (9/10/18), we will enable this change, and the warning will no longer be shown. If you have not updated your games before this time, they could break.


July Recap: Check Out What's Happening in the Developer Community
Coroutine.resume() bug while used in RemoteFunction & BindableFunction
Coroutines and loops: C stack overflow
Custom Event Module
ModuleScripts that yield with coroutine.yield() will break parent thread
BindToClose extended yield w/ coroutine.yield()
August Recap: Last Month in the Developer Community
ModuleScripts that yield with coroutine.yield() will break parent thread
#2

This is awesome! Now we can stop using messy BindableEvents for this sort of thing! It’s nice to have consistent behavior, and now coroutine.yield will stop being near-useless in Roblox.


#3

Nice, good change


#4

Helpful!


#5

Thank you :heart_eyes:


#6

omgyes


#7

Yes!
Thank you!

The old functionality was incredibly confusing and annoying, and not to mention useless because of it.

I look forward to this change!


#8

I dont think I’ve ever needed coroutine.yield for anything, I wonder what is a good scenario for it.


#9

If 100% backwards compatibility is needed, the improved behavior could be implemented as a new function instead. I have some old scripts that may depend on the old behavior (using coroutine.yield() as a fast wait()), but I’m looking forward to this change.


#10

The old behavior was a bug and never documented. I don’t think Roblox should support that and differ farther from vanilla Lua.


#11

We will be enabling this on the 10th of September, please ensure you’ve updated your games before then. I have updated the original post to include this information.


#12

Is that Day/Month/Year or have the Americans gotten to you?


#13

MM/DD/YY to be consistent with other posts we make in this category.


#14

Any chance this could be an opt-in feature before September 10th? I’m really excited for this :slight_smile:


#15

I’ll let you know in a few weeks time, once the warning is being shown.


#16

If you are relying on the old behavior you should now start seeing a warning in studio. Please ensure you update your games before the 10th of September.


#17

Is this warning displayed at runtime, or while opening studio?


#18

The warning will be shown at runtime. You’ll see a message saying you’re relying on the old behavior and there will be a seperate message for each script that’s using it.


#19

This is now live.


#20

Whoops; this broke Farming among Friends. It’s fixed for all three of my players now!