Odin Modules

The Modules system that was added to Odin in 3.0 is a very simple, minimalistic package system that is meant to solve several long-standing challenges that Odin has faced since its original release.

Since its release, Odin has supported a very wide range of Unity versions, and has constantly been kept updated to always support the latest versions of Unity as they have been released. In addition to that, Unity's transition to a package-based system means that any version of Odin must work with and adapt to an increasingly wide variety of possible Unity project setups and versions, with different packages and code bases available.

Until now, working with Unity features that are in some versions but not in others, or that are in, has required a lot of effort, often resulting in the heavy-handed use of hard-coded reflection littered with error-handling and logging. This is necessary since there is no way to write code that directly references features of Unity that might not be present, and no out-of-the-box method to conditionally activate or deactivate "normal" non-reflection code files that uses such features.

The core of Odin still labours under these limitations, but for larger, separate systems and components, we now have the Modules system, which can be found under Tools > Odin Inspector > Preferences > Modules.

What is a module?

A module is a small collection of files that knows about the dependencies it requires to function, and that can intelligently prompt the user to activate it - or that can automatically activate itself, depending on the user's settings - when the dependencies that the module needs are detected to be present. It will also prompt the user to deactivate the module - or again, can automatically do so - if its dependencies should be removed at some point.

As such, modules make it far easier for us to craft custom support for various Unity packages or larger version-dependent features going forward. As a user, your main experience with modules should be minimal, and how much you notice them is up to how you configure the global module settings.

Global Module Settings

There are a few global settings you can adjust to determine how the module system behaves by default.

• Module Toggling: This controls module system's default behaviour for toggling modules. If set to Ask, which is the default setting, then you will get a popup asking what to do if a module could be activated but isn't, or if a module shouldn't be activated, but is. If set to Automatic, then modules will be activated and deactivated automatically without prompting if their dependencies appear or disappear. If set to Manual, the system will neither ask you about toggling modules, nor will it toggle them by itself - you will have to go into each module's settings and manually activate or deactivate it.

• Module Updating: This controls module system's default behaviour for updating modules. If set to Ask, which is the default setting, then you will get a popup asking what to do if a module is activated but out of date. If set to Automatic, then modules will be updated automatically without prompting if an update is available. If set to Manual, the system will neither ask you about updating modules, nor will it update them by itself - you will have to go into each module's settings and manually decide to update it.

Also note that each module can be set to override these global settings on an individual basis by changing its activation settings between global and manual. Finally, modules marked experimental or unstable will never ask to be activated by themselves - they are always opt-in, and you will have to activate them manually in all cases.

And that's it for modules!