696 introduced ifsm_state::Self_Transition for the FSM implementation, but not for the HFSM implementation.
Expected behavior is to also reactivate (exit, enter) the current state when ifsm_state::Self_Transition is returned by process_event / on_event
Now, this may be a bit more complex as there are also parent state handling to take care of. As what should happen if the parent returns the ifsm_state::Self_Transition variable. Should than the parent be reactivated as well?
Also, but this may need to be a different issue but somewhat related. Returning the STATE_ID from the parent when it processes an event causes some weird transitions as it partially reactivates the states.
For example, in the motor control example if the Running state would accept the SetSpeed event and returns the STATE_ID. It would then reenter the Running state without exiting it first and activate its initial substate WindingUp
696 introduced
ifsm_state::Self_Transitionfor the FSM implementation, but not for the HFSM implementation.Expected behavior is to also reactivate (exit, enter) the current state when
ifsm_state::Self_Transitionis returned byprocess_event/on_eventNow, this may be a bit more complex as there are also parent state handling to take care of. As what should happen if the parent returns theifsm_state::Self_Transitionvariable. Should than the parent be reactivated as well?Also, but this may need to be a different issue but somewhat related. Returning the
STATE_IDfrom the parent when it processes an event causes some weird transitions as it partially reactivates the states. For example, in the motor control example if theRunningstate would accept theSetSpeedevent and returns theSTATE_ID. It would then reenter theRunningstate without exiting it first and activate its initial substateWindingUp