Last active
December 9, 2016 09:55
-
-
Save NPatch/5a5b2cdbd0a42e9beba155a50bc1ab2e to your computer and use it in GitHub Desktop.
Custom Editor/Drawer property serialization per instance
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At this point, creating custom editor scripts or custom drawers for specific classes and having the ability to keep editor/drawer only properties serialized is to create a helper class or helper fields inside the class we are trying to draw , wrapped with | |
#if UNITY_EDITOR | |
#endif | |
and grabbing it as SerializedProperties inside the custom editor/drawer script and at the end of the process, write back all changes. | |
If we have lots of classes around and we want to do fancy stuff and have drawers/editors for many of them and having them blend | |
with eachother to achieve reuse etc, it becomes quite combersome towards the size of the codebase just for editor stuff. | |
The problem currently is that we can't differentiate between instances of a single type. If we could differentiate we would be | |
able to pinpoint any such property , eg a foldout in a drawer for X type, by querying some form of database(be it an actual database or an asset or a dictionary in memory) about the properties for that instance and then for the field "Somefoldout". | |
It would then be easy to have an extendable db of properties for any custom editor/drawer for stuff in the scenes, by simply querying ids about the instance we are drawing and updating the saved values when stuff change. | |
For example, one thing I really hate about custom Drawers is that you have to mess with Rects, meaning correctly updating sizes | |
per iteration. So if you want to persist the size of having a foldout open, you have to keep track of the aggregate height and | |
store it so that when you call GetPropertyHeight for this type in another editor , it knows to grab that last value. And the | |
more things you have to draw, the more SerializedProperties for foldouts and heights you have to store and the code for the drawer, becomes even larger. | |
It would be nice if you could query stuff like that and update them using ids in one place. That would mean no UNITY_EDITOR wrapped classes inside your scripts, nor extra code in the drawers/editors for those SerializedProperties. | |
Ideally, I'd like this thing to have an easy way of adding an instance and then fields, also easy way of querying them and finally storing them on disk for persistency. I really like the idea of those .json files VS Code keeps around for settings. | |
Gives an easy way to store preferences and easy querying using string ids. | |
One solution is to keep a scriptable object around in the Editor folder with all that info inside and have a static class which, | |
initializes on Editor launch and serializes stuff back to disk on editor close(and perhaps some other events to prevent data loss in case of crash), that can also have Dictionaries for fast queries and adds/saves. | |
The hard part is actually being able to pinpoint the property, you are currently drawing for, to a single instance inside the whole project. | |
For that I would like to have access to the internal PersistentManager for tracking changes and getting the LocalFileIDs which | |
is enough to pinpoint instances. | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment