[RELEASED] Odin Inspector & Serializer - The Ultimate Workflow Tool ★★★★★

We're unlikely to add further support for this, as specifically Unity object references is something we have no control at all over. Whenever we encounter them, we explicitly let Unity handle them, as there is no actual, solid way to reference a Unity object without having Unity do it for you.

 

As you can see, I have complex list elements. Is there a way I can use an InfoBox or some other attribute that tells at what index is a specific element placed in the <List>? It would be a great help. Thanks.

 

Having trouble making a custom drawer for Dictionary to show each Key (string) as a toggle button. Yep, using a dictionary for a big tagging / flags system.
Tried making custom drawers in the same way you've demonstrated, but i get... nothing drawn and no errors. Tried keeping the dictionary in a subclass, and tried over-riding your own dictionary drawer.

Not sure how to proceed - the entire manual for Drawers is missing

 

You can use the [ListDrawerSettings] attribute to completely customize how your list is drawn. For example, this code injects a custom label before each list element.

Code (CSharp):

1. using UnityEngine;
2. using Sirenix.OdinInspector;
3. using System.Collections.Generic;
4.  
5. public class MyMonoBehaviour : MonoBehaviour
6. {
7.     [ListDrawerSettings(OnBeginListElementGUI = "OnBeginListElementGUI")]
8.     public List<Vector3> list;
9.  
10.     private void OnBeginListElementGUI(int index)
11.     {
12.         GUILayout.Label("Fancy index label: " + index.ToString());
13.     }
14. }

It results in this inspector:



You can wrap each list element completely in any code you wish, by also using the OnEndListElementGUI parameter. Hope that helps!

We're afraid that there currently isn't a good way to change how dictionary keys are drawn - even we would have trouble doing that without digging deep down into the actual dictionary drawing code. You could copy paste the entire DictionaryDrawer code from our source, and modify that to override the key drawing, but it's no simple task.

If you look at our roadmap, however, you can see that in patch 1.1, we're going to upgrade how our property and drawer system works internally, so that it becomes a lot easier to dynamically style elements in the inspector from "the outside" - so for example, you could choose to apply an attribute to all key properties in a specific dictionary. So this capability is coming! It's just not here yet, as we're currently very busy integrating and testing all features for patch 1.0.5, which is coming closer to release very fast indeed.

 

Thank you very much.

 

Anyone have issues with serialized interface fields on prefabs reverting to referencing the components on the original prefab in playmode?

For example, copies of a prefab's serialized interface fields seem to point to the instance components but sometimes on playmode they'll point to the original prefab's. Not sure what is causing this, any suggestions?

 

This should be fixed in 1.0.5 which is currently in beta. If you want' in on it, send us an email with your invoice id (for verification) and I'll send it to you.

Link to patch notes: (WIP)
http://sirenix.net/odininspector/releasenotes/1-0-5-0#version

 

Ah ok, glad to hear it's a known issue that will be fixed soon in a stable release. I have sent an email requesting the beta with my order id too, for now.

 

Hello,
I'm propably missing an obvious thing... but how can i get the type selector drop-down menu like Luizbeneton on the first page? (i have parameterless constructors so on that point it should be good)

 

It would be really fantastic if there was some sort of option to "flatten" a script with Odin property drawers / attributes into unique custom inspectors. For instance, say that I have a manager class that's extremely complex- hundreds of variables- and I want to use Odin to better manage how those variables are grouped and displayed (normal enough). If this is for internal use only, no problems, but if I ever have any intention of shipping it as a plugin or something on the UAS, the Odin libraries obviously can't be included.

That said, if there was some way to generate a custom inspector for a class based on the Odin attributes, but not actually using the Odin code, then that MIGHT be an interesting way around this limitation. In other words, translating those [BoxGroup] attributes and such from a class's main script into a custom inspector, so that the attributes aren't actually needed anymore. Of course, dynamic code generation in this way is an extremely complex area that I have only minimal knowledge of, so it simply may not be possible.

