I reported the problem to Epic. There’s nothing more I can do. Will keep you informed.
Appears to be fixed now. I’m really sorry for the delay.
Great, thanks! (Not your fault, I’m guessing…)
Hi,
Thanks for the great plugin 
However I encoutered what seems to be a bug, a pretty annoying one:
When I’m visualizing the flow of the FSM in Blueprint Debug mode (with the red boxes ticking), UE crashes at some point.
If I’m not looking at the FSM in debug mode, it all goes well.
I was able to repro using the demo project from the plugin’s website, and that in the GameMode (I used a tool to merge .jpg’s but it’s all in the same BP):
](filedata/fetch?id=1796907&d=1596547221)
Adding this in GCFSMState.GetFSMRecursive() seems to do the trick:
](filedata/fetch?id=1796906&d=1596546764)
Otherwise, it seems to be in an infinite loop, going back-and-forth between WaitingState, ClassSelectionState and ShuttleState (at least, that’s what the FName argument in GetFSMRecursive contained when I was debugging).
Is this really a bug, or am I using the plugin in a wrong way?
You can also find the crashlog here: https://arthurcousseau.com/CrashContext.runtime-xml
Thanks!
I’ll have a look into that. You fix seems reasonable. However, I have noticed that a few of your FSMs do not have a Stop FSM node. You should always ensure that every execution flow terminates into a Stop FSM node.
Hi Gamecentric.Thank you for making this plugin.
It works really good in our project but I have a problem with blueprint debugging.(Advanced debugging)
Here it is.
The Blueprint Debugging works well in the [character blueprint] if the FSM is created/defined in the character bluerpint .
However,if a FSMState is an other blueprint which is a child fsm state of the FSM_Root in that character blueprint,then it can’t be attached to any debug object.
This can be really inconvenient for us to debug with these fsm states.
If there’s any solution,please tell us.
Hello @gamecentric,
Thanks for the quick reply!
Indeed, it seems adding a FSM Stop node fixed it.
I still think it shouldn’t crash but rather capture the error and display that info to the user? (“You probably forgot to add a Stop node…”)
Thanks again
Indeed, GC FSM used to display a warning about missing Stop nodes… the fact that now it doesn’t looks like a regression. I will look into that. Thanks for the report.
Updating my question.
After testing beween different engine verisons,I found the problem that fsm class debugging not working only happens in 4.24.
It works fine in 4.22.
So obviously GCFSM has not support 4.24 well yet.
Hope you solve this soon,dear gamecentric.
Thanks for the report. I already have a fix for this bug, but unfortunately I am on vacation and I’m unable to push it. If you are able to rebuild the plugin from source code, the fix is just one line:
UGCFSMRootState* UGCFSMRootState::MakeRootStateObject(UObject* context)
{
check(context);
auto rootState = NewObject<UGCFSMRootState>(context->GetWorld()); // <--- FIX HERE
rootState->Initialize(context);
return rootState;
}
Otherwise, please be patient, I will sent the fix to Epic as soon as I’m back.
@T.Mao A fix addressing your issue has been submitted to Epic. I’ll post again when it’s online.
The fix is now online and can be downloaded with the Epic Launcher. Passing by, I took the opportunity to improve the debugging experience for nested states. This is the appearances of the “Debug Filter” before the update:
In this case, there are multiple objects, running FSMs each in a state implemented by the same class: all state objects are displayed with the same name (the state class name), making it difficult to see which is which. This is the appearance of the filter in this new release:
As you can see, the filter now shows exactly the name of the object running the FSM, the name of the FSM and the name of the state (not of the state class). Hope it helps!
Enjoy!
Hi @gamecentric
Thankyou for making this, your plugin is awesome.
Everything works perfectly on my project :). Unfortunately, I got some issue here after updating Unreal version from 4.23 to 4.25.
Somehow the FSM Local state is stop running after I travel to the next map. I put the state in Game Instance so I’m guessing it supposed to be persistent between Map.
Cheers 
Thanks for using my plugin. I am investigating on your problem.
Version 1.7.7 of GC FSM is online now. This is bugfix only release for the issue reported by @DhimasGP: the FSM of objects that outlive the world they were created into (like, for instance, Game Instance objects) would stop running if a new map is loaded.
Enjoy!
Thanks a lot @gamecentric , appreciate your efforts for fixing this
@gamecentric Is it possible to control the tick interval of GC States?
What kind of control would like to have?
Like how actors and components can set the tick interval
Currently that’s not possible. It’s not technically impossible to implement, but I am using the tick also to ensure that the FSM are properly disposed as soon as the context object is destroyed. Introducing a tick interval might create a delay in the destruction of the FSM. I will add this feaure to my TODO list.