Hello. I'm trying to integrate HFSM2 into my code and I'm running into a problem. I can't get the Context from a Control, only a FullControl. The docs say I should be able to, but it creates this error:
the object has type qualifiers that are not compatible with the member function
Hi @tastesliketriangle please open an issue https://github.com/andrew-gresyk/HFSM2/issues/new with a minimal code sample so I can verify on my end
Thanks, @DJuego !
Focusing on bringing https://gitter.im/andrew-gresyk/FFSM2 to close feature parity with HFSM2
Currently, only serialization and state access remain to be done
Focusing on bringing https://gitter.im/andrew-gresyk/FFSM2 to close feature parity with HFSM2
Currently, only serialization and state access remain to be done
The recent updates to HFSM2 were mostly formatting and minor tweaks with very minimal functional changes
At this point the highest priority work is around a multiplayer UE4-based demo and docs
At this point the highest priority work is around a multiplayer UE4-based demo and docs
That said, the previous logo didn't displease me per se.
It's true that the new logo seems more friendly to me. Why yellow and blue?
However this project probably doesn't have such a large community for that.
Whatever your soul decides will be fine, for that you are the supreme author.
In my case I have a weakness for symbolic logos. I would probably recreate myself in the recognizable/familiar scheme of a finite-state machine such as:
I would try in the HFSM2 logo to refer to its "hierarchy" or "regions" nature and in the FFSM2 logo to its "flat" nature.
so I've got a bit of a basic question. I want to have the fsm Instance as a member variable in my class, but every way I've tried to organize that has failed. part of the issue is that Instance doesn't accept a forward declaration of a state, it needs the full the from the cpp file. I guess I'm just wondering if there's an obvious way I'm missing or if there's another way I should be organizing my code?
e.g. if you're in UE4, and have an
AMyActor- I'd create a MyActor namespace and put all of the FSM code into it
Then I prefer letting
FSM being more of a 'brain' for the actor
AMyActor do all the heavy work, exposed via public API, and have the FSM call actor's functionsFSM being more of a 'brain' for the actor
Hi @andrew-gresyk, just wanted to follow up on your advice to @tastesliketriangle to clarify one thing about adding an instance as a class member. When you describe letting the fsm call the actor's functions, is your strategy to pass a reference/pointer to the Actor through the context, i.e. a Context struct with a reference to an Actor instance inside of it? Or is there a more direct way to just use Actor& as the Machine's context type and directly construct the FSM instance passing *this as the context object? I'm wondering if this sort of forces you to declare the FSM instance member as a pointer and create it in a deferred manner, since the Actor class would not be fully constructed at time of creation?
one more quick question, as I didn't find much info in the docs on orthogonal regions: would I be correct in intuiting that they always update their states in the order declared in the region's template?
Well, @andrew-gresyk . Congratulations for the new version 1.9.0 of HFSM2!! It's been a while since I've worked with any project involving a finite state machine. But you can believe me: I'm looking forward to it. It is my desire to use HFSM2 in the context of a robotic platform I am working with. :-)
1 reply
Hi @andrew-gresyk, I've gotten a bit further into integrating HFSM2 into our robotics project; really nice to work with. There is one slightly unexpected behaviour that I encountered and I just wanted to check with you if there is a way of avoiding it. I modeled my overall HFSM into a 2-level state+substate, using Composite regions (with head states) as the states, and just states as the substates. There is some logic that i want to call every for every update of the region, so I overrode the head state's update() method and performed that logic there. This logic contains error checks, like loss of connectivity, timeouts expiring, etc, and is meant to pre-emptively exit the region upon detection of these issues. While this works, I noticed that when one of these errors occurred and I called changeTo<SomeOtherRegion> from the head's update method, the currently active substate update method got called immediately afterwards, despite the request to exit the region. Is this expected, and is there any way to "force" deactivation of a region immediately to avoid the region's substates getting updated? Perhaps there is a better way to achieve this? I'm trying to avoid putting the same error-checking code in every substate, since this logic is common to all of them.
I've tried a lot of alternative methods, like composing the "State" as an orthogonal region containing the "pre-update check" state and the original Composite region containing the substates (same behaviour as just doing the check/transition in the Composite's head state), as well as trying to use an Injection's preUpdate() method to call a lambda with a reference to the FSM that evokes the transition (the inner state's update methods still get called here as well).
Apologies if this just sounds like word soup to you :sweat_smile:
So far my only working approach is to create a map of StateID->PreUpdate std::functions and evoke "state_preupdate_functions fsm.stateId() ;" before each fsm.update() in the main loop.
But I was hoping to find a way to embed the logic into the FSM transition-related code self-contained
Hey @spiderkeys_gitlab
Thank you!
What you can do - is use event handling for handling errors.
There's an example in https://github.com/andrew-gresyk/HFSM2/blob/master/examples/advanced_event_handling/main.cpp for that.
You can have your FSM react() to CheckForErrors event before the recursive update()