Assets [WIP] Odin Inspector & Serializer Looking for Feedback

We’ve built Odin Inspector to make it easy to build powerful and user-friendly editors for yourself and your entire team, making it easier for developers and designers alike to use Unity more efficiently. So, what does this mean?

Sign up for the mailing list
>> View on Asset Store <<
More Info​

It means that Odin is super extendable, easily integratable and includes full source code access. Read on below to find out how Odin deals with Serialization, Input Validation, Value Dropdowns, Powerful Lists, Customizable Layouts, Color Palettes, Asset Lists and more!

We’re on a mission to build the best inspector and serializer ever for Unity, and we’re proud to soon allow you all to be able to see for yourself why we’re so hyped about this release!

Be sure to check out the to-do list at the end of this post to let us know which of the features you want the most and leave additional feedback/ideas.

Odin Inspector & Serializer has been developed by the fantastic team at Sirenix, and published by Devdog.

Sign up for the mailing list
>> View on Asset Store <<
More Info​

Main Features

Serialize Anything!
A simple, straight-forward data structure is often the way best way to go, but there are times where you simply need to serialize that complex generic, polymorphic type with cyclic references. This is where our custom serialization protocol comes into play.

You can either inherit from one of our many in-built serialized classes, such as SerializedMonoBehaviour and SerializedScriptableObject, or add a few lines of code to your existing classes.

Oh, and in case you were wondering, it has:

• Full support for polymorphism, cyclic references and null values
• Full prefab support
• Serialize delegates
• Built in Binary and Json Formatters
• High performance and close to zero garbage generation
• Follows all Microsft's .NET serialization standards
• Customize serialization by creating your own type formatters and data formats
• Supports external references to objects such as Unity objects and assets.
• Special editor-only node format is mergeable via source control

Input Validation
Bugs are often caused when a designer doesn't know how a component works and accidentally sets an invalid value. This causes many errors, and can waste a lot of time that might have been productive while they look it up in a manual or consult with the developer who wrote the component.

Odin lets you easily write custom validation logic to ensure only correct values are set, and lets you give sensible feedback right in the inspector. Providing informative warnings, or simply disallowing invalid values, goes a long way towards minimizing the amount of potential bugs and smoothing out your workflow.

• Write custom input validation logic
• Prevent invalid values from being set
• Give designers useful feedback in the inspector
• Provide custom conditional UI messages for any property
• Use built-in attributes such as SceneObjectsOnly and AssetsOnly

Powerful Lists
All arrays and lists are drawn by our powerful list drawer.

• Drag and drop, insert and delete individual items
• Cross-list and even cross-window item dragging
• Paging for lists with many items
• Infinite nested list drawing
• Fully customizable though settings and / or using attributes

Customizable Layouts
Properly ordering, labeling, hiding and grouping your properties helps the user to faster find what they are looking for.

• Group properties into Tab Groups, Foldout Groups, Toggle Groups, Horizontal Groups, Button Groups and more
• Hide or show or enable or disable properties based on your custom conditions
• Mark properties readonly or disabled
• Custom property ordering
• Hide or rename labels entirely
• Display custom messages based on values
• Easily draw custom GUI before or after properties

And much much more!...

Spoiler

Color Palettes
Define project-based color palettes for your whole team to share, and mark relevant color properties to show a color palette right next to the color picker.

• Works with all Unity's Color types
• Palettes are stored as an asset, making the entire team share the same color palettes
• Easily create new custom color palettes

Value Dropdowns
One way of easily preventing invalid values from being set, is by providing the user with a list of valid values to choose from.

The ease of dropdown selection is no longer limited to just enums. Odin lets you create a dropdown with value of any type to choose from.

• Create dropdowns for any type
• Manually specify name for items that do not implement .ToString() properly

Asset Lists
Finding the right assets can sometimes be a hurdle in big projects with lots of files. The AssetList attribute replaces the default list drawer, with a toggle-list of all relevant assets relevant to your use case. The user can then toggle relevant assets in and out of your list.

