So, a little correction to my video. I said parent states could run tasks even if not selected which is not true (at least it's not true now with 5.3.1). They won't run if they're not selected. Only selected states can run tasks now. Use selection behavior to decide wether or not a state can be selected if it has children.
This might just be different in Mass State Trees but from what I have tried: Enter State still runs when you use "Try Select Children" but Tick doesnt. If you want the Tick function of a non-leaf state to run you have to use "Try Enter" instead. Or have you noticed a different behavior?
The "Finish Task" node seems to be a bit misleading / confusing as to what it actually does based on its name and description. I created a bunch of tasks and added them to a state and found that basically no matter what I do it seems to finish the state after the first task in the array finishes. Which made adding multiple tasks in a "sequence" seem not possible. Then I realized how State Trees work, there is no execute task event to override in the task and there is no "Finish Executing Task" function either. The "Finish Task" function doesn't just finish the task itself, it also finishes the state. The event to execute the task is actually just an event that runs when entering the state. The way it works is very weird as typically a task involves an execution and finish execution and are often asynchronous, but with state tree you shouldn't call "Finish Task" unless you want the actual state to finish. So if you add a sequence of tasks that doesn't finish the state until the last task finishes, you need to make sure you only call "Finish Task" when the last one completes. This confused me at first coming from Behavior Tree. Also makes the developer have to be careful about where they use the "Finish Task" function, making sure to only use it for tasks that actually finish a state. Which seems to make it harder to setup really generic tasks. Instead I do wish tasks worked more like BT tasks and we had more flow control over the tasks for a state, similar to composite nodes from BT. Either that or they decoupled tasks from states a bit more and allowed you to add a specific transition based on if a specific task from the state finished successfully or not.
Thanks for the info. I didn't realize the Finish Task basically finishes all tasks because I was using just one task per state. Good to know, and yeah i agree, tasks flow is not very robust yet. It works well if you just stick to one task per state but doing something more complicated still feels experimental. Let's hope we see some more additions in 5.4
@@MrKosiej I’m hoping Epic continues to make improvements to State Tree as well, because as you said some aspects are not as robust yet. I have created souls-like boss AI with BT and my solution was to mix a finite state machine made in blueprints with BT so that I could have more precise control of the AI behavior while still being able to use tasks. But State Tree mixing a finite state machine with BT tasks has the potential to be the only solution I need. State Tree just isn’t as fleshed out as BT yet. So I’m looking forward to the future development of State Tree.
Thanks for this - question. How now do you set a task as running? It seems to default to succeeded. The problem is the enter state event is run over and over again for my tasks. Tick is never called. The state completed 'completion status' enum has a running possibility, but I can't seem to set it as that.
I figured this out - if on EnterState you use the node FinishTask as either succeeded or failed, then Tick is never called because the task is completed.
Excellent video and very useful information about StateTrees, specially given how very little documentation is available about it. @MrKosiej, one thing that I couldn't figure out is how to store state in between tasks (for example a given task sets the value of a variable that is used by that same task again the next time it runs, or maybe by another task in the three). I know I can probably use the actor associated with the context and store everything in it, but I think it would be cleaner to keep these variables inside the tree itself. I've tried using bindings, but for some reason I can only read from bound variables, never write to them. Do you have any advices in that regard?
Sure. Make a new class of type object and use it as a place to store your variables. Make a new class of type state tree task that will construct and save that object to a variable, change its category to Output. Put this task in global tasks in your state tree. Now you can bind that object to any task in your tree and from any task you can access this object and change the stored variables. This will run per instance so every tree will have its own "store", and you can have multiple stores of multiple types if you want. That's probably the closest we can get without an official data management system in state trees from epic.
Oh, that's a good idea! I was hoping epic would have provided a proper way to do something like that, like the blackboard in behavior trees, but I think your suggestion will work pretty well for what I need (and is kind of a blackboard anyway). Thanks @MrKosiej !
@@MrKosiej I had an idea about this topic that seems to work (although I haven't done extensive testing yet) and I though of sharing it with you. Here's what I did: - I moved my StateTreeComponent to the AiController as the BrainComponent (previously it was on my characters) - I subclassed AiController and exposed a UProperty of type UBlackboardData so I can configure it in the details panel of my AIControllers - Then, in the OnPossess method of my controller, I call the method UseBlackboard and pass the asset. That will automatically instantiate a BlackboardComponent on my AIController - Finally, I changed the context of my StateTrees to be my custom AIController. That way, I have access to both the character itself if I need (through the controlled pawn), as well as the BlackboardComponent, so I can read/write any variables I need I know someone may ask why not storing the variables (or the blackboard data) directy in the actor or whatever, but I like to keep AI related variables in AI related components, and I think keeping everything in the AIController makes the character slightly less coupled to the AI.
@MrKosiej, did you manage to understand how to work with animations inside the state tree? on Unreal documentation it says that State Trees are like Behavior Tree and State Machine together....but I still did not understand how to NOT use state machine
State Trees were not designed to replace State Machine. In documentation it says it "combines the Selectors from behavior trees with States and Transitions from state machines." which doesn't mean it combines both systems so it can be used for both purposes, it just means it uses certain mechanics from both systems. I really wouldn't try to replace State Machine for now and definitely not with State Trees. Main purpose of ST is AI but it also has features than allow for broader use, and that's how it should be thought of. If you want to control animations from ST, do it how you would do it from normal blueprint.
@@MrKosiej got it, thanks! I am trying to make a custom State Tree Task to move a character in a Spline and it seems like the Enter State node from the Task is running all the time....was this supposed to happen?
Hey MrKosiej! It there any idea how to make parallel states in ST? For example: 1. pose state - crouch/walk/run 2. action state - aim/kick/reload weapon 3. move state - move to position How make them work at the same time?
I don't think there's a way to run 2 states in parallel in the same tree, but there are some similar alternatives: 1. Running several tasks in the same state 2. Running multiple state trees Or using options outside state trees. In my experience it's better to have a skill system (custom or GAS if you're brave enough :P) that handles specific actions and use ST for more general states that includes the possibility of using those skills. So an example state would be "going to cover" that would also check ammo (if the character should reload), or stamina (run or walk) and activate those actions separately. Then if the character should reload, it just knows. We enable run to cover then it runs/walk to cover and triggers an animation montage for upper body on top of the running animation.
Hey @MrKosiej, what do you mean by the parent state is not selectable? The code tasks will run but its not selectable? What implications does that have?
It is selectable now with selection behavior. Previously it couldn't be selected. Basically if a state has children states and selection behavior is "Try Select Children" it will behave like normal parent state, (tho it actually can't run tasks now, it was running on previous version, so it's better now.) so it will just try to enter children states. If children states are parent states it just goes deeper until a state has "Try Enter" or is a leaf state. If a state has "Try Enter" it is treated as a leaf state and can be selected (and run tasks). Then it doesn't matter if it has children states, those can be accessed tho through explicit selection using transition rules or events (or links).
@@MrKosiej thanks a lot for your reply! So parent states can only execute their tasks with "Try Enter", but then i have to explicitly do a transition to a child to continue? that new system is quite confusing to me. if i wanna find a house and then walk to it i would do something like this? ParentFindHouse[TryEnter] -> OnSuccess transit to ChildWalkToHouse --ChildWalkToHouse
@@MrKosiej that actually solved by problem..... thank you so much! i wish the documentation would explain that properly. so how is a "parent state" with "try select children" then different than a "group"? because neither is meant to execute tasks right? theire just there to have enter conditions?
hey man thanks for your videos! do you have any idea why the custom tasks I create do not appear on the state tree tasks dropdown? I am creating as "StateTreeTaskBlueprintBase"
Hey, sadly i don't know what could be the cause of your issue. I've never seen it before. If you find a solution tho, please let me know what you did :v.
@@MrKosiej I found out the issue was that I was trying to use the Mass Agent component from MassAI plugin....when you are creating your state tree it gives you two options if you have MassAI in the project and I created mine based on that and it does not support custom tasks
Hey thanks for your videos, they are great and have helped me alot so far. is there a way to stop State Tree tasks and switch to another state? Let's say I have an AI with idle and combat modes, and I want it to switch to combat mode right away when it detects a player. I'm aware that theoretically, I could send an event to every idle state and transition them to combat, but I'm looking for a solution that directly transitions to combat from the current state, without having to define it everywhere.
I have a theoretical technique that might do what you want. 1. You need some kind of a delegate, so make a dispatcher "OnCombat" that you will call when the AI should go into combat. 2. Have a base class for your state tree tasks where you bind that dispatcher on Event EnterState (get it from context actor) 3. To that bind an event that executes "StateTree Request Transition" 4. Make a variable in your AI character class called "State Tree State Link" 5. Use that var to pin to Target State in Request Transition in step 3 using context actor. 6. Use Evaluators Or Globals Tasks to pass the relevant state ref to the context actor on Tree Start. 7. Done (but might wanna unbind that STT event on ExitState). Now everytime the dispatcher is called, it should trigger a transition to the state you defined as a Go To If Combat. Keep in mind, i did not test it, i just thought of it so please let me know if it works :)
@@MrKosiej Thank you. I had a similar idea, but I experimented with a different approach, and surprisingly, it worked. It appears that if you're child of a state, and that state receives an event, it triggers the transition and force that state to exit. I tested this before and it didn't work, so I posted my question here. But when I gave it another shot, it worked this time so now I have two event-base transitions at my root to combat and idle modes. I have another question too have you managed to work with state tree's debugger? It seems there are only fake break on enter/on exit buttons which don't work.
Ok i just notied the next milestone in the roadmap is not 5.4 but "forward looking", so i guess it's just a general collection of things they're working and and that might not be what's next in 5.4 but possible later. There's an entry about it here portal.productboard.com/epicgames/1-unreal-engine-public-roadmap/c/1288-state-tree-debugger I'll make a video about a debugger when i think it's "good to use"
