UFSM: Finite State Machine

In example project the “Input” BP goes towards that direction.

The character BP only sets a state based on player input.
Jump key will jump otherwise it will double jump depending on current active state, that’s what I was referring to.

But you are setting a bool (DJump) in your double jump state and checking against it in your jump state and then unsetting it again on land. Having to keep track of bools being set and unset surely goes against the FSM philosophy no? All code should be compartmentalised and slotted in when in that state. Otherwise you end up with dependencies all over the place which is essentially spaghetti code once again.

Again, I’m prepared to admit I’m not understanding something here but I still don’t get it.

The ONLY reason that boolean exists there is because the Animation Blueprint needs it, it’s cheaper to check for the bool than the AnimBP query current state every frame:

That bool has zero effect on state logic in the RSM graph.

OK, I’m sorry if I’m coming off as obtuse but you’re not really helping me understand how RSMs are working with FSMs in any way. Your FSM system makes sense in that, what state an FSM is in is what is active. Typical FSM stuff - great. But the RSM seems to have all it’s “states” running concurrent and so the state machine isn’t really active at all. Your character controller is just sending input information to your RSM. You say the logic isn’t controlled at all but isn’t this logic for jumping? Anyway I don’t want to get caught up on that… My question is really about trying to understand how RSMs fit into the equation because how I’m looking at it, it doesn’t look like there’s a state machine going on here at all? FSMs yes, but the RSM is just all the states running at once?

Again, sorry if I’m coming off as terse or rude but I just don’t get it…

That’s an “Action” graph. Maybe you are confusing actions with states?!
In RSM node the state is the node itself, it is a “reactive system”.

Actions are executed as a queue, until you call an exit point, getting the “flow graph” to move to next state/node graph.
For example, “Aim” in this case is its own state and while it is active, player will not be able to jump because there’s no “Jump Action” in its action list:

OK that’s interesting. Yes you’re right I was confusing actions with states. I’ll dig into this a bit more tomorrow but this is promising. Thanks.

Keep in mind that you can create FSM blueprints and add these “RSM” nodes to the FSM graphs as well.

Ok I think that’s probably exactly what I’m after. One thing I’m a little stuck on is creating these nodes. I’m choosing New Reactive State Machine and setting the machine class to my RSM Input that I created. This, however, doesn’t produce an RSM Input FSM object reference, it instead (probably obviously) creates a Reactive State Machine. What am I missing here?

If you see in demo project, there’s action base classes in asset browser.
You can right click asset browser and create as many more “Action” classes as you want.
It’s a bit confusing at first, but everyone soon enough understands the usage pattern:

When you add a node to a graph, you can define the node’s RSM base class + add there in its details panel the action classes you want the node/state to execute (edit: select the RSM node and go to its details panel):

** Then you have to recompile the blueprint once you’ve made changes a RSM node.
** Also always define unique “Machine Name” for each of your RSM nodes.
** I do not recommend using the “Machine Class” for multiple instances of same Character class, because your brain might have trouble tracking execution flow for each, I’d rather use 1 machine class for 1 specific graph to save my sanity… [HR][/HR]
And then you can code “Action” graphs as if their were little pieces of logic regardless of who is the actual Actor these actions are running on.
Once you have a library of actions, you can share them among any RSM node you might see need some specific actions.

Yep this I got, the issue was that when I create a new node (right click the blueprint editor, “New… Reactive State Machine” and then change the Machine Class to the RSM_Input (or whatever RSM I’ve created), the FSM node from that node is not of RSM_Input type, instead it is of Reactive State Machine type, regardless of if I compile or not. I literally just fixed it by restarting the editor but I suspect that that is a bug?

Hmm… I have never experienced that behavior.
I will have to check that, I have been using these nodes everyday and didn’t notice that.
Do you mean the output “FSM” pin from the node isn’t changing its type after you compile the BP?

Although you can still cast to correct class, that should not happen.
Because in c++ I do the casting already.

Yep exactly.

I’m on editor 4.25 with the latest version of the plugin also.

But you’re right I can also cast and that is fine. I can use that for now, thanks.

Hi, I just find out about this plugin and it seems like it’s only FSM that is actively being developed. I used to use BT and FSM together and I’m wondering if you can run different BT on entering different States. This way you can manage BT much easier(run specific BT depending on State) instead of having one giant BT that does all. I’m asking because I saw you can set FSM state from BT but not the other way around. Thanks.

I don’t think Epic has any API that allows BT manipulation from the outside… last time I tried, everything in there was private/protected.

I see. I guess I’ll be ok with just calling AIController->RunBehaviorTree from FSM or something. FMS is provided AIController, it might be feasible, no?

Yes that can be done from BP graphs easily.
Deeper integration from C++ is what isn’t very friendly to get.

Right, anything is pretty much possible from the graph. What I was originally asking was if it’s possible to be integrated into the FSM editor so that changing BT is easier and it will help both debugging and visualization easier too. If so, it will become a super powerful tool. ^^

I like to clarify why having both BT and FSM to work together can be a very powerful concept.

Both BT and FSM have their own advantages and disadvantages.

FSM is good for representing overall AI (large granular) states such as Idle, Attack, Flee, Patrol, and stuff.
And it’s up to the user to implement what each state states do.

BT is good for implementing specific AI task(fine granular), like Attack(a state) behavior. Having a BT to represent many behaviors(states) in a single large BT can get out of hands very quickly.

Therefore, using both FSM and BT together can complement each other very nicely.

I’ve used such system (Nodecanvas Unity) for good success.

If we can call “RunBehaviorTree” directly from UFSM, it will allow us to work with BT and FSM as I suggested.
The attached image shows some states (Patrol, Attack) is just calling BT from Nodecanvas to give you some ideas.
In other words, a state can be represented by BT.

I hope it makes sense.

Do you think we can add a node that calls BT in UFSM? If so, it will make UFSM very valuable and I would really appreciate it.

@ChrisK I understand what you’re saying, but what would be the difference if you use the already existing “Run BT” node from within a uFSM “On Enter” state function ?

What would be the necessity for C++ integration which that above cannot achieve…
I mean, the node already exist in Blueprints engine. What exactly is the path you see could be better?

I guess the difference is that you will have to write such functions every time you call BT. The function has to make sure it stops previously running BT when entering a new state and also to stop the current BT running when exiting the state. It adds quite a few steps and error-prone. And visually it’s not clear if it’s calling BT looking at UFSM diagram. You will have to open the graph to search for it.

Having a special BT node to FSM will automate these steps and it’s much cleaner and visually easy to track what’s going on. I’m wondering, how hard is it to add a custom node?