• Filter the asset list by folder location, tags, layers, name prefixes, etc...
• Only shows assets assignable to your list type
• Works on all asset types, including components on prefabs
• Auto populate mode that automatically adds all relevant assets in the list
• Easily create new assets that meet your constraints

But most importantly! Odin is fully customizable
We make it easy to configure how you want the inspector to act in your project, and trivial to create new configurations for your own custom drawer types.

• Customize the inspector to suit your needs and preferences
• Create integrated configurations for your own drawers

We’ve spent the last 8 months developing Odin, and after a beta test to perfect it, we’ll release it at a release-discount on the Asset Store. So be sure to check back as soon as it is released.


We’ll continually improve upon Odin, so we’re looking for feedback on which features from the To-Do List you’d like to see developed first.

To-Do List:

• Save play mode changes
• Delegate Drawer for any delegate type
• Dictionary Drawer
• Adding a static inspector
• In-line Unity object editing (expand a Unity object into a dropdown instead of changing inspector window to view its values)
• Object snapshots / restore feature allowing you to restore an object to previously saved states

Sign up for the mailing list
>> View on Asset Store <<
More Info​

- Your friends at Devdog and Sirenix.

 

Wow! This looks absolutely amazing!

 

The first teaser video showing off just a tiny part of all the things that are made possibly by Odin is now up:

 

Hello @SuneT @jorisshh. Looks really interesting this new inspector tool, and how simplify the process of creating custom editors. At the moment I'm a solo developer and working on a project that I'd like to incorporate this sort of custom editor.
So my question: if I create a custom editor with this tool, Is there going to be a way to export the custom editor created so I can include it in a project I'm going to publish in the asset store? Obviously without including the source code of Odin Inspector.

 

Hello @hernanperez85, Sirenix developer here.

You can easily do that, as your custom editor would simply be a script file that Odin detects through reflection at runtime. You may simply include all of your Odin scripts in your assets.

Odin declares its presence in a Unity project by adding a define tag to all platform targets. This means you can simply wrap your Odin-dependent scripts with "#if ODIN_INSPECTOR", and the script will become active if Odin is in the user's project.

 

Hello @Tor-Vestergaard, that's great!, Thank you for you quick response

 

This looks awesome. One thing I usually always have to write custom editors for, is adding buttons in the inspector that runs code in my MonoBehaviours. I would LOVE if you guys added the functionality to add an attribute to a method, that could then be called via a button in your custom editor.

Examples of the stuff i usually have to write editors for myself:
Button: Die (kills the character and despawns it with death effects)
Button: DealDamage(100) (deals 100 damage to the character, which can trigger Die internally).

 

Already asked and was answered in this reddit thread, x-posting this info in case any forum users have similar questions:

Question

I am already in love with this extension, we've spent a lot of time building in-editor tools to automate our game's maze generation, I've always felt the UI was clunky and crowded but have never had the time to properly address it. I'd gladly drop $ to save said time.

Is your price point per seat? While I do adore how extensible and customizable Odin seems, to what degree can I get it going "out of the box"? For example, if I just wanted to get some tab and toggle groups integrated into our editor tools and get to the fancy stuff later, could you describe how involved that would be?​

Answer

You simply install Odin, and it's present everywhere, for every class that doesn't already have a custom editor defined. You don't even have to inherit from a special type. This means, for example, that all lists and arrays, everywhere, even on Unity's own engine components, get the Odin upgrade. This is, of course, all very easily configurable.

Integration is seamless. If you've already made custom property and decorator drawers for vanilla Unity, Odin finds and integrates these into its inspector, so nothing gets lost. Everything you've done to extend Unity's editor, will extend Odin in exactly the same way.

So to answer your question, all you have to do is drop the provided .dll or Odin's source code into your project, add the attributes to your members, and enjoy.

And if you want to integrate Odin Inspector into your own custom editors, it's literally a matter of two lines of code to draw a property tree for any set of objects: 1) Create property tree, 2) draw property tree. And that's for any object type at all, not just Unity objects.

