koobas.hobune.stream
C# Constructor in MonoBehaviour
How is the constructor called in MonoBehaviour?
It seems a constructor is called twice if it's in a gameobject via MonoBehaviour?
Example:
using UnityEngine;
using System.Collections;
public class Constructors : MonoBehaviour {
public Constructors(){
print("Constructor");
}
}
When you press play in the editor, Console reads:
Constructor
UnityEngine.MonoBehaviour:print(Object)
Constructor
When you press stop in the editor, Console has an additional extra line reading "Constructor" with these three separate lines:
Constructor
UnityEngine.MonoBehaviour:print(Object)
Constructor
Constructor
Use Init() and Start() to do initialisation. Classes derived from $$anonymous$$onoBehaviour do not have constructors.
What do you mean that classes derived from $$anonymous$$onoBehaviour do not have constructors? The constructor seems to be called anyway (?)
This set up should give you a warning about constructors on monobehaviours. Either way you don't use them. As indicated do your initialisation in Awake and Start. Awake is typically for internal stuff and will be called immediatley. Start is for external stuff and gets called before the first frame of Update.
$$anonymous$$aybe you have two gameobjects with this script attached?
Speaking about constructors vs Awake/Start - actually you could use the first, but very carefully and only when you sure what exactly are you doing. For example to init static public Instance field for Singleton, or something like this. But keep in $$anonymous$$d that object with it's components, and all scene are not initialized at the coustructor execution moment, and even your public fields are not initialized by values set in inspector.
And as was said here - in 99.9% cases you should use Awake and Start.
As everybody else is saying, don't use constructors. With the way unity works, you're supposed to use Awake and Start to handle initialization behavior.
To explain what you are seeing: yes, the constructor is called three times. You'd get the same result if you implemented the ISerializationCallbackReceiver interface, and put a debug in OnBefore/AfterDeserialize. You'd even get the same thing where the first debug would point back to the line of the debug, while the other one would be just the debug text with no extra info.
Now, I think that gives a clue about why you're recommended to not use constructors. See, serialization of the objects in the scene (and the scripts on them) happens a lot; whenever you save, whenever you press play, a lot of times. Instantiation of new objects, and thus calls to the constructor, probably happens as a part of that process. So if you say create a new gameobject as a part of your constructor, you'd be seeing that gameobject being added to your scene at different points when you didn't expect the constructor to be called.
Awake and Start, on the other hand, only happens exactly when the application starts playing, and when things are instantiated in play mode. So to prevent stuff from leaking from the serialization process to the scene, avoid constructors.
I think this would be a good case to use a custom constructor hack http://answers.unity3d.com/answers/1398563/view.html
