Really like using State Machines so I’m learning the new StateTree implementation which shows huge promise. I’m just using them with a simple AI character to test it out and have followed the documentation examples and tutorials. These are helpful but pretty simple implementations.
I suppose my main question is how to best switch between states, based on happenings on your main Actor. For example, if you have a animation notify event firing off from your anim instance that should change your state. Is the best and most performant way for this to change your state is to expose a bool on your actor that changes on the notify event? The evaluator is then checking this bool every tick to see when this changes? Is there a cleaner way to do this? I.e. the notify event just fires off a message that changes the state (perhaps through transition bp)?
I see that evaluators are useful but I don’t like the idea of it tracking every single bool/variable you want to track for the entire time the State Tree is running. I.e. you cannot seem to set the evaulators to only run on certain states.
Maybe I am missing something? Thanks for any help!
I’m suffering form the same questions. One of the things I’m discovering is that they are operating on tick (you can see this when you use StateTree Debugging Primer | Tutorial) So the state is ticking anyway. I’ve decided to therefore not use evaluators as I can then place the check as a state transition condition in the tree referencing the variable in the context actor. Thus only the relevant check is accessed each tick
Nice thanks, yeh I like the idea of just using the transitions to track the necessary changes.
How about event components like the Sphere Collider? Is there a way for that to interact with the State Tree Transitions? I don’t like idea of that toggling a bool that is tracked by an evaluator for example on tick.
Well the state tree if active is going to be ticking anyway. So its more about making that tick efficient. The transition on event option looks pretty good for this. It is worth also thinking about stopping the event tree if its not going to be doing anything until something happens and starting it when relevant - though that only works if you design the tree with a restart in mind.