Search Issue Tracker
Fixed
Votes
3
Found in
5.0.0f3
Issue ID
679042
Regression
Yes
StateMachineBehaviour exclusive messages are treated as MonoBehaviour messages
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.
- Original case: http://issuetracker.unity3d.com/issues/statemachinebehaviour-inconsistent-start-usage-in-statemachinebehaviour-scripts
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
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.