Okay, I will keep this noted and see if I can come up with plausible result.
Majority of Behaviour Tree system is locked behind private/protected implementation so I don’t know how far I can go, but last time I checked this was several engine versions ago. Maybe things are more exposed now, we’ll see.
Awesome! If there is a roadblock, please let me know. I’ll try to file a request to Epic. Cheers!
FSM Blueprints (Components), I am adding a system where you can link Behavior Trees to a particular uFSM State.
You will have to link them from your FSM’s Details Panel, I did not have the time to make visual graphs for these “linked” things.
When you change your “State Tree” array from Details Panel, “State Bahavior” slots will open so you can attach a BT to a particular FSM State…
State will abort given linked BT when that state is exiting, and restart the BT if that State is active again (FSM’s c++ runtime will deal with activating them on enter/exit state changes).
Obviously they will do nothing if the BT is not set or the owner of FSM Component is not a pawn controlled by AI Controller.
For “Action” graphs of a ‘Reactive’ FSM node, I have included these nodes that can be used to control BTs:
https://i.imgur.com/bO9BOQV.png
Wow, so quick! I really appreciate it. Yeah, the better visualization can come later but it looks like it will do what I asked. I’ll give it a try and let you know how it went.
BTW, I read about HFSM being reworked on. Is it still the thing? or just a smoke in a chimney? I’m familiar with HFSM but I haven’t seen a good implementation since Serious Engine days. I also saw Stack-Based FSM in Unreal Marketplace. I really haven’t used it to say it for sure, however, they seem to get the implementation right. To properly implement it, you have to use Stacks to represent the hierarchy.
Why do you want to use HFSM? It can help to simplify FSM quite a bit by sharing States. A common use-case, for example, is Damage. Whether you are in Idle, Attack, Patrol, they will all have to deal with Damage.
If you are using HFSM, you can put the Damage state at the bottom of the stack and push other states(Idle, Attack, Patrol) on top of it. This way you don’t have to duplicate damage handler to individual states. Basically, HFSM allows you to modularize the States by combining several States to create new States. Combining States different ways can give you very interesting behaviors. And this behavior cannot be emulated in BT. BT and HFSM is totally different animal.
Anyway, it’s not super critical but it’s a very sexy feature if you are looking for improving uFSM.
Cheers!
“Reactive State Machine” (RSM) is an Action Stack based Hierarchical FSM system that can be added as a node to any blueprint’s uber graph, including the graphs of a FSM Component, within another RSM’s graph or itself’s graph… and because of that, they can become very complex really quickly however powerful.
You can create ‘Action Blueprint’ classes and add/remove them to customize each Node/State behavior, making the node to be its State and Machine itself.
I haven’t talked much about them because it’s not heavily used on projects I work and I haven’t finished 100% development on them yet, there are points they can be improved;
But I talk a bit about them here:
https://forums.unrealengine.com/unreal-engine/marketplace/88276-ufsm-finite-state-machine?p=1717741#post1717741
https://forums.unrealengine.com/unreal-engine/marketplace/88276-ufsm-finite-state-machine?p=1805517#post1805517
There’s some major game project out there using this system and it’s weird that they know more about it than I do, they have been implemented tons of ‘Action’ blueprints and have these State/Node running everywhere, but I haven’t received any serious feedback yet.
RFSM looks interesting and useful as you can layer actions. It’s more like having multiple Action Components in Stack and I’m afraid it’s not the same thing as having States in Stack.
When people talking about HFSM, they often have different ideas. Most commonly mistaken by nested FSM ( FSM within FSM). It’s a useful concept but it’s not HFSM.
HFSM requires having **States **in Stacks and you should be able to dynamically manage the States in the Stack at runtime.
A simple illustration as I mentioned above can be given by the common damage handler. It works like this. I’ll try to use just Idle, Attack, and Death states to simplify the illustration.
-
First of all, you will need to have BaseState and put common event handler(such as damage in this case). Within this BaseState, you will implement a damage event handler. Damage event handler will react to damage, decrement health, and if the health is below zero, go to DeathState and so on.
-
When first running HFSM, it will first push Start State into the stack. In this case the BaseState.
-
Create IdleState and AttackState. When there is no event, IdleState will be pushed into the stack (now you have BaseState and IdleState in the stack).
-
If attack input is pressed, you will pop IdleState and push AttackState(now you have BaseState and AttackState in the stack). This pop and push is commonly used and we can call it Jump stack or Replace stack.
-
When attack is finished, it will pop AttackState and push the default IdleState into the Stack (now you have BaseState and IdleState in the stack)
As you can see, BaseState is always at the bottom of the Stack so that it can deal with damage event at all times.
An interesting situation is that when damage is received while attacking, the damage handler in the BaseState will send the state to Death. BaseState is at the bottom of the Stack, therefore, it will pop AttackState first. This way, you can have a nice interrupt mechanism as the bottom State can cancel whatever it’s doing on top of it.
In summary, there are two things to implement HFSM.
- How to manage Stack: Push will just add new State to the top of the Stack, Pop will just remove the top of the State, Replace will pop the top of the State and push a new State.
- How to deal with events: events are handled from the top of the Stack to the bottom Stack. Top States always have the first chance to handle the event, and also it can override the bottom Stack event handler.
I hope I explained it clearly. I have seen some online doc that talks about but I can’t find it now. If I find it, I’ll post it here.
Cheers!
I understand what you are saying, but with these nodes, I would do something this:
On Character graph add a “Main” (BaseState):
and within “Base” graph would do this:
The results are the same, what matters is then what “Actions” on each State node will do when that node is ticking (node stops ticking when On Exit wire is called).
In that case “Base” graph is still always ticking while alternating between Idle/Attack graphs and Actions;
Hm… I’m not sure but it looks like Main and Base are independent of each other and it’s more like hardcoding states using programming. Emulating HFSM is not difficult. If you make multiple states running in parallel, in theory, it’s HFSM. But my point is that it’s really difficult to understand what states are running at the same time and how each state related to each other. To make a proper HFSM, we should be able to show the relationship on the diagram. By looking at the diagram, we should be able to see what states are in the stack.
A basic FSM can be viewed as having one level deep Stack and all Transition(wire going from one State to the next State) is just basically Jump state(pop and the push) in terms of HFSM.
HFSM will have more than one level deep Stack and each Transition can be either Push or Jump state. So we need to modify HFSM editor to show the two different types of Transitions.
To explain about HFSM Transition, Transtion can be either Push, or Jump. Also Transition can be tagged if the Transition is will be returned to the previous State (Auto-return Transition) or not. Many State Transitions are temporary for example, Idle -> Attack -> Idle. Attack is a temporary State and Idle->Attack Transition is an Auto-return Transition. Since it’s returned to Idle State automatically(unless interrupted), we don’t have to show a wire going Attack->Idle Transition in the diagram. It will help simplfy the diagram.
The whole point is that we need to do this in the State diagram without resorting to programming or BP graph. Otherwise, I wouldn’t have brought it up.
BTW, is the FSM editor a custom editor? or you are just using Anim BP? If you are using Anim BP, it might be difficult to extend it for HFSM or even adding BT node. If so, I’m sorry for asking for the wrong feature request.
No, I don’t want to use custom graphs.
Once they are added in, the possibility of having undetectable bugs is exponentially bigger than just let the engine do its default thing on Details Panel.
I cannot afford that possibility, I need the component to be solid even though isn’t pretty.
I see. Although uFSM is really nice, I’m looking for an asset that has a custom editor as I need it to be extended. Thanks for the discussion, I hope one-day uFSM evolved into what we discussed above. Cheers!
I’m no longer allowed to create states without using an ENUM inside of BP FSM components. Is this intentional Bruno?
No, I always use enums so I forgot to mark a “true” boolean when there’s no enum and the list has changed,
I will send fix tomorrow.
Just to note: that issue above was already fixed and Epic published the update on Marketplace earlier this week.
Will submit this weekend v3.1.0 for Unreal 4.26+.
There’s only a few changes to “Async” nodes:
- Removing “Loop” option from Async nodes that do not require callbacks.
- Async nodes with callbacks retain a “Loop” option, but they now introduce another delegate transporting a reference to generated timer handle.
- You can cancel the loop by invalidating the handle with a “Clear and Invalidate Timer by Handle” node.
Thanks Bruno! You’re awesome
https://forums.unrealengine.com/core/image/gif;base64
Epic’s update system is failing to detect changes to source code.
I had to delete the 4.26 version to force an update, so plugin for Unreal 4.26 will be unavailable to download for a while until they solve this.
It’s bizarre, looks like they are checking package changes by counting bytes on files. This is inaccurate for c++ plugin updates.
[HR][/HR]
Edit:
Changes already processed.
Thank you Marketplace staff!
Hi Bruno, I think I found a bug. I created an FSM component, added a BP enum with two states (movement and jump), generated the functions, and attached the FSM component to the BP character. The bug appeared when I added a new state to the enum. The component automatically added the new state to the State tree array but the new state cannot be found by the FSM: Set State function. To make it work, I had to delete the FSM component and attach it again.
It seems to work fine if the states are added manually/directly in the State Tree array (and no BP enumeration is used at all)
Edit: 4.26 version
The attached component is a spawned object (instance of FSM class).
The FSM blueprint is a “template”.
When you save changes to the template, its serialized data will not necessarily move over to the attached component if that property is dirty on the instance, it’s a serialization thing of Unreal Engine.