I guess my question is, given the current paradigm of this product, is there absolutely any way that this can benefit developers right now except for internal use? Making pretty editors is great, and I really love Odin, but if I (as the Unity developer on the project) am the only person who's ever going to benefit from it, that's not so great.

I have no interest at all in making a cheaper way for people to get access to Odin's features, and I understand that concern, so please understand I'm in no way suggesting that I want to be able to include Odin property drawers in my own commercial products, but a custom inspector is much harder to replicate for general use. If I could use Odin to somehow create a complex standalone custom inspector for a manager class, that doesn't have the same re-usability if included in a commercial product of mine that property drawers would have, and people buying my product would not in any way detract from the value or usefulness of Odin.

Is there any way at all to use Odin for commercial plugins, in order to assist in the creation of custom inspectors? Keeping in mind that the assets I sell are extremely cheap $5-$10 trivial things on the UAS, and that I don't make a ton of money from it, will there be, at some point in the future, some method for utilizing Odin in this way that won't force me to charge 10x more for my products or cost me more in licensing than I make from it?

Sorry for rambling- I'm just trying to be as clear as possible for a subject I'm not very familiar with.

 

Can you perhaps post some example code that demonstrates the issue you are having?

This is not the first time we've had this sort of question!

Due to the strong interest, we've been considering adding the ability to create a redistributable, "locked-down" version of Odin that people can use to create inspectors in products they distribute, but that doesn't let people who have the distributed product use Odin in their own non-product-related custom inspectors.

The license for such a version of Odin would likely be a little expensive, but would probably end up as just a one-time licensing fee. Maybe. It would likely take the form of a special purchase and download from our website. We still haven't settled on options, though, as it's early days yet, and your feedback as to which models would suit you most would be valuable.

Apart from the financial/legal model, there are also a bunch of tech issues to work out. Your suggested solution of "baking" inspectors isn't quite viable due to the way Odin's drawing works, but if we do this, we're probably going to end up doing something vaguely similar. This is probably quite a ways into the future, though, unless our early tech experiments turn out a lot more promising and easy to manage than we think they will. So in the future, we definitely want to do this, if at all possible - but don't count on it being out for a while yet, as it's a big undertaking!

 

All is fine finally... my bad. I was confused about the use of the OdinSerialize attribute on some fields type versus the fact that the type-combobox appears for list/dict values of this type or if the base class is abstract etc. (without having to use the attribute in these cases). So the Luizbeneton's code for his StatModifier class in his post confuses me a bit more at this time -___-

 

If I want to group several Types of variables in a FoldoutGroup do I have to add [FoldoutGroup("Group1")] to each line like this:

[FoldoutGroup("Group1")]
public float float1, float2, float3;
[FoldoutGroup("Group1")]
public int int1, int2, int3;
[FoldoutGroup("Group1")]
public GameObject go1, go2, go3;
[FoldoutGroup("Group1")]
public Vector3 vec1, vec2, vec3;​

Making my code a lot longer and less readable.
Or is there some other way?
Something like this perhaps:

[FoldoutGroupStart("Group1")]
public float float1, float2, float3;
public int int1, int2, int3;
public GameObject go1, go2, go3;
public Vector3 vec1, vec2, vec3;
[FoldoutGroupEnd]


​

 

This would be neat, if C#'s syntax actually allowed us to do something like that reliably. We could do it, and it would work... mostly. In a few cases, however, very strange things would happen, and people would get very confused. Ultimately, the problem stems from the fact that we do not, in fact, know the actual declared order of members. No such guarantee is provided by C#'s compiler. It just happens to generally give you the members by their order of declaration, "sorted" by their type. IE, fields, property and methods never interleave - we are given them separately.

This is the order on which we usually rely, and then we offer the PropertyOrder attribute to people, if they want buttons or properties shown in a different order, and not entirely separately from fields. Therefore, we think that what you propose would be more confusing for people than it would be beneficial, because they would see some very weird behaviour.