Edit: I might add, if you already have some very involved custom editor code, and you can't simply switch over to a different drawing system at all, we do provide a vast public API of GUI utility methods to make drawing something that's ordered and looks nice far easier than it is with Unity's very rudimentary API, and you can use those utilities wherever you want.

Edit 2: And sorry, I just noticed you asked; yes, the price point is per seat.​

 

This is already in the Inspector; there are even special group types for dealing with and arranging buttons in nice ways.

@murkantilism Cheers, thanks for the x-post!

 

Possibly the most important feature I'm looking for is this:

Can I select a bunch of assets, drag and drop them into an array, and they don't fill the array in a batshit insane order like they do in the standard Unity inspectors?

 

Looks cool. Does it work with scriptableobject where the name of the file might not necessarily match class name? etc...

 

In case you're curious, it's not batshit insane or completely random. It's the order in which the elements were imported into Unity. So if you have sprites 1 to 100, if you were to import them all one by one in the correct order, then a drag and drop into an inspector array should yield a nice sorted result.

The solution to get it auto-sorting in alphabetic or alphanumeric order is pretty simple, so I'd imagine it could be added to Odin easily if not already there. But they might have the same thought process as Unity; not all users want it sorted by name but by other metrics. If you offer one sorting behavior you'll have to offer all common sorting behaviors, otherwise you're bound to make some folks unhappy. That's why Unity went with the obscure and largely useless default sorting behavior.

 

Right now, they'd just be inserted into the list in the same order as Unity usually does it. However, we could easily add a configuration option for different ways of sorting them before insertion. It wouldn't be hard at all to add a few "right click list -> sort -> by name/import date/type/whatever" commands. I'll add this to the list of minor UX additions to sort out. It should definitely be in before release.

