Trying out Odin Inspector

Hello! I'm PanKUN.

This time, I will summarize the troubles that occurred when introducing Odin Inspector in an indie project and the actions taken at that time.

Roughly speaking, the situation was:

• Differences appear in .meta files related to Odin
• Unity only starts in Safe Mode in some environments
• Errors related to Test Framework also appear

It did not reproduce in my environment, and since "people for whom it works" and "people for whom it doesn't" were mixed, it was necessary to isolate the cause and establish response rules within the team.

In this article, I will write from the perspective of "doing this makes it less likely to cause accidents during the initial introduction" based on the steps actually taken.

Organizing Error Details

First, I will organize the symptoms that were actually occurring within the team.

1. Differences and warnings in meta files

In the environment of some members, differences occurred in .meta files related to Odin, and warnings like:

Invalid meta file exists

or errors where Odin-related assemblies were not recognized correctly appeared.

2. Starting in Safe Mode

• It starts normally in my environment
• Unity can only be opened in Safe Mode for other members

This became the state.

Even though there was no problem when I:

• Imported Odin
• Performed Clean -> Checkout in another local project to verify

I received reports that only some members were sent to Safe Mode.

3. Test Framework Errors

When I looked at the logs in Safe Mode, there were patterns where:

• Errors related to Test Framework

were appearing separately from Odin.

Unity's Test Framework is:

• Unity Editor top menu: Window > General > Test Runner (name varies slightly depending on version)
• A package for writing unit tests using attributes like [Test] in code

As far as reading the logs, it seemed that:

• Somewhere related to Odin depends on the Test Framework
• However, the Test Framework is broken / unreadable in some members' environments

However, since:

• The version of Test Framework on Packages/manifest.json is consistent
• It works without problems with the same version in my other projects

I judged that the package itself is not broken.

Possible Causes

Here are some likely causes while looking at the logs.

1. Version differences in Unity / Odin / Test Framework
   • Only specific members have different Unity minor versions
   • The version when Odin was imported is slightly different
2. State differences in .meta files or Library
   • The Library folder remains old
   • Some .meta files are generated only locally and not uploaded to Git
3. Difference in installation state of Test Framework
   • Once deleted or disabled on Package Manager
   • Cache is broken and re-import is not completed

Actually, rather than "one of these", it felt like multiple conditions overlapped and caused it to be sent to Safe Mode.

Actual Response Procedures

From here, I will organize and write down the procedures that the team actually followed.

Step 1: Unify everyone's work procedures

First, we fixed "what to do after Pulling".

1. Do git pull
2. With Unity closed
   • Delete the Library folder
   • Delete Temp and obj if necessary (optional)
3. Restart Unity and wait for the initial re-import to finish

Since there were several members who were not doing this, I documented the procedure and shared it via Discord / DM, unifying it as "Start from here".

Since this alone fixed it for some people, I recommend distributing a "procedure manual set" when introducing Odin.

Step 2: Check status of Odin and Test Framework

Next, for members who still had problems, I asked them to check the package status.

• Open Window > Package Manager
• Check the version of Odin
  • Is it consistent with the imported version?
• Check Test Framework on Unity Registry side
  • Is it installed?
  • Is the version the same as other members?
  • Is the status not Error / waiting for Resolve?

If the Test Framework seems broken:

1. Temporarily "Remove" the Test Framework package
2. Restart Unity
3. Re-install Test Framework from Package Manager again

I asked them to re-import in this way.

Step 3: Organizing .meta differences

If there are differences in .meta files related to Odin:

• First, commit the correct state of Odin + meta to the repository side
• Then, for other members:

  1. Evacuate local changes in work branch (stash or commit)
  2. Sync to latest branch
  3. Delete Library
  4. After restarting Unity, check if .meta differences related to Odin appear

I asked them to move in this flow.

The idea is to set the "working environment" as correct and fix it in the repository, then align other environments to it.

Operation Rules when introducing Odin in a team

Based on this trouble, I will summarize the points I decided to be careful about in the next project onwards.

1. Decide a "person in charge" before introduction

• Selection of Odin version
• Import to project
• Initial commit

It is less likely to cause accidents if one person in charge does this all at once.

If multiple people import individually in a halfway state, .meta and manifest.json tend to become messy.

2. Document "assumed versions" of Unity / Odin / Test Framework

• At the start of the project
  • Unity version
  • Odin version
  • Test Framework version write these down in some document. It becomes sufficient just to guide members joining later to "please match this".

3. Write initial setup procedures in README

Like what we did this time:

• Things to do after git clone / git pull
  • Delete Library
  • Restart Unity
• Confirmation points when it didn't start well
  • Status check of Odin / Test Framework
  • Ask to report with logs attached when it becomes Safe Mode

Just by making a simple procedure manual for such contents, the communication cost during trouble drops considerably.

Summary

Summarizing what I learned from this Odin introduction, it looks like this.

• Odin itself is convenient, but it is easy to have accidents due to differences in "Unity / Test Framework / meta files" during team introduction
• It is easy to adopt a policy of deciding one "working environment", committing the state of Odin + Test Framework from there, and aligning other members' environments to that state
• Just documenting the procedure and assumed version lightly in advance makes it much safer

Since Odin is a quite powerful tool around custom inspectors and editor extensions, once you can create a form that can be introduced stably in a team, projects from the next one onwards will be much easier.

I hope to write about what features I am actually making with Odin (attribute-based Editor extensions, ingenuity of Data management, etc.) in another article in the future.