Coroutine support will be overhauled and completed in Bolt 2. While the current coroutine system is already very capable (e.g. waiting in loops, etc.), there are still some rough edges.
Ports defined as Control Roots will have an option that enables them to be treated as coroutines. Control roots include the Trigger port on any Event, along with some other ports like Completed on Cooldown and Timer. Currently, the latter ports cannot be treated as coroutines in Bolt 1, which is what this change will fix.
The control ports on Super Units, Graph Inputs and Graph Outputs will have special handling. Whether they are treated as coroutines will depend on the port definition, not the port setting.
With the additional information available at the port level, the graph analysis will be able to determine whether a unit that requires a coroutine flow (e.g. Wait) is connected to a non-coroutine control root, and in this case, show a Severe warning, because a crash is inevitable.
This refactoring of the analysis would also be a good opportunity to attempt to traverse super units recursively when doing analyses rather than taking them as black boxes.
Bolt 2 will include a new Create Coroutine unit, which will have a similar design to Handle Delegate. Instead of returning a delegate however, it will return an IEnumerator that can be passed to any of Unity’s coroutine API methods. This will allow for creating coroutines that are not started immediately.
A new Current Coroutine unit will be provided. It will return the underlying Coroutine object of the executing coroutine on the current flow, in case users want to perform advanced operations with the Unity API (e.g. StopCoroutine) later on. A common use case will be to assign that object to a graph field instantly after having fetched it.
Bolt 2 will include a new Wait for Operation unit, which takes any Unity AsyncOperation (e.g. scene loading, web requests) as an input.
Bolt 2 will include a new Parallel unit, which will have a similar design to Sequence. The difference is that every control output will be started as a coroutine simultaneously instead of one after the other.
A new option will be provided at the flow graph level to automatically stop all coroutines started by that graph once it stops listening (default true). This means, for example, that any machine that gets disabled will stop executing its coroutines. More practically, it fixes a common design problem of State Transitions using the following pattern: