Playmaker Forum
PlayMaker Feedback => Feature Requests => Topic started by: ciabaros on April 13, 2013, 01:51:16 AM
-
I believe that there should be a new Fsm Variable/Parameter type for directly storing/passing "Fsm" object references. The manual assignment of this variable (or action parameters of this type) would pop up an FSM picker, almost identical to the current PlayMaker "FSM Browser" (easy implementation reuse?).
Why not use FsmObject with SubType "PlayMakerFSM"?
- Assigning these manually doesn't always work, since you can only pick the GameObject, which amounts to the FIRST fsm being assigned -- you cannot currently pick any FSM (if there are multiple on a single GO) as you can through the PlayMaker "FSM Browser" window, and;
- You cannot enforce sub-types of FsmObject for Actions in the editor, so you'd have to do it at runtime, and that's very ugly.
Why This Came Up:
I've recently implemented 2 custom actions, which (to me) revolutionized what I can do with PlayMaker in treating/running ANY other FSM AS a Sub-FSM from within a single state using actions:
- StartFsm: Starts another FSM (and optionally, tries to enable it, if needed). Fails if already running, can be used with "StopFSM" below, to force "restart".
- CheckFsmStatus: See/wait if/until another FSM is disabled/stopped/finished or enabled and running.
But I noticed that now, having a reasonable arsenal of actions that operate on FSMs, defining the GO, and FSMName every time is kinda ugly (as EnableFSM does). With an "Fsm" type variable/parameter, you could further separate Fsm-operating actions into proper atomic ones, such as:
- GetFsm: used mainly for locating relative FSMs, or just based on a FsmGameObject variable (not known/existent until runtime), much like EnableFSM does today to get its FSM. You'd no longer need an action to locate FSMs "absolutely", because with this variable type, you'd now just assign the variable to any available FSMs set up in the scene.
- EnableFsm: depricate (but keep for legacy) its GO and "Fsm Name" parameters, and add an Fsm parameter based on this proposed "Fsm" type, which can be absolutely assigned on the spot, or given a variable.
- CreateFsm:
the way that "RunFSM" could have been done instead; similar to "RunFSM"; takes an FSMTemplate and a GameObject to add it to and once done, assigns the new created FSM to an output variable, which can then be passed on to be started, monitored, etc. - StopFsm: force another FSM into a "Finished" state as if it itself called "FinishFSM"
- etc.
Additionally, this would allow the current "RunFSM" Action to simply output the SubFSM instance into a variable, rather than having to retrieve by the current intended "StoreID", which would then be an unnecessary complication.
More Information About the Proposed "Any FSM as SubFSM" Pattern:
I'll create an appropriate topic for this in the right section, and provide a reference to it from here once done, in case anyone's interested in why I'm so jazzed about it.
-
Hi,
yes, I too would enjoy storing the Fsm component reference directly. This would also allow hopefully for a better management when referecing fsm's an variables on a prefab, because at the moment, if you use "set fsm string" for example on prefab unknown during edit time, then you have to hardcode the fsm name and variable name, and it will not be refactored if you change it, so that's a real potential for byd bug if you forget about this loose referencing.
It's indeed a difficult situation here, maybe reference the fsm from a template would help the refactoring.
bye,
Jean