koobas.hobune.stream
What should be handled in the custom inspector version of a script?
So if I have 2 scripts, Enemy and EnemyEditor, and "Enemy.cs" contains this (which is just an example):
using UnityEngine;
using System.Collections;
public class Enemy : MonoBehaviour {
public float someFloat
public GameObject someGameobject;
void Update() {
Debug.Log(someGameobject);
}
}
What should the editor version for the inspector contain?
This is what it currently looks like:
using UnityEngine;
using System.Collections;
using UnityEditor;
[CustomEditor(typeof(Enemy))]
public class EnemyEditor : Editor {
float editorFloat;
gameObject editorGameobject;
Enemy myEnemy;
public override void OnInspectorGUI() {
myEnemy = (Enemy)target;
editorFloat = myEnemy.someFloat;
editorGameobject = myEnemy.someGameobject;
myEnemy.someGameobject = GameObjectField(myEnemy.someEnemy, true);
myEnemy.someFloat = FloatField(myEnemy.someFloat);
}
}
My question is: Should the editor scripts only contain code for modifying the LOOK of the inspector, or can it contain all the functions in update, and what actually does stuff to the character?
And if the editor script is just for changing the way it looks, what should the code look like in both? I don't understand SerializedObjects, if that's important. If you could, please try to explain since I'm not familiar with this.
Generally speaking, your editor scripts should be mostly to make life easier when trying to edit that object, or create/modify assets. As Unity's class you derived from, Editor, is part of the UnityEditor namespace, anything using that class, Editor, cannot be included in a standalone build. Meaning anyone you send your game to who doesn't use Unity like we do won't be able to see any of your editor script stuff, since your EnemyEditor (for this example) is only available in the full Unity editor.
So as with other UnityEditor classes and functions, be careful that your game doesn't rely on them to function normally if you want to build your project to play outside of Unity. Note that you can use "preprocessor directives" to tell the compiler to include/exclude certain parts of code in certain situations. In this case, you can wrap code with this: (literally any code, it can be outside functions, outside classes, etc.)
#if UNITY_EDITOR
...
#endif
So that will allow you to use editor code inside there, because any code inside of there will not be included in any builds -- it will only be available in the Unity editor. Sorry if that sounds like a broken record xD
Ah yes, Unity's serialization system (way of saving data) is complicated yet simple -- a long conversation from the beginning for sure though. It's based on SerializedObjects and SerializedProperties, and the editor knows how to draw all sorts of basic types using PropertyFields (Just about all classes inheriting from UnityEngine.Object (this includes MonoBehaviours, EventTriggers, ScriptableObjects, etc.) are able to have references to them saved. Others types like custom classes of our own, and structs -- these serialize inline, so you won't see a Vector3 reference field for example -- the values are serialized inline with your MonoBehaviour for example, where the inspector shows not a Vector3 reference field, but literally just x, y and z (float) fields. Serialization happens constantly in the inspector, as it typically serializes the data before displaying it. This is why the attribute [SerializeField] causes stuff to show in the inspector -- as it's being included in the editor's serialization of that object of yours, and then the inspector will show all the serialized (saved) data belonging to it.
There are quirks and limitations to Unity's serialization though. Also note that you can implement ISerializationCallbackReceiver (an interface in the UnityEngine) to slightly control how Unity serializes/deserializes (saves and loads) your classes and structs. You probably won't (I didn't) understand it all at first, and you may be able to get away with not really caring about Unity's serialization for your inspector. But it's definitely useful to know especially once you need to get around to advanced editor stuff -- you may eventually need it when you extend Unity to do really nice chores for you and your team :P. Here's a helpful blog post for more information where they describe serialization used by Unity.
I hope this somewhat helped! It's a big topic >.<. Also note! If you want to see the serialization first-hand, go to one of your Unity scene files or asset files (like a prefab) in your file explorer on your computer, and open it with a text editor like Notepad++ or Visual Studio or something. You'll be able to see all the serialized data, arrays, field names & values, and stuff in there!
