koobas.hobune.stream
Can you override a customeditor if it already exists?
Unity has some already defined custom inspectors, for example in the mecanim system. I'd like to be able to override some, but it seems that [CustomEditor(typeof(object))] only works the first time it is loaded. Is there any way to override one that is already defined?
For example: [CustomEditor(typeof(Transition))] is already defined in UnityEditor.dll, so I'm trying to figure out how to have my own Transition inspector custom editor.
Short answer- Nope! In fact, you can't even make subclasses of almost all of the Unity API classes. Why do you need to do this? A somewhat messier way would be to create a 'dummy' monobehaviour you can attach to the relevant gameObjects, and use the editor to that. The component itself should not have any actual behaviour (except maybe deleting itself at runtime!), but should have a reference to the Transition component you want to make a custom editor for.
Thanks, I don't need to do this, but I would like to. I'm adding other events to the state machine and thought it would be nicer to add to the UI that already exists ins$$anonymous$$d of making a completely new one. This seems like a reasonable feature to have in my opinion. It would be nicer if the last loaded [CustomEditor] was used ins$$anonymous$$d of the first loaded one.
'nicer to add to the UI that already exists ins$$anonymous$$d of making a completely new one'
... this is exactly what creating a custom editor for your own classes does.
You must understand that the folks at UT aren't too keen on end users introducing bugs into their interface code and then co$$anonymous$$g back crying about errors. That said, I do wish they would release more of their source code- there's a lot we can learn from looking at exactly how the built in editor stuff actually works.
I wanted to make the question short and simple, but so you know that I know what I'm asking for, there are multiple GUI windows involved in the state machine. The managed assembly also contains the source code for these inspector classes, so they are easy to replicate and add on to. Additionally, for the more difficult items, using assembly reflection seems to be a quick and dirty way to reuse and add on to the existing toolset, though unfortunate it could break between versions.
I thought of a workaround this morning. I'll have an editor window that monitors when items are active, then start a different customeditor. That way, even though Unity's will initially load, it will quickly be replaced with my new one.
Confirmed workaround for this problem.
I used an EditorWindow for my tool which also monitors what current selected objects are. For this example, I'm editing a State object since the Transition object I mentioned in my first post is not exposed (internal class). The 'StateEventEditor' is my own customeditor class.
In the EditorWindow:
private static State lastSelectedState;
void OnEnable () {
EditorApplication.update += Update;
}
void Update () {
if( Selection.activeObject.GetType() == typeof(State) ) {
if( Selection.activeObject != lastSelectedState )
Debug.Log("State selected");
lastSelectedState = (State)Selection.activeObject;
StateEventEditor stateEventWrapper = new StateEventEditor(lastSelectedState);
}
}
}
