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.
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.
