Unity Issue Tracker - StateMachineBehaviour exclusive messages are treated as MonoBehaviour messages

Fixed

Votes

Found in

Issue ID

Regression

StateMachineBehaviour exclusive messages are treated as MonoBehaviour messages

-

Mar 10, 2015

How to reproduce:

1. Open attached project
- The project contains a single script with the following code (modified):

using UnityEngine;
using System.Collections;

public class ConsoleErrorOnStateUpdate : MonoBehaviour {

public class Foo
{
public void OnStateEnter() { }
}

void OnStateUpdate () { }

public void OnStateEnter() { }

}

- The editor throws errors that would make sense in the context of a StateMachineBehaviour, but seem odd in a MonoBehaviour context:

Script error (ConsoleErrorOnStateUpdate): OnStateEnter.
The function must have exactly 3 parameters.
The function will be ignored.

- The messages are not listed in http://docs.unity3d.com/ScriptReference/MonoBehaviour.html as possible options
- A workaround would be to not use the predefined messages that are listed in http://docs.unity3d.com/ScriptReference/StateMachineBehaviour.html for method names.

Andrew-Carvalho

May 07, 2019 01:54

Just booted up 2019.1 and this is happening even though I hadn't noticed it in 2017 or 2018. Possible regression? Was this ever actually released in any way or has it actually been in review for 4 years?
nack

Apr 15, 2015 15:58

This is a little bit ridiculous.
cgulliver

Apr 02, 2015 18:35

The audacity that Unity thinks that they can reserve a function name in its entirety, and lock down its signature is frustrating. Our project makes heavy use of callbacks for our own state machine which are frequently called "OnStateEnter", "OnStateUpate", "OnStateExit". The naming schema matches because it is such a common construct, Unity did not invent the idea and nomenclature of an FSM. However, I could forgive it on objects that specialize StateMachineBehaviour, but not on MonoBehaviours.

Even still, as a language construct, I can overload methods with whatever signature I want, but for Unity 5 certain method signatures are locked. I understand that it may be to prevent (new) users from accidentally providing the wrong signature and provide up front feedback instead of silently failing. As an experienced engineer; being forced to name a method something less readable solely because a common method name is now reserved across all monobehaviours and namespaces is extremely frustrating. Especially in a large existing codebase upgrading to Unity5.