I am pleased to announce that v1.0 of my plugin GC FSM is now available on the marketplace. This version supports Unreal 4.19, but the code base is perfectly compatible with Unreal 4.18, I’ll make sure to upload a separate 4.18-compatible version in the next update, so that support is properly advertised. Due to a problem with the Mac/iOS toolchain in Unreal 4.19 the plugin does not advertise Mac/iOS support, although the code is actually compatbile also on those platforms.
[HR][/HR]GC FSM is a plugin for Unreal® Engine that allows you to create event-driven, hierarchical finite state machines directly in blueprints.
Why do you need FSMs when you have behaviour trees, you ask? BTs are great, but they require quite a bit of machinery. For instance, BTs must be run by an AIController and also need a Pawn actor. But there are tasks that have complex logic that are not “behaviours” in the strictest sense and that are not logically run by an “enemy”. Think about menus, puzzles or even parts of the logic of your PlayerController. Can you use BTs for those? Probably yes, but not without making it more complicated than it should be. GC FSM allows you to implement those tasks using FSMs right in blueprints, for all kind of objects: actors, components, widgets, etc. with ease and without any gimmick to use a tool clearly designed for something else.
Features:
The definition of a state machine is done entirely in the blueprint editor and can coexist and mix with “normal” blueprint logic. GC FSM does not rely on the behaviour tree or the animation editor, so blueprint logic stays where it should be.
You can create re-usable state classes for recurrent tasks both in blueprint and in C++. Blueprint state classes can run state machines too, allowing a natural hierarchical structure.
Transitions between states are triggered by events, allowing you to de-couple the logic and complexity of the state machine from the higher-level game logic.
Any object can run state machines, not just actors. You don’t need to jump through hoops to create a state machine in non-actors, such as actor components. An object can run multiple state machines at the same time.
You can debug state machines within the blueprint editor itself and monitor the flow of events in the Unreal Visual Logger.
Code Modules: (Please include a full list of each Plugin module and their module type (Runtime, Editor etc.))
Runtime module
Editor Module
Number of C++ Classes: 4 (Runtime), 14 (Editor)
Network Replicated: No
Supported Platforms: All except Mac/iOS. (The Mac and iOS platforms are meant to be supported, but they have been disabled because of a bug in the Mac buidl toolchain in Unreal 4.19. Support for those platforms will be re-enabled in a future update.)
Documentation: GC FSM for Unreal Engine – gamecentric
Example Project: Example projects – gamecentric
I don’t see in the log file the lines where the engine loads the two GCFSM plugin modules (named GCSFSM and GCFSMEditor). I assume that you are aware that you must buy the plugin in order to run the example project, so could it be that you did not enable it?
My bad, sorry. The example project was created with the plugin “embedded” in the project itself, but when you buy it from the Marketplace you are running the “installed” setup where the plugin is placed in the engine folders. This setup requires a different .uproject file. I am going to update the project file on the website, but you can easily patch the .uproject yourself by adding the following lines:
I understand. I will create a video tutorial so that everyone can get a glimpse of what the plugin does without buying it beforehand. Anyway, feel free to contact me anytime for questions. I also have created a Slack workspace for the support, if you prefer that channel. Just IM me with you email address to get an invitation.
I am pleased to announce that version 1.2 of GC FSM is now available on the Marketplace. This version is compatible for both Unreal 4.18 and 4.19 and supports all platforms, except Mac/iOS (actually those plaftforms should work, but they can’t be advertised on the Marketplace due to issues with the toolchain).
This new version introduces a new exciting feature: Local FSM States. These behave identically to “regular” FSM states, except that the OnEntry/OnTick/OnExit notification can be handled right in the event graph of the object running the FSM instead of in a separate class. While having a separate class is good for re-use and complexity management, local states can be very convenient. In particular, local states allow an FSM to interact with actor timelines, since those can only be manipulated from the actor event graph.
The default list of transitions events when you place a state node can now be customized in the Project Settings/Plugins/GCFSM panel
The messages in the Visual Logger have been redesigned by including the state name and are now much more helpful
Leaving a state node with an unconnected event pin would have caused a crash if the event was triggered. Now the event is ignored and a warning is emit at compile time
Right-clicking on a node without an implementation class no longer makes the “Create New Implementation” dialog to appear, blocking the access to the context menu
The documentation on the website is being updated to include the new feature.
A special thank goes to Frederick Desimpel whose feedback has been extremely valuable and in particular for giving me the idea of local states.
For support about this release, please post on the Support Thread.
This new version fixes a few bugs that affected Local FSM States and introduce the possibility to inspect the event that caused a transition from OnExit event handlers. Please notice that** this version contains breaking changes** for those programs using C++ to define state classes. Nothing big, actually, but the OnExit C++ virtual function now takes a parameter, so in case you have overridden it, you must update the signature in your code. Blueprint usages are not affected, since blueprints will be upgraded automatically.
Other improvements in this release:
The objects returned by GetActiveFSMState() now have a GetStateName() accessor to get the name of the node in the FSM
The objects returned by GetActiveFSMState() that refer to local states have a GetGraphName() accessor to get the name of the graph that implements the state
Added function IsFSMRunning to check if a specific FSM is currently running
I’m very pleased to announce that version 1.4 of GC FSM is available on the marketplace. The main feature of this release is Network Replication. Yes, FSMs can now be automatically synchronized between an actor authority and its proxies. Be sure to read the documentation you can find at Network Replication – gamecentric
Sorry to have kept you waiting, but version 1.5 of GC FSM is now available on the Unreal Marketplace. This version adds a new feature called Submachine State that allows to you to easily create a multi-layer FSM without having to subdivide the logic in multiple classes. Be sure to read the documentation page and the change log. Enjoy!
A minor update, this time: version 1.5.1 of GC FSM is now avalaible on the Marketplace. In this release: support for Unreal 4.20 and the possibility to defer the initialization of replicated proxy FSMs (details here).
Enjoy!
Version 1.5.3 is online, another minor release to fix a few bugs.
First of all, there was a regression on Unreal 4.20: under certain circumstances, FSMs would stop and disappear unexpectedly. It turned out the problem was caused by the recent optimizations in the garbage collector. Many thanks to users eanticev, Albie_123 and woodzong for their very detailed reports that allowed me to found the bug in no time!
Second, nativization of blueprint including FSMs didn’t work properly and is now fixed. Thanks to user eanticev for the report.
Long time no see! It took so long but version 1.6 is now available with some new features! You can now save the state of the FSMs of your object and then restore the exact state at a later time. Snapshot objects are convertible to/from strings so you can also use them to serialize FSMs states. More info at http://gamecentric.com/gcfsm/saving-and-restoring-fsms/
Another “new feature” release in less than a month! Version 1.7 introduces the possibility to have Submachine States remember their history when exited, so that the next time they are re-entered they will start from where they were interrupted instead of re-starting from scratch! If you know what a Deep History Pseudo-state is in UML, well… that’s basically the same! The feature exploits internally the FSM snapshots that were introduced in v1.6. I have updated the Submachine State documentation page with info about the new feature.
A minor bugfix also: now if, while restoring a snapshot, a running FSM is already in the right state, that state is not exited and re-entered.
