Why having a different kind of "Get FSM Game Object"? The point is, right now we don't have global variables, nor the ability to duplicate actions, so if you initialize your local variables with content placed elsewhere (quite a common approach to keep things organized) you're in for a lot of legwork simply to initialize your variables. You have to drag and drop the object that contains the source FSM, then select the FSM (if there's more than one, also far from uncommon) then select the source variable then the destination variable. That, per action.
So I decided I could do something to smooth up this process a little. 'Read Game Object' finds the source game object per
name (meaning you can copy+paste it), same for the FSM name, then all you have to do is select the local variable. As long as there's a same-named variable in the source FSM, the content will be copied over.
To change the handy default source strings, besides the manual paste/typing method you have two options:
1) Edit the .cs file and change the strings in the "Reset" section (I've set it for the naming convention that I use):
public override void Reset()
{
objectName = "_ GameFSMs _";
fsmName = "fsmPrototypes";
}
2) To make it "drag and droppy", simply use a variable. You can start the state/FSM with a "Get Name" action and assign the desired object name to a string variable which will be used for all following "Read Game Object" actions.
I imagine this will get deprecated as soon as Global Variables are introduced, but meanwhile I found it quite handy, hope you find it of use as well.
PS.: I'll be posting "Read" actions for other variable types as I need/make them