It is theoretically possible for us to look up the actual, precise line location of members using the assembly metadata files that are compiled by Unity alongside the actual user script assemblies. There are a number of complications here, though, but if those are solved, this would let us sort members by their actual declared order in the file, and then we could reliably do something like what you propose. That's in the future, though - we have lots of other exciting features coming up, for now.

 

Ok, thank you for the thorough explanation.
I'm curious about the new features (and will keep adding the separate lines in the meantime )

 

We're submitting a patch with these features today (asset store verification will take a few days) - and you can check my roadmap post (soon to be a page on our website) to see where we're planning on going in the immediate future.

 

Wow! quite a list!

And Persistent Editor States!
I was thinking about asking for this. But you already implemented it. Great!

 

@Tor-Vestergaard Regarding AOT Support, would it work to just add the types to a link.xml file rather than adding them to that AOT DLL? Or is the root cause something other than stripping?

 

The root cause is indeed not quite stripping. The dll also tells IL2CPP to generate code for the necessary generic variants that will be needed.

 

Hello. Is it any way to init private field default values in inner classes with Odin serialization?
For example I have some SomeClass what serialize with Odin. Is there an easy way to init field2 = 2 without call additional methods? In a real project, I can not use default Unity serializetion.

Code (CSharp):

1. public class SerializeAnything : SerializedMonoBehaviour
2.     {
3.         private int field1 = 1;
4.  
5.         [OdinSerialize]
6.         private SomeClass someClass = new SomeClass();
7.  
8.         private void Awake()
9.         {
10.             Debug.Log(field1); // Write 1
11.             someClass.LogField2(); // Write 0 but if I use SerializeField instead OdinSerialize will be 2
12.         }
13.     }
14.  
15.     [Serializable]
16.     public class SomeClass
17.     {
18.         private int field2 = 2;
19.  
20.         public void LogField2()
21.         {
22.             Debug.Log(field2);
23.         }
24.     }

 

You need to make sure that the values you want to keep are serialized - otherwise, they will become their type's default values upon deserialization (such as pressing play/script reloads/restarting editor, etc), since deserialization creates uninitialized objects without calling any constructors or field initializers, and then fills those uninitialized objects with the saved data. Since there is no saved data for field1 and field2 when deserializing, they will never be initialized with anything but the default value for an int type, namely "0".

If you change your code to this, it will work and the values set in your field initializers will be kept.

Code (CSharp):

1. public class SerializeAnything : SerializedMonoBehaviour
2. {
3.     [SerializeField]
4.     private int field1 = 1;
5.  
6.     [OdinSerialize]
7.     private SomeClass someClass = new SomeClass();
8.  
9.     private void Awake()
10.     {
11.         Debug.Log(field1); // Write 1
12.         someClass.LogField2(); // Write 0
13.     }
14. }
15.  
16. [Serializable]
17. public class SomeClass
18. {
19.     [SerializeField]
20.     private int field2 = 2;
21.  
22.     public void LogField2()
23.     {
24.         Debug.Log(field2);
25.     }
26. }

 

Thanks. But I don't need to save this filed. I just need to get initialized value in runtime. So serialization call FormatterServices.GetUninitializedObject or something like this? Is there some callback when it serialize inner class?

 

We do indeed use exactly FormatterServices.GetUninitializedObject to create the object instances that we then deserialize data into. Odin supports all .NET serialization interfaces, attributes and features, so there are lots of different callbacks you can hook into in SomeClass. Simplest for you is probably the [OnDeserialized] attribute.

Note, however, that we do not support all of these interfaces and attributes on the Unity object itself, as deserialization there works in an entirely different manner. You can still, however, override OnAfterDeserialize (and OnBeforeSerialize) and get a callback that way, if you need one. So it could be done like this:

Code (CSharp):

