Case Status
Log In


Home ยป API Reference»Writing Custom Actions»Custom Actions Overview
Community Wiki

Custom Actions Overview

Playmaker automatically discovers any class derived from FsmStateAction in the project. All discovered actions appear in the Action Browser.

Actions are modular building blocks that define the behavior of a state. Writing a custom action is very similar to writing a MonoBehaviour script.  However, unlike MonoBehaviours, Actions can be moved around in the State Inspector and they execute in sequence.  See Actions Overview

The main differences from MonoBehaviours:


Reference the GameObject that owns the FSM using the Owner property. For example:

Owner.transform.position = new Vector3(0,0,0);

OnPreprocess (1.8.0)

OnPreprocess gets called by PlayMakerBuildCallbacks.OnPostProcessScene

Use this to preprocess the scene and avoid runtime work.

For example, add physics handlers here:

public override void OnPreprocess()
    Fsm.HandleCollisionEnter = true;

This adds a proxy Monobehaviour to the GameObject to catch OnCollisionEnter. You can do this at build time instead of runtime by using OnPreprocess.


Called when an action is first loaded. Use this for expensive initialization operations. 

See MonoBehaviour Events below.


Instead of Start(), or OnEnable() use OnEnter(). OnEnter is called when the state becomes active. This lets you initialize an action.  Many actions also do all their work in OnEnter.


Instead of Update() use OnUpdate(). OnUpdate should look very similar to a MonoBehaviour Update.


Instead of OnDisable(), or OnDestroy() use OnExit(). OnExit is called before leaving the current state. This lets you cleanup or perform optional operations on leaving a state.


If an action has a definable completion criteria, it should call Finish() when it is met. When all actions on a state have finished, a FINISHED event is sent that can be used to transition to another state.


Playmaker FSMs are event driven - they change state when they receive events. An action can send an event using Fsm.Event(eventName). NOTE: If the event causes a state change, OnExit is called immediately on all actions in the current state that have started but not finished; the FSM then switches state, and OnEnter is then called on each action in the new state. 


Public action variables are exposed in the Action Editor the same way public MonoBehaviour variables are exposed in the Unity Inspector. An FSM also has a list of named variables that can be used in action parameters. Fsm Variable types use an Fsm prefix in front of their wrapped type (e.g., FsmInt, FsmFloat, FsmString...). Typically you get/set the underlying value of the fsm variable using the Value property (e.g., numLives.Value -= 1). See Using Fsm Variables.


Actions can call Log(), LogWarning(), and LogError() to create nicely formatted log entries. Warnings and errors appear in the PlayMaker Log Window and the Unity Console. Other log entries show only in the PlayMaker Log Window.


Actions can provide an optional ErrorCheck() function. This function is called by the Error Checker to validate action setup. Use this function to perform custom setup checks and return an error string (or null if no errors are found). Note: You can also use RequiredField and CheckForComponent Attributes to validate parameters. See Action Attributes.

Every Frame

Many actions have an option to repeat every frame. By convention this is defined as: public bool everyFrame, and should be the last parameter in the action. Actions that repeat every frame do not call Finish().


Actions should provide a Reset() function that initializes parameters to useful default values.

MonoBehaviour Events

Actions have built in support for the following MonoBehaviour events:

  • OnGUI
    • to use this, you have to explicitly declare its usage using Fsm.HandleOnGUI = true; See SetGuiDepth for an example.
  • OnFixedUpdate
    • to use this, you have to explicitly declare its usage using Fsm.HandleFixedUpdate = true; Set SetVelocity for an example.
  • DoCollisionEnter
    • to use this, you have to explicitly declare its usage using Fsm.HandleOnCollisionEnter = true; See CollisionEvent for an example.
  • DoCollisionStay
    • to use this, you have to explicitly declare its usage using Fsm.HandleOnCollisionStay = true; See CollisionEvent for an example.
  • DoCollisionExit
    • to use this, you have to explicitly declare its usage using Fsm.HandleOnCollisionExit = true; See CollisionEvent for an example.
  • DoTriggerEnter
    • to use this, you have to explicitly declare its usage using Fsm.HandleOnTriggerEnter = true; See TriggerEvent for an example.
  • DoTriggerStay
    • to use this, you have to explicitly declare its usage using Fsm.HandleOnTriggerStay = true; See TriggerEvent for an example.
  • DoTriggerExit
    • to use this, you have to explicitly declare its usage using Fsm.HandleOnTriggerExit = true; See TriggerEvent for an example.
  • OnLateUpdate
    • used to handle the MonoBehaviour LateUpdate() event. 

The code in these functions will generally be the same as code used in a MonoBehaviour.




Last modified on 1/7/2016 7:00 PM by User.

  • RSS Feed