One Unity Editor To Rule Them All

[@bluzenkk]

you know.. there aren't alot of youtube videos on how to make custom editor tool. so if you you know this stuff, its a good idea to make more video on how to make them.

[@WarpedImagination]

Yeah I have a list of topics to cover and a number are around the editor You'll also see little gems for the editor entwined in my other tutorial videos

[@scriptbrix]

Instead of checking the namespaces wouldn't it just be easier to create an abstract class, call it whatever, why not EditorBehaviour and let that inherit from MonoBehaviour. Now in your CustomEditor attribute, you just say typeof(EditorBehaviour) and let your Tree class inherit from EditorBehaviour instead of MonoBehaviour.

[@WarpedImagination]

Absolutely valid method and one I show in a few other videos on the channel and discuss in other comments (but I should have maybe stated a little more in this video too).. this video just shows a different option. Maybe you want to capture other classes you dont own or ones that are deriving not from Monobehavior directly, you could do this video or simply create customs for those. Gotta love those options Unity gives

[@leos-clockworks335]

Great video, thanks! This gave me a lot of ideas on where I could expand this (Debugging, more actions etc) So I'll play with this a bit and see where it gets me.

[@WarpedImagination]

Glad to hear you liked it .. do come back and continue the conversation once you've played with it.

[@fmproductions913]

Thanks for the video! I was hestiant to make an Editor that encompasses all MonoBehaviours, but you shared some interesting ideas for it

[@WarpedImagination]

Glad it got the brain juices running .. I wondered about making this video, but I guessed my audience would like to see these little options

[@mathboy8188]

Very cool idea. Here's a thought about how to use this idea with an opt-in approach, instead of this video's seize-all-Monobehaviors-then-maybe-opt-out-for-some approach: I'd have to test this, but since the constructor of the attribute CustomEditor() takes a C# System.Type, and interfaces are C# types, the attribute CustomEditor might accept an interface? So the idea would be to create an empty interface, maybe called IUseMasterEditor, and then "implement" them on any classes you want to use this special editor. You'd lose this video's magic of "it just works everywhere without any added code", and you'd be constrained to your own code only, but it's a minuscule amount of code to add (literally just ": IUseMasterEditor") where you want, and it does give you perfect control. But again, I haven't checked that [CustomEditor(typeof(IUseMasterEditor))] will even work.

[@WarpedImagination]

What a great idea I did remember reading somewhere that the inspected type parameter must inherit from MonoBehaviour or ScriptableObject .. but I gave it a try as it was such an interesting concept and unfortunately it didn't work out with a basic interface (not too say there isn't a hack to find to fix it though). Do let me know if you find a work around for it though as that would be a nice touch!

[@omg33ky]

@@WarpedImagination one very simple fix would be to make your own class that derives from MonoBehaviour and just use that instead of the normal MonoBehaviour you have in the script that should have the editor and in the editor script only take derivatives of that wrapper class. That has some problems if you want to create derivatives of a class that should also have this editor but in other cases it works perfectly fine

[@WarpedImagination]

​@@omg33ky Yep certainly is one of the options and a fair path to walk .. the original little trick is nice as we don't derive from anything we can just keep building components deriving from whatever (as you state), so if Math Boy's interface idea had worked it would have been so tidy .. but Unity provides and it also takes away .. lol

[@revilorere]

Fascinating!

[@WarpedImagination]

Glad you liked it

[@computer1889]

Oh? I didn't expected what I see. So you have a small subscribers huh... Just please... continue doing helpful videos, I visited your channel and it may have small views right now but in the future, people will thank you about this. Heck, I even see old videos that gets million of views after few or several years... But do you know what xD... so far, your thumbnails are very well-made... that If I judge it, I would think it has hundred of thousands of views 😂 I don't use Unity yet, I just saw this video and it looks interesting, so I watched it ;)

[@WarpedImagination]

Thank you for the kind words .. a lot of the content I create is a little niche so maybe over time as the word is spread the channel will grow. No rush I will just keep turning out the fun stuff .. but feel free to tell your friends!

[@trashcaster]

Cool video. Would it not be better to just create a custom script, say MyMonoBehaviour, that extends MonoBehaviour, and is used as a base class for your other classes, and use typeof(MyMonoBehaviour)?

[@WarpedImagination]

Glad you liked the video. There are quite a few ways to get this base editor functionality and the one you mentioned is a great option that I think would suit so many more than what I showed here .. thanks for putting it in the conversation. In this video I wanted to show the possibility so as it spur another option, maybe someone wants to decouple a library from others so that library is no longer required but optional, no base monobehaviour that the other libraries would require .. so many great paths Unity is so much fun!

[@zekiozdemir420]

Thank you!

[@WarpedImagination]

You're welcome!

[@chancerosenthal7253]

Can you name some situations in which generic editors like this would be genuinely useful? I am deeply skeptical of the Unity ecosystem's penchant for introspective doohickeys.

[@WarpedImagination]

"Doohickey" now that is a word I haven't heard in forever and one that should be used so much more in day to day conversations. Some people love generic editors others despise .. no judgement either way .. some prefer the static resource class that holds all their functionality referenced into each specific custom editor while I quite like the single source where I can place a lot of functionality and spin custom attributes to define functions or properties in the component as items of interest for a base editor to display, while refining certain items in a derived custom editor as needed .. a sort of enhanced property drawer.

[@MarekNijaki]

Nice tricks

[@WarpedImagination]

Yep I do enjoy the little tricks in game tools development