1. public class SerializeAnything : SerializedMonoBehaviour
2. {
3.     private int field1 = 1;
4.  
5.     [OdinSerialize]
6.     private SomeClass someClass = new SomeClass();
7.  
8.     private void Awake()
9.     {
10.         Debug.Log(field1); // Write 1
11.         someClass.LogField2(); // Write 0
12.     }
13.  
14.     protected override void OnAfterDeserialize()
15.     {
16.         field1 = 1;
17.     }
18. }
19.  
20. [Serializable]
21. public class SomeClass
22. {
23.     private int field2 = 2;
24.  
25.     public void LogField2()
26.     {
27.         Debug.Log(field2);
28.     }
29.  
30.     [OnDeserialized]
31.     private void OnDeserialized()
32.     {
33.         field2 = 2;
34.     }
35. }

 

Thanks for the help.

 

Hey,

I have a GameObject which serves as a repository. I added the ItemRepository script and used the Inspector to add a lot of ItemDefinitions.

Code (CSharp):

1.     public class ItemRepository : SerializedMonoBehaviour
2.     {
3.         public List<ItemDefinition> ItemDefinitions;
4.     }

Now I have some GameObjects with the Person script on them. There I am adding Items using the inspector. What I now want is to be able to select an ItemDefintion from the Repository-GameObject.

Code (CSharp):

1. public class Person : SerializedMonoBehaviour
2. {
3.     public Dictionary<int, Item> Items;
4. }
5.  
6. public class Item
7. {
8.     public ItemDefinition ItemDefinition;
9.     public int Count;
10. }

This would allow me to specify some items globally and add those items to the inventories of my persons. Is there a way to achieve this neat behavior?

 

You could theoretically do stuff like this using Odin's serialization, by saving the indices of items and utilizing all sorts of callbacks to fetch the items at the correct times and populate your Person with the actual values from the ItemRepository object, but it would be fairly clunky and not very easy to do. There are all sorts of possible hurdles to climb, from ItemRepository possibly being deserialized later than Person (making it difficult to fetch the values at deserialization time), to having to write and maintain the code to link everything up.

Odin's serialization system does have an extendable system for creating "external references" - references that point out of the serialized graph, that are then resolved at deserialization time. This is how Odin handles references to Unity objects, actually. However, it's still going to be clunky as hell in this particular case.

Essentially, Unity just isn't set up to handle persisting the "same" non-Unity-object reference values on different Unity objects, and Odin generally tries to stick to the basic patterns that Unity has set in place.

This, however, is the exact sort of use case that Unity's ScriptableObjects are made for. In your case, I would make ItemRepository a ScriptableObject, and I would also make ItemDefinition a ScriptableObject. Have an ItemRepository asset in your project (made using the [CreateAssetMenu] attribute), and drag a reference to that wherever you need it on components in the scene.

Also, a tip: Unity doesn't expose this in the editor UI, but you can actually add assets as children of other assets, so as a matter of organization, you could make all your ItemDefinition ScriptableObjects children of the ItemRepository ScriptableObject after you create them with ScriptableObject.CreateInstance, so it's just one asset plus children in the project view, instead of a whole mess of assets. This is done using AssetDatabase.AddObjectToAsset.

I encourage you to read up on how Unity's asset database and ScriptableObjects work, and play around with it a bit. This is how Unity generally intends you to do "cross-object referencing", and in your case, it sounds like the best solution.

 

A bit of news
We've decided to turn our own forums at forum.devdog.io to "read-only" and instead switch to our own Discord server.

The Discord server will allow for faster support and quicker messaging back and forth!

So if you're experiencing any issues, have feedback, or just want to show-off whatever you've made using any of our tools and hang out with us, come join: https://discord.gg/zjNj5zZ

 

I hate discord as a form of support. The same questions are asked over and over again because it is not good at being searchable. In a proper forum, there is a database of questions and answers, all categorised, that are searchable so that maybe I can find the answer to my problem before I have to ask. Also saves the devs time. This stupid Discord is just another stupid geek fad.

 

