While using NodeCanvas I noticed that when a state becomes successful the transition to the next state only happens in the next graph update. This is problematic for me when for example I have a state A waiting for something to happen (something that cannot be checked by the state itself and that happens during update only), then transitions to state B to do something instantly, then goes back to state A. Because of the Update needed to transition between states, state A misses an Update and therefore is not completely reliable to detect that something happened.
A simple way I have found to fix this was to add the following code at the end of OnGraphUpdate of the FSM class:
where _lastUpdatedState is a new class member to avoid stack overflow issues when a state is successful but cannot be exited due to conditions.
This way my transitions from A to B and back to A all happen on the same Update and I know I won’t miss anything. Moreover it means that now I know I can cut my FSM states into multiple consecutive states for clarity without delaying any of the actions.
It’s obviously dangerous if state A is also a state that ends instantly but it seems the FSM is not correctly designed in that case (also it could be solved using a list and checking we are not coming back to a state already updated in this same Update).
So I don’t know if this change could be interesting for the next version, this is just a suggestion.
I will have to think about this very carefully before making any change to that since FSMs have been made by design to work like that from the start and there is a backwards compatibility concern as well as of course the concern of stack overflow (which could of course be handled). Maybe I could add an option for this though.
Yeah 100% you don’t want to break existing FSMs. Maybe a global option could be useful then yes (off by default), on my side I have handled infinite loops and it just logs a warning saying what is the loop and then waits for the next update to continue.