Exit point for branch node?

Temmy 4 years ago updated by Lazlo Bonin (Lead Developer) 4 years ago 4

I want to continue the flow whether condition is true or false.

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

Just ensure that both flows end up at your destination. While a Control Flow output can only go to one other node, a Control Flow input can be from any number of sources.


I know this. I am not sure you understood me. I mean something like this

so after the condition is checked, I can continue the programming from the branch unit.
 I could use a sequence like this

but it is much longer and inconvenient. Also I feel this should be standard for all units except data nodes ofcourse. Most visual scripting programs like nottorus have it and i used to programming like this. Sounds like a simple feature request, maybe this should be moved to the ideas section


Sorry, it is a bit hard to know how much a person knows from the request.  I took a guess and was wrong.

I suspect that Bolt favors the simpler form as it, well, favors simpler nodes and leaves complex nodes up to super units and custom nodes.  Most users would probably never miss the Next control path, as they can just do as I mentioned and never think twice about it.  This helps prevent users from shooting themselves in the foot by accidentally double wiring code on the conditional triggers and the "Next" trigger.

However, this sort of thing is the sort of thing that we can solve for ourselves.  Drop this in your project, regenerate your unit options, and you should get a "Branch Next" node under Control, right next to "Branch".


That said, there's nothing really wrong with your super unit, as it solves the problem and you never have to think about it again.  You can go either way

*disclaimer*  I'm still new to creating custom units.  It is entirely possible I messed it up.  I can only test on Windows, as well.


Hi Temmy,

Thanks for the suggestion! However, I agree with Reality.Stop(), and I won't be implementing a constant output port on every node in the future. The correct approach is to connect both output ports to the entry (which is allowed for cases like this), or indeed to use a super/custom unit to do that in one go if you'd prefer