I hear you... But we didn't have our own forum before, so Discord is just one more social-media where people can reach out to us or come and hang out if like. Our hope is that it will engage the community more, and maybe even help us out answering questions as well .

And yeah, we do get a lot of the same questions asked again and again, and Discord will defiantly add to that. But we've actually just made a new Odin FAQ page (which went live yesterday) that will help us out a lot. It has categories and search, and all that. So we plan on answering a lot of the future questions we get from Discord, Twitter, Reddit, Email, this forum thread etc... in there so it becomes a good resource over-time.

 

Hi,

I'm using Unity 5.6.3f1. The inspector with this asset is not really an improvement. Please fix the following:



1. If my code has more than one [Header("text")] for one field, then I get the ERROR's in the inspector.
2. One [Header("text")] for an array is shown multiple times. For the list and for each item. Please remove this for each item.

Please check it for Unity 5.6.3f1 a bit more carefully, this is the last release for the commercial 4.x-5.x license. I and a lot of us just uses Unity as a game engine platform, because in the asset store you always find a better solution for Unity built in features.

 

Hello.

Quick question as I'm considering purchasing Odin (well to be fair, I already know I'll buy this at some point; just maybe not for my current project). Also, pre-apologies if the answer I seek is detailed in the documentation or posts above... admittedly I haven't already read either.

