Wait Until And While bug?

Crystalius 3 years ago updated by Garnette 2 years ago 14

When I use Wait Until/While and flow is constantly flowing to them, game's fps drops like 80%. 

But when I use Jason's Wait Until/While Loop there is no loss of fps. 

Is this a bug or is it by design? Are those units supposed to be triggered only in one shot? In one flow shot there are no issues.


Bolt Version:
Unity Version:
Scripting Backend:
.NET Version (API Compatibility Level):

Well you just need to know how to use them. Constant flow will stack up coroutines and kill performance. But making gaps will reset them, if I am correct, and all should be fine

Satisfaction mark by Crystalius 3 years ago

Mine simply have a thing to block it, that's what the the toggle async is for. The regular naturally just throw off a coroutine every time it's entered. The future updates will introduce new stuff that will allow more choice. 

Thanks😊 With your addons I feel like I am in Bolt's future a little bit 😀


Thanks! it's an extremely fun thing for me to be involved in. A lot more interesting things coming!  Enjoy! 

Fixed in Alpha

In version 1.4, only one coroutine will be started at the event level, not one coroutine per wait unit. This should improve performance and reduce memory allocations.


Using 1.4 but Wait Until and Wait While still kills performance until unplayable after a while. 

How should I use them in Update loops? They are needed because they lock flow and happen instantly when condition is correct. Branches only happen every flow which takes time to activate something and it doesn't work when very high speed is needed.


Correct me if I'm getting your problem wrong.

Update will always fire every frame. Nothing you can do about that. Your lag comes from infinite firing of new coroutines. The events create a brand new instance of flow, every unit entered from this new instance, with the exception of super units (graph variables) is brand new. They no longer retain it's state.

So you are using wait in an update, and that new flow instance is the only one that is waiting if the conditions to reach the wait are met. Any incoming flow will be essentially getting the same results stacked over and over.

Since you can't stop update from sending another flow, you can place a branch and on right before you hit wait, change a bool variable (graph) 'canFlow' to false. After wait change it to true.

If stopping update while waiting is what you want, you'll get the intended results, and no more slow down.


Here is actually how you would do it. A little tedious if you had to do it everytime, but if you make macros for these, it will just be automatic. We store this variable in a list, because a list can retain information. A bool itself passed down, is just a value. We don't have access to the units graph variable, but in this way we can still modify them,

Inside 'Wait Update':

Inside 'Wait While Pause Update':

if you'd like the macros, I uploaded those two.


Thank you! That should work for me.

But your plugin's Wait Until/While didn't stack over even without enabling Async, if I remember correctly. 

I wonder  why Lazlo don't want to take those units from your plugin:(

Instead of 1 unit now people need to use 14


Lazlo can correct me if I'm wrong, but that is actually not even possible anymore, since units don't contain state. Before I'd have a variable that stores every instance running, and determine if it has any, therefore we can't run it. All done inside the unit.

But since units don't retain it's previous data, another flow enters as if it's a whole different unit. So that information isn't the same as the other instances you entered. Therefore it has no knowledge it's ever been entered in the first place.

I don't think it's so bad, you only ever need to do the work once, and can infinitely repeat with macros. Plus you gain more control over how the flow actually happens.

Looks like I can do all I need with branches without Wait While/Until so far. I probably just used them in a way they are not supposed to be used for.

I had trouble now which Wait Until fixed and performance stays good. Probably because there are gaps in flow. I guess those gaps resets this coroutine and thus cleaning it. 

In places where constant flow happens into Wait Until/While, performance dies


From what I understand, you're not using Wait Until / While for their intended purpose.

You should not input continuous flow (e.g. Update, Fixed Update, etc.) in the entry port. You should only input "punctual" (e.g. On Mouse Down, etc.) one-time flow.

If you are using a continuous flow, all you need is a Branch that checks the condition. 

Wait while / until are useful specifically for when you're not on a continuous flow, but want to delay the execution of the rest of your graph while/until a condition is met. This is because the wait while / until runs on every update after being entered and fetches its condition every time, as part of the Unity coroutine loop.

Let me know if that makes sense!

Yeah. Everything is great. They just need little breaks between flow to not stack up.