( And if it wasn't in by then, it would be fairly trivial for you to add it yourself. These days we don't really touch Odin's core code except when we find bugs to fix, we just extend it in the same way any user would. )

It doesn't, sadly, as we do still operate through custom editors that live in Unity's own inspector window. If Unity can't make sense of the asset type, then Unity doesn't even know to create our editor to inspect it. If you have your own window, though, it would be trivial to make Odin draw the asset with a few lines of code; Odin will handle it just fine. The only issue is on Unity's side, and we can't do much about that, unless we want to make our entirely own inspector window and trying to subsume Unity's, which would be quite a messy solution, and wouldn't be a very clean integration into Unity.

 

Random thought, why Odin? Devs are a fan of Norse mythology?

 

As Sirenix is a danish company, we are indeed fans of Norse mythology! That's not the only reason the name fits, though; Odin is a god often associated with knowledge, magic, insight and wisdom. He gave one of his eyes to drink of the waters of wisdom from Mimir's Well. He spies the world through his ravens, Huginn and Muninn. Odin sees and knows all.

The Odin Inspector is all about introspection and reflection, knowledge about things and what they consist of and how to change those things. So you see, the Odin Inspector's job is basically to see and know all, and to convey this information to you.

That's maybe overthinking it, but these thoughts did cross our mind and were factors when we settled on the name. Mostly we kind of just like it, though.

 

Next teaser is up - this time showing exactly how the Odin Asset List feature makes it easier to find the right asset in big projects with lots of files.

The AssetList attribute replaces the default list drawer, with a toggle-list of all relevant assets relevant to your use case. The user can then toggle relevant assets in and out of your list.

• Filter the asset list by folder location, tags, layers, name prefixes, etc...
• Only shows assets assignable to your list type
• Works on all asset types, including components on prefabs
• Auto populate mode that automatically adds all relevant assets in the list
• Easily create new assets that meet your constraints

 

I have a couple of inspector extensions. will be interesting to see what you came up wth

 

Any chance of support for 64-bit [flags] enums?

How does this compare to Full Inspector?

 

There is support for 64-bit flags enums, yes, though currently you do need to make it backed by an ulong to get the full range.

As for how we compare to Full Inspector: at release, we won't have all the features it does. We will have some features it doesn't: faster and more robust serialization that doesn't have nearly the same performance impact as Full Inspector's does, a broader selection of attributes and features to tweak the inspector appearance with, greater ease of extendability, not needing to inherit from a specific base class to get the inspector, being able to apply the inspector to many Unity types as well and so on.

Odin is designed to work well with enterprise-level workflows that make heavy use of source control and require tight performance and very reliable serialization. Most importantly, perhaps, it's painstakingly designed to be able to drop into huge, complex projects that have already customized their editor greatly, provide an inspector upgrade across the board, and still work without any issues, and without breaking anything, incorporating all the same customizations into its own inspector.

Over time, we'll add more features. We've concentrated most of our efforts so far on building an array of very solid and highly extendable core systems. Given this, once we've released, adding more features as we go along will be fairly easy.

 

For 64-bit Flags enums, I'd have this...

[Flags]
enum Flags : ulong
{
None = 0,
Flag01 = 1uL << 0,
Flag02 = 1uL << 1,
Flag03 = 1uL << 2,
Flag04 = 1uL << 3,
Flag05 = 1uL << 4,
Flag06 = 1uL << 5, Flag07 = 1uL << 6, Flag08 = 1uL << 7, Flag09 = 1uL << 8, Flag10 = 1uL << 9,
Flag11 = 1uL << 10, Flag12 = 1uL << 11, Flag13 = 1uL << 12, Flag14 = 1uL << 13, Flag15 = 1uL << 14,
Flag16 = 1uL << 15, Flag17 = 1uL << 16, Flag18 = 1uL << 17, Flag19 = 1uL << 18, Flag20 = 1uL << 19,
Flag21 = 1uL << 20, Flag22 = 1uL << 21, Flag23 = 1uL << 22, Flag24 = 1uL << 23, Flag25 = 1uL << 24,
Flag26 = 1uL << 25, Flag27 = 1uL << 26, Flag28 = 1uL << 27, Flag29 = 1uL << 28, Flag30 = 1uL << 29,
Flag31 = 1uL << 30, Flag32 = 1uL << 31, Flag33 = 1uL << 32, Flag34 = 1uL << 33, Flag35 = 1uL << 34,
Flag36 = 1uL << 35, Flag37 = 1uL << 36, Flag38 = 1uL << 37, Flag39 = 1uL << 38, Flag40 = 1uL << 39,
Flag41 = 1uL << 40, Flag42 = 1uL << 41, Flag43 = 1uL << 42, Flag44 = 1uL << 43, Flag45 = 1uL << 44,
Flag46 = 1uL << 45, Flag47 = 1uL << 46, Flag48 = 1uL << 47, Flag49 = 1uL << 48, Flag50 = 1uL << 49,
Flag51 = 1uL << 50, Flag52 = 1uL << 51, Flag53 = 1uL << 52, Flag54 = 1uL << 53, Flag55 = 1uL << 54,
Flag56 = 1uL << 55, Flag57 = 1uL << 56, Flag58 = 1uL << 57, Flag59 = 1uL << 58, Flag60 = 1uL << 59,
Flag61 = 1uL << 60, Flag62 = 1uL << 61, Flag63 = 1uL << 62, Flag64 = 1uL << 63
}

...and declared like this:

Flags myFlags = Flags.Flag01 | Flags.Flag32 | Flags.Flag64;

How would that appear in the inspector...drop down with 65 multi-selectable check boxes (I hope)?

In the enum, I might also have Flag05thruFlag08 = Flags.Flag05 | Flags.Flag06 | Flags.Flag07 | Flags.Flag08 as shortcut to setting those flags together.

 

That would indeed work exactly as you describe it. In fact, I just copy pasted your code (with a special flag added) into Odin and took a few screenshots.

( Note that I'm using Odin's special serialization. This is because Unity logs a lot of errors complaining about invalid enum backing types if you create a field with an "invalid" enum that it thinks you want it to serialize. )

Spoiler: Flags enum screenshots

Code


Editor


Clicking myFlags


Clicking specialFlags
​

 

THANKS! As I understand it, it's really a mono problem, since a normal C# app has no issue with such things.

So my class needs to inherit from Odin's "SerializedMonoBehavior" which would still have the normal Awake, Update, etc. as that just extends Unity's MonoBehavior. Cool.

 

Latest teaser GIF for the Odin Inspector & Serializer is live.

Also, beta testing is getting really close now!

 

This looks fantastic. Is there any way I could sign up to try the beta? I need a new inspector asset, AdvancedInspector's started causing problems.

 

We're starting closed beta testing this week, and already have a solid list of testers (sorry ). Depending on the number of bugs our testers find we should be able to release within a few weeks.

If you'd like, you can sign up to the newsletter and you'll be notified when Odin hits the asset store (The newsletter is only used for product launches, big updates and giveaways).

 

Alright, sounds good.

 

The beta testing is going great, but we're looking for teams of 8+ people to really test the limits of Odin in a few large projects.

If you are part of a larger team (company of 8 or more people), be sure to send an e-mail to sune@devdog.io, and we'd love to have you be part of the beta testing of Odin!

 

Hey, I saw beta-test info on twitter, how may I join it? Currently using Adv.Inspector but it cause some problems we want to get rid of.

EDIT: Ouch, 8 people

 

Hi,

Our studio (https://lonestone.consulting/en-UK/ , 6 full time + freelancers) would be happy to give Odin a go. We would be glad to finally have an editor correctly handling polymorphism for custom classes (non scriptable object).

 

Great - Could you send an email to joris@devdog.io from your company's mail account?

 

This looks like it could save a ton of time.

The big question, though: does your serialization work with AOT platforms? Especially XBoxOne, PS4, WiiU. Those have a tendency to break serialization libraries real hard due to how generics (doesn't) work on AOT platforms.

EDIT: Also, what's the price point?

 

As of the most recent (beta) patch, Odin is supposed to work on all AOT platforms, though we haven't had access to the hardware necessary to test this thoroughly yet. XBoxOne, PS4 and WiiU are not yet among the tested platforms. So far, in fact, we've only had time to test AOT serialization on WebGL, where it worked fine.

During the beta, we will be testing our serialization thoroughly on as many platforms as we can get our grubby hands on, and fixing any possible issues we encounter as they come. Later on, Odin will also be able to pre-emit serialization formatters into an assembly in the editor, which would then be included in AOT builds, boosting performance and completely obviating any need for reflection at runtime, enabling support even for very tricky platforms like Windows Store. Ultimately, we would like to have 100% support for all platforms that Unity targets.

As for the price point, we're planning an initial launch price of $35. The price will increase in the future as we keep adding more features and improving Odin even more.

 

I am really interested in Odin Inspector vs Advanced Inspector comparison. What are the main advantages of Odin? Thanks

 

With Odin still being in beta, with more features still to come and a lot of testing still to be done, this is a tricky one to answer, but I'll do my best.

I could try to do a feature-by-feature comparison to Advanced Inspector and Full Inspector, and say things like "Odin offers more powerful editor customization with its attributes", "We have much stronger features for input and scene validation, cutting down on entire classes of bugs", "Our serialization is a lot faster and allocates close to zero garbage at runtime", and so on. While those points are true, I'm not going to do that. (Except to the extent I just did )

The fact is that while Odin does have many features that Advanced Inspector and Full Inspector don't, we also currently miss many that they have in aggregate. Of course, we're adding more every day, and will eventually more than match them both put together if you put them on a point-by-point comparison list. However, we feel the core difference lies on another level, a qualitative as opposed to quantitative one, that touches every part of the product, and is not as simply put as just listing raw features side by side.

Imagine you're a large game studio, with dozens of people working on a game in Unity. You're all losing a lot of time to constantly writing custom property drawers to make your editors look nice, having to deal with the vanilla Unity editor's many idiosyncracies and lack of powerful workflow features, and having to finagle your way around Unity's limited and rigid serialization. You absolutely need an inspector upgrade, and so you look at what's available. This is a huge decision to make.

Whatever you pick, this will affect every person on the team that ever touches Unity; whatever enhancements or limitations it offers, these will apply globally across your team. Since you've already spent significant time modifying your editor, it may also require a lot of integration work and rewriting of editor code before you're back to the point you were before. If you plan on using the serialization, it can't affect your game's performance, which is already stretched tight with all kinds of neat features. And of course, being a large team with a huge project, containing hundreds of thousands of lines of code and thousands of assets, it is absolutely critical that the inspector upgrade be utterly reliable in a massive enterprise environment.

These are the kinds of extreme conditions under which Odin is intended to excel: being dropped into a major project, full of pre-existing editor customizations, with major demands on performance and stability, and still performing without a single hiccup.

In the given example, the team could simply drop Odin into their project, and immediately their inspectors have been upgraded across the board without them lifting another finger, touching the configuration, or changing a single line of code. Furthermore, all of their old custom property drawers and attributes, all of their old customizations, are still there, integrated into Odin.

They try the custom serialization: null values, polymorphism, cyclic references - all of it is handled and shown intuitively in the inspector. Their old custom property drawers are also being drawn for this new, non-Unity-backed data. Prefabs using the custom serialization work just the same as before - there is no perceivable difference.

Immediately, they can get to work again. There's no onboarding, no radical new workflow or paradigm to learn. At their leisure, they can peruse Odin's demos and documentation to get an overview of the dozens of new attributes they now have available to augment their editors. And then, finally, when their demands increase and change, Odin is highly customizable, with a modular and extendable design that can be adjusted to fit their particular needs. To help with this, every single public and protected member in Odin's source code will be documented.

All of the above also illustrates an important point: Odin doesn't change the way Unity works or enforce any new pattern on you. There is no integration boilerplate required. Where possible, it always integrates what is already there. If Unity adds a new data type, and a new property drawer for that type, or if they add a new property attribute that is drawn in a special way, that will be found and used by Odin. We don't try to supplant or replace Unity - it's solely an additive upgrade, not a lateral or subtractive one.

So that's Odin's ideal, so to speak: rock-solid reliability, extreme ease of integration, and making it trivial to design very powerful custom editors using only attribute annotations. It's the rigorous standard Odin has to uphold before we're satisfied with it. We want to deliver a dependable product of the highest quality, with a smooth and polished user experience, and we don't want to compromise on that.

The current beta testing will bear out how close we are to having achieved this goal. We're asking our testers to throw everything and the kitchen sink at Odin, to tie chains around its ankles and dunk it in the deep end of the pool without mercy, and see whether it sinks or swims. And once it swims, well, that's when we'll finally feel comfortable releasing it into the wild.

 

I haven't used Odin yet but I'm trying to move from AdvancedInspector because it's caused me a bunch of problems. On complicated gameObjects with a bunch of scripts it would take 2 seconds for a letter to appear after you type it when you change a string, like it's re-calculating something about every single AI-enabled script on the gameObject every character. It replaced Unity's camera editor with one that is, as far as I can tell, identical except that it still pops up the little free version warning when you select Deferred and then uses Forward instead. I spent three days trying to figure out why my draw calls were so high before I figured out that the camera set to Deferred wasn't actually rendering Deferred. Can't recommend it.

Plus, there's a good bit of boilerplate. It doesn't affect your editors unless you #include AdvancedInspector, add [AdvancedInspector] over your class and [Inspect] over anything you want to inspect, which means it's hard to add to an existing project and hard to strip out of one when it starts causing chaos.

 

This looks incredible. Are you still accepting beta testers?

My colleague and I both spend ~10 hours a day within Unity on a multitude of different project, and have been looking to upgrade our inspectors. We'd both love the opportunity to test this out!

EDIT : We are both professionals and experienced programmers, who should be able to give it a bit of a kicking

 

Thanks we're also very excited about Odin.

We're looking for larger teams (8+ people) to test Odin at the moment, as we're very curious to see how well Odin holds up, and how well it integrates with user's existing workflows. Or, as Tor put it:

Do you have a finished or large project that you could use to test Odin?

 

The beta is well on its way, but that isn't holding us back from adding new awesome features!
So here's a quick sneak-peak at the InLine Editor Attribute in Odin:

 

We have several large projects that we regularly have to go back to and update - we are also normally swimming in about 5/6 different active projects at the same time, all of which have had signifcant development done on them

If you're looking to see how it could integrate into existing workflows / projects, I think we could have something to offer .

Side note : We work as part of a larger team across multiple sites - although my colleague, myself and another would primarily be doing the programming, we have other Unity developers who would be able to take advantage of Odin!

 

It sounds like you're exactly the type of tester we're looking for - Could you send a message to joris@devdog.io from a company email please?

 

Thank you for such exhaustive answer, sounds like something I always wished for in Unity. Also thanks @brisingre for his insight on AdvancedInspector. We are going to buy Odin Inspector immediately on day one. And I feel like it's going to be our #1 on MUST HAVE package list. How many people approx are working on Odin if I may ask? Also you mentioned some garbage on run-time. How much in comparison with Unity default serializer? This garbage is being generated only when scene is being loaded? Thanks in advance. This is some incredible work you are doing here guys. Top notch!

 

Sirenix is a team of three developers, who have been working full-time on Odin for quite a while now.

As for how much garbage we generate, it depends. Serializing using our optimized binary format - the format that runs in builds by default - generates very little garbage. In fact, when serializing and deserializing binary data, generally the only garbage that is allocated are the metadata strings. IE, if you have a field named "someField", a string "someField" will be allocated during serialization/deserialization so we can know what the field is called. This is rather difficult to avoid.

The only exceptions to this rule are enums, which are currently boxed to the Enum type upon serialization/deserialization, and thus generate a tiny amount of garbage. It is theoretically possible to get around this using either unsafe or runtime-emitted code, we just haven't done it yet.

As for when garbage is generated, generally during scene load, yes. To be more precise, in builds our serialization runs whenever an Odin-serialized object is instantiated from a prefab, or loaded. Instantiate serializes the prefab and then deserializes the data into the new instantiated object, while load merely deserializes the object from pre-existing scene or asset data.

 

Thank you again for the reply. Sounds perfectly reasonable. Now I will just keep looking forward to the release date.

 

New little feature: The AssetList attribute now also has functionality for non-array types. And, of course, it works with all the filters (Except for AutoPopulate):


P.s. Thanks to all the amazing beta testers, we're getting very close to release now!

 

Just wanted to chime in and say I'm super excited for this! There's been multiple times during development recently that I wished for even 10% of these features

 

What if I told you that you can win Odin for free in our Odin-will-soon-release-celebration-giveaway?
Join the giveaway here: http://vyper.io/c/1059

 

To be honest, I believe you haven't updated AdvancedInspector in quite a long time. The [AdvancedInspector] attribute was "retired" over two years ago.

Odin looks nice, by the way.

 

I've updated it, but I might not have updated it properly, i.e. deleting old versions manually and doing a clean install.

I'll try that, and update my post if it works. That's only fair.

That said, even if this fixes it, I'm going to try to switch to Odin, I think. My overall experience of Advanced Inspector is that, every time I've used it, it's saved me a lot of work for a while by letting me do things like inspect List<t> and whatever, and then eventually ended up creating a lot of work tracking down an issue that ends up being AI-related. It's certainly not the first asset to ever make me track down an issue, but I really don't want that from an inspector replacement. I really want it to "just work." Perhaps that's too much to ask, and I'll have similar issues with Odin. Time will tell.

 

Here is how the newly added support for dictionaries looks. We also handle self-referencing infinite draw loops which the gif also showcase

 

Any idea on a day when the asset will be released? I'm looking forward to this asset!