My question is this - out of the box, will Odin allow me to use an enum for Keys in a dictionary inspector, hence allowing the users to select Keys (or I suppose even values, for that matter) from a dropdown to fill in the Keys in the inspector? If not, this would be a great feature and would allow me to build in a bit of "author-time" validation. If this is supported for Keys without us having to write our own drawers/inspectors, will they properly shrink the dropdown selection upon entry of each Key (ie can't have duplicate Keys in a dictionary)?

Thanks.
-Kevin

 

Thanks for the heads up on this one - it turned out to be a fairly pervasive issue that has been sneaking in a few places as we've been introducing new features. We just made a slight change to our property context system that should make it far harder for us to cause errors like this in the future. This fix will be in the hotfix patch we're going to be releasing for 1.0.5 very soon.

If you need the fix urgently, you can mail me at tor@sirenix.net with your Odin invoice ID, and I'll make a build and send it to you right away.

Odin does indeed support enum key types in dictionaries! Odin, in fact, supports keys of any type on dictionaries in almost all cases. Key type support is limited on specifically prefab instances due to how prefab modifications work, but even there, there is support for enum keys.

Sadly, we don't gray out the enum values of keys that are already in the dictionary, in the enum dropdown itself. This is a neat idea, and we can implement it after our property rebuild in 1.1, but there's no easy way to do it right now. However, the add key button does gray out if the key you're trying to add already exists in the dictionary.

Here's a gif of how our dictionaries work:

 

Great news, everyone!

First of all, Odin is on sale in case you haven't noticed.
We're going to increase the price after this sale, so Odin will never be cheaper than this (even during future sales).

And also - Odin is a finalist in the Unity Awards, and we need YOUR help!
You can go vote for Odin right here: https://awards.unity.com/

 

This looks really neat and I'm tempted to buy a couple of licenses for a current project. We've a lot of semi-complex stuff to do in the Inspector that looks like it'd benefit from this, and I'd love better integration of various C# data types in Unity.

But... I see a review on your Asset Store page which says:

Can you please expand on this a little? What parts are/aren't you confident of in your serialization, and what (if anything) is likely to have compatibility-breaking changes in the future?

 

Oh, that's of interest, too. Can you tell us what it's going up to? I don't want to rely on something that might make expanding my team later on a pain.

 

Oh yes!

 

I love this plugin, makes life a lot easier!

I would really appreciate if you could make a Foldout that looks the same as Toggle so it fits the style when you use the two together.
Basically I want the Toggle appearance but without the checkbox

 

So far, Odin's serialization has held up very well since we released, and has consistently proven to be the most reliable, bug-free part of the plugin. It was also the part of Odin that was written first, and so it saw heavy use and testing during the development of the rest of Odin. Our cautionary warnings are merely us exercising due caution.

A lot rests on serialization. As such, we want to make sure it is 100% safe to use before recommending people to use it in their projects. We're confident Odin's serialization feature currently works as expected; however, even a small issue could theoretically corrupt a project's serialized data quickly. We haven't had any such issues, but with people's precious serialized data, there is no such thing as being too safe. Therefore we want to very, very thoroughly vet and test Odin's serialization before we actively recommend people to use it, and that seems to be going very well.

Additionally, as is the main point we state in our manual, the freedom that Odin's serialization gives you to arrange your data exactly as you want it can be a mixed blessing. On the positive side, you can do anything you want, and on the negative side, well, you can do anything you want. More freedom isn't always good, unless it comes with proportionally more restraint. It is very easy for people to get themselves into a mess with highly complex data structures that have no real need to be so complex, and could be better expressed in a simpler way.

Therefore, as a rule we recommend people to exercise due caution and restraint when using our serialization system, as we would with any other tool that's so powerful and flexible. It's always best to let Unity serialize your data if you can, since Unity's system is simpler, faster, and has been in use for much longer. Odin's serialization is intended to lap the gaping holes in Unity's serialization that people find so painful - not to replace it entirely.

As for future compatibility-breaking changes, it's very simple: they won't happen. It is very important to us that the serializer is and remains totally backwards-compatible. The robustness and integrity of the serialization system is, and remains, our first priority.

So, to summarize: Can you use Odin's serializer? Absolutely, but be aware of the risks - both on your end and on the serialization's - and always make sure to keep backups, just in case. After all, that's just common sense

 

Hey, a stupid question:

If I need to change the same property of many game objects on scene at once, can I do this with this asset?
I just hate to change it one by one by hands
May I change just one value and all game objects are updated automatically?

 

Odin supports multiselection, but only to the same degree that the regular Unity editor does. If you can't do it with multiselection in Unity's regular editor, I'm afraid Odin won't be of help here either. You could always write your own custom editor script to go through all your gameobjects and change the values, but that process would be the same both with and without Odin.

 

Quick question. I have not started using Odin to create anthying yet, just checking you demo scenes. each time I click on any item in your demo's to check the inspector it is taking quite a long time to load before doing so or switching between items. Is that normal or possibly my system or settings?

 

how to show or hide a variable based on some enum value?

 

That does not sound normal no. It should switch between inspectors almost instantly. The first time you inspect something after having installed Odin, it will lag a little, because Odin needs to generate a few config files if they don't already exist. But other than that, it should switch smoothly between inspectors, even on really old 32 bit computers.

Does it happen on all demo examples, and Is it also slow if you try Odin in a clean project?

ShowIf, HideIf, EnableIf, and DisableIf are all getting enum support in the next patch But for now, you can get the same functionality through a property or a method like so:

Code (CSharp):

1. [ShowIf("ShowA")]
2. public int a;
3.  
4. private bool ShowA() { return this.someEnum == SomeEnum.ShowA; }

 

Could you tell us how much up will the price of Odin go after the Sale?

 

We plan to increase the launch-discounted price of $35 to $45-55 after the sale.

Odin has consolidated a lot over the past months, and we were actually planning to update the price in August, but then we became part of the "Back to School" sale, and those plans were thus delayed a bit

 

Ok. I found the culprit. It seems to only happen in the 1st demo whenever the AssetList item is clicked on. I imagine the long load time is from the actual gameobject assets getting referenced in the inspector. All the rest including the other two scenes are snappy.

 

I have an array with elements that I'd like to reorder in the inspector. Would it be possible to reorder the elements of the array in the inspector and have the reordering be reflected for the array?

Reordering = clicking and dragging the elements of an array and moving them around (inspector)?

 

I sit possible to create a dropdown where I can multi-select elements from that dropdown?

This is a fantastic tool, and I wish I came across this earlier!

 

Having been looking through the demo scenes, you can. If you own it, take a look.