-
-
Notifications
You must be signed in to change notification settings - Fork 20
Nested FSM Support #97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Yo! I already noticed you working on that. I will take a look later that week, as it is something I have been wanted to add for some time now, but the workaround of nesting a fsm inside a integrated behaviour tree was more comfortable (or less work).
What's the difference from overloading the state like you would normally? This is what you do with all states anyways, so I do not see why this would be a problem. |
I'm very glad to see you approve of this implementation! Hopefully I can get back to work on this now that I have more time on my hands. I plan to implement more robust transition checks for the Transition class. This would include generating warnings for cross-hierarchy transitions, such as when a nested FSM attempts to transition into an ancestor FSM. Then after some clean up, comments, and a template I feel it should be finished. |
I'm just now realizing there is a lot more work than I thought to fully integrate NestedFSMs beyond adding configuration warnings for transitions into this plugin. I'm just going to continue working until I feel it's finished lol. |
The new configuration warnings check if the initial state exists within that FSM, preventing human error.
Ok I think nested FSMs are in a good state.
Any feedback is welcome! |
I will do some testing and experimenting! Thanks for your addition! Looks good so far! |
Hello!
I wanted to get your thoughts on a NestedFSM node I implemented. It derives from State and initializes a self-contained FSM that inherits values from the main FSM. Additionally I've also created a demo similar to the blacksmith demo to showcase this new functionality.
Looking ahead, I'm considering overloading the
_on_enter
,_on_process
, and_on_exit
functions to give users more control.For example, in a fighting game, a "Crouching" nested FSM could use its
_on_enter
function to play the crouching animation. This ensures the animation plays before any sub-state (like "Crouch Jab") runs, eliminating the need to manually trigger it in every possible transition or every sub-state'son_enter
function into the crouching posture.Do you have any suggestions or concerns about this direction?