Flow Control - Why Aren't These Part of the Base Library

About a year ago I created some custom flow control nodes which I have found to be amazingly useful. At the time they suffered from a few bugs, but as of 4.19.2 they seem to be working without issue. These nodes are meant to read the execution pulses from Event Tick and Axis Events as a stream and process them based on the logic of the node (I’m no programmer so I have no idea if this is a programming faux pas or not).

One example that stands out regarding the utility of these nodes is how easy it is to create charge actions (which has probably been asked over a billion times on these forums) using the FlowChargeUp node. Another example is how these nodes can to create low maintenance complicated button schemes such as: hold R1 to charge, release R1 to fire, but press O while charging to cancel the charge (without it immediately starting to charge again), but press O while not charging to do something completely different. The HoldGate node is another good example that can be used to create things such as multi-button press actions with variable input sensitivity.

I’ve talked about the details of these nodes before over in this thread (some parts may be out of date):


Ultimately my question is why aren’t these kind of flow control nodes part of the base library? They seem incredibly useful and so far I haven’t encountered a control scheme I wasn’t able to replicate using them. Again I should probably mention that I’m no programmer which is why I’m asking here to see if there’s some kind of flaw with this method of blueprinting.



Took a quick peek but not long study. What would you call these… ‘Latent States’ Nodes???
A lot of BP code is driven by the pulse: Interpolation etc. So does it help or work against that…

The first thing that struck me about this was how similar to Electrical-Circuit flows this seems.
But in coding its always a question of abstract-customization or complexity, versus simplicity…
Or how long will it take to get up-to-speed on these new nodes vs building something familiar…
(Albeit fixed). Although, I assume there’s many optimization benefits from execution-blocking…

Like with AI, if you plumb these in, you’re going to have moments of WTF is the code doing? :eek:
But I’m all for innovation. So its nice to see what other approaches people are trying / taking…
Personally, I try to write really Simple-Predictable / decidable-code using the simplest nodes…
Even then I **** it up all the time… These nodes would lead to more of those moments (I fear). :stuck_out_tongue:

However, if this works for you and your projects, then cool, hey why not!
But the risk is always: what if you have to share all your code someday?

Interesting that you would bring up electrical circuits. I do have a background in engineering so perhaps that might explain why I instinctively found this more understandable.

It’s definitely very easy to have moments of “WTF is this code doing!?” if these nodes are used recklessly. Personally I like to keep everything neatly divided into states. I’ve attached a blueprint of what I mean.

Generally I have:

  • “Stuff that happens when entering the state”,
  • “Stuff that the player can do while in the state”, and
  • “Stuff that happens when exiting the state” (I tend to reserve this to only stuff that’s relevant to inside the particular state; sort of a cleanup step).

This blueprint structure allows modification to individual actor states (eg. you could allow the player to throw a punch while in the walking state, but not while in the falling state, and it’s relatively trivial to change it so they can punch while falling). The structure can also be embedded inside itself so instead of just a “Walking” State, you can have sub-states (eg. Walking-Idle, Walking-LightPunch, Walking-HeavyPunch, etc.) and sub-sub-states (eg. Walking-LightPunch-Hit1, Walking-LightPunch-Hit2, etc). Each of these sub-states and sub-sub-states can have “stuff that happens when entering that state”, “button inputs available to the player in that state”, and “stuff that happens when exiting that state”. It should be noted that button inputs available to the player in a particular state are still available to the player when in that state’s sub states. The final point of interest is that even if you are in a sub-sub-state, say the Walking-LightPunch-Hit2 state, it’s trivial to move immediately to the Falling state without having to worry about resetting any variables or timelines as they can just be put in the “Stuff that happens when exiting the state”. A good example is 2D fighting games where a character would need to be able to go from the Crouching-LightHit-Hit1 State to a Hitstun State if they were hit by their opponent.

This is the main way that I use these nodes, but I’ve found other uses for them. I’ve even managed to make an AI tree using this blueprint structure.