Encountered invalid entry while reading serialization data

[Mark A]

We just upgraded to Odin 2.0.17 (this version isn't selectable below so I've marked it as 2.0.16, but it's .17). I think this error started occurring on update, although I cannot be 100% sure . The component is question hasn't changed since mid March although I'm still trying to track down if a base class did change, although it looks like it did not. This error occurs on startup of the editor and it doesn't seem like it is affecting play in editor mode or our standalone builds.

We do not have editor only mode enabled. Unity 2018.4.6f This is on Windows 10.

Data dump:

Reader type: SerializationNodeDataReader
Data dump: Nodes:

- Name: 
  Entry: 0
  Data: 
- Name:     <<<< READ POSITION
  Entry: 0
  Data: 
- Name: 
  Entry: 6
  Data: 
- Name: frozenDamageReactions
  Entry: 6
  Data:

UnityEngine.Debug:LogError(Object) Sirenix.Serialization.CustomLogger:LogError(String) (at C:/Projects/sirenix-development-framework/Sirenix Solution/Sirenix.Serialization.Config/CustomLogger.cs:59) Sirenix.Serialization.DebugContext:LogError(String) (at C:/Projects/sirenix-development-framework/OdinSerializer/OdinSerializer/Core/Misc/SerializationConfig.cs:208) Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, IDataReader) (at C:/Projects/sirenix-development-framework/OdinSerializer/OdinSerializer/Unity Integration/UnitySerializationUtility.cs:1610) Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext, Boolean, List`1) (at C:/Projects/sirenix-development-framework/OdinSerializer/OdinSerializer/Unity Integration/UnitySerializationUtility.cs:1427) Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext) (at C:/Projects/sirenix-development-framework/OdinSerializer/OdinSerializer/Unity Integration/UnitySerializationUtility.cs:1147) Sirenix.OdinInspector.SerializedMonoBehaviour:UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize() (at C:/Projects/sirenix-development-framework/OdinSerializer/OdinSerializer/Unity Integration/SerializedUnityObjects/SerializedMonoBehaviour.cs:37)

[Tor Esa Vestergaard]

Hmm. This seems to happen sometimes - Unity just corrupting and wiping the data we have stored. This is the first time I've seen anything usable be left in the node list, though, after this happens. I'm not sure what we can do to prevent it, really - though in this case, it seems like we should perhaps try skipping all invalid entries so we can at least arrive at that valid bit of data and deserialize that. I'll need to think about it a bit. If you figure out a way to reproduce this issue reliably, that would be lovely - we've never figured out a set of reproduction steps that actually makes this happen consistently or even sporadically.

[Mark A]

While it's not 100% repo on our project, it's not totally rare either. Unfortunately our project is large and I'm not sure that I can boil down a potential test case easily. I will do some investigation and report back what I find. When this does happen, what are the potential issues? lost data?

[Tor Esa Vestergaard]

I'm not actually certain whether there's any lost data - people have only ever reported the error, not any negative consequences they've encountered from it. It could be that Unity isn't wiping data, but just filling in garbage instead. It could go both ways.

[Tor Esa Vestergaard]

Issue #529 was marked as a duplicate of this issue.

[Tor Esa Vestergaard]

Issue #529 was marked as a duplicate of this issue.

[Tor Esa Vestergaard]

Issue #529 is essentially the same as this, and I've redirected the discussion from there to here, to keep things manageable. No reproduction steps have as yet been determined. Vinnie, have you identified which asset is causing the exception? It is very likely that causing the asset to re-serialize (IE, modifying it and then causing it to be saved to disk) will fix the issue. If that's not the case, then we have an actual reproduction case, since this corruption reoccurs consistently.

[Vinnie Vivace]

cool, thanks. No, I cannot provide any more information at this stage other than the fact this issue did not occur until we upgraded to 2019.1

[Vinnie Vivace]

now its a show stopper. As per comments on other issue, doing a Build will produce the errors but still result in a successful build. doing a build and run will fail, every time.

[Tor Esa Vestergaard]

Vinnie, I have a build that I'd like to send you that contains a few modifications in the error handling and the logging message. I'd like you to try your Build and Run during this, and see, first, if it works, and second, if the improved log messages help you handle the issue better. Can you give me your email or contact me on Discord through our Discord support channel so I can send the build to you?

[Tor Esa Vestergaard]

Mark, I can also send this build to you, if you would like to give it a go and see if this is more helpful. It logs a lot more data and helps you track down the precise asset in which the error took place.

[Mark A]

Yes, I'd be happy to take a build from you to try this out. Currently the rest of my team is still using an older version of Odin because we ran into other problems with previous integrations that were causing player crashes. I wasn't at a spot to look at them more closely at the time so this time am taking a more cautious approach (we heavily use nested prefabs and I suspect that was part of the problem. 2.0.17 seems far better so far). Let me know how to grab and I can take a look and get you more data. We still do see this issue regularly but not terribly often

[Tor Esa Vestergaard]

You can send me a mail at [e-mail] or hit me up on Discord and I'll send you the build.

[Mark A]

As an update, I moved to 2.0.19 today and got this message again. The bad thing is that something happened during the Odin upgrade and the library had to be reimported which for us is about a 4 hour process. Reimport crashed and then I got this message after that. I did look around the log for a potential offending asset that was leading to this problem, but with all of the other things that were happening, my logs were large (and by the way, the reimport time and and crashes on reimport are things that we routinely see so I’m not saying they were a result of upgrading Odin).

I guess the good news is that I was able to make it happen again. I hope though that I can narrow down where I am seeing this.

[Mark A]

I was able to get this problem again when just opening up the project this morning after the weekend. I actually have 10 instances of this opening up the project. The 10 instances are all on the same Component and of the 10, 1/2 show the READ POSITION at one point and 1/2 show it at another point. I will paste both of the relevant portions of the log below. I did search for DELAYED SERIALIZATION LOG, but only found the instances of that text in the warning text that says to search for it. I suspect though, that this might be because of an error in the subsequent log message. There seems to be a NULL name/member. The paste of the log information here has two errors in a row (one each with the two different read positions,) and then the NULL error from Odin that immediately follows. The lines before and after are just asset database updates for other assets. I assume that these are irrelevant based on the message from Odin, but let me know what else you need.

‌

Encountered invalid entry while reading serialization data for Unity object of type 'HealthComponent'. This likely means that Unity has filled Odin's stored serialization data with garbage, which can randomly happen after upgrading the Unity version of the project, or when otherwise doing things that have a lot of fragile interactions with the asset database. Locating the asset which causes this error log and causing it to reserialize (IE, modifying it and then causing it to be saved to disk) is likely to 'fix' the issue and make this message go away. Even so, DATA MAY HAVE BEEN LOST, and you should verify with your version control system (you're using one, right?!) that everything is alright, and if not, use it to rollback the asset to recover your data.

A delayed warning message containing the originating object's name, type and scene/asset path (if applicable) will be scheduled for logging on Unity's main thread. Search for "DELAYED SERIALIZATION LOG". This logging callback will also mark the object dirty if it is an asset, hopefully making the issue 'fix' itself. HOWEVER, THERE MAY STILL BE DATA LOSS.

IF YOU HAVE CONSISTENT REPRODUCTION STEPS THAT MAKE THIS ISSUE REOCCUR, please report it at this issue at 'https://bitbucket.org/sirenix/odin-inspector/issues/526', and copy paste this debug message into your comment, along with any potential actions or recent changes in the project that might have happened to cause this message to occur. If the data dump in this message is cut off, please find the editor's log file (see https://docs.unity3d.com/Manual/LogFiles.html)) and copy paste the full version of this message from there.

Data dump:

Reader type: SerializationNodeDataReader
Data dump: Nodes: 

- Name:     <<<< READ POSITION
  Entry: 0
  Data: 
- Name: 
  Entry: 0
  Data: 
- Name: 
  Entry: 6
  Data: 
- Name: frozenDamageReactions
  Entry: 6
  Data: 

UnityEngine.DebugLogHandler:Internal_Log()
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
UnityEngine.Logger:Log(LogType, Object)
UnityEngine.Debug:LogError(Object)
Sirenix.Serialization.CustomLogger:LogError(String) (at C:\Projects\sirenix-development-framework\Sirenix Solution\Sirenix.Serialization.Config\CustomLogger.cs:59)
Sirenix.Serialization.DebugContext:LogError(String) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Core\Serializers\Serializer.cs:84)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, IDataReader) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Utilities\Misc\DoubleLookupDictionary.cs:152)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext, Boolean, List`1) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Utilities\Misc\DoubleLookupDictionary.cs:101)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Utilities\Misc\DoubleLookupDictionary.cs:83)
Sirenix.OdinInspector.SerializedMonoBehaviour:UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize() (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Unity Integration\SerializedUnityObjects\SerializedMonoBehaviour.cs:37)

(Filename: C:/Projects/sirenix-development-framework/Sirenix Solution/Sirenix.Serialization.Config/CustomLogger.cs Line: 59)

Encountered invalid entry while reading serialization data for Unity object of type 'HealthComponent'. This likely means that Unity has filled Odin's stored serialization data with garbage, which can randomly happen after upgrading the Unity version of the project, or when otherwise doing things that have a lot of fragile interactions with the asset database. Locating the asset which causes this error log and causing it to reserialize (IE, modifying it and then causing it to be saved to disk) is likely to 'fix' the issue and make this message go away. Even so, DATA MAY HAVE BEEN LOST, and you should verify with your version control system (you're using one, right?!) that everything is alright, and if not, use it to rollback the asset to recover your data.

A delayed warning message containing the originating object's name, type and scene/asset path (if applicable) will be scheduled for logging on Unity's main thread. Search for "DELAYED SERIALIZATION LOG". This logging callback will also mark the object dirty if it is an asset, hopefully making the issue 'fix' itself. HOWEVER, THERE MAY STILL BE DATA LOSS.

IF YOU HAVE CONSISTENT REPRODUCTION STEPS THAT MAKE THIS ISSUE REOCCUR, please report it at this issue at 'https://bitbucket.org/sirenix/odin-inspector/issues/526', and copy paste this debug message into your comment, along with any potential actions or recent changes in the project that might have happened to cause this message to occur. If the data dump in this message is cut off, please find the editor's log file (see https://docs.unity3d.com/Manual/LogFiles.html)) and copy paste the full version of this message from there.

Data dump:

Reader type: SerializationNodeDataReader
Data dump: Nodes: 

- Name: 
  Entry: 0
  Data: 
- Name:     <<<< READ POSITION
  Entry: 0
  Data: 
- Name: 
  Entry: 6
  Data: 
- Name: frozenDamageReactions
  Entry: 6
  Data: 

UnityEngine.DebugLogHandler:Internal_Log()
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
UnityEngine.Logger:Log(LogType, Object)
UnityEngine.Debug:LogError(Object)
Sirenix.Serialization.CustomLogger:LogError(String) (at C:\Projects\sirenix-development-framework\Sirenix Solution\Sirenix.Serialization.Config\CustomLogger.cs:59)
Sirenix.Serialization.DebugContext:LogError(String) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Core\Serializers\Serializer.cs:84)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, IDataReader) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Utilities\Misc\DoubleLookupDictionary.cs:152)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext, Boolean, List`1) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Utilities\Misc\DoubleLookupDictionary.cs:101)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Utilities\Misc\DoubleLookupDictionary.cs:83)
Sirenix.OdinInspector.SerializedMonoBehaviour:UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize() (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Unity Integration\SerializedUnityObjects\SerializedMonoBehaviour.cs:37)

(Filename: C:/Projects/sirenix-development-framework/Sirenix Solution/Sirenix.Serialization.Config/CustomLogger.cs Line: 59)

Entry of type "Null" in node "" is missing a name.
UnityEngine.DebugLogHandler:Internal_Log()
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
UnityEngine.Logger:Log(LogType, Object)
UnityEngine.Debug:LogError(Object)
Sirenix.Serialization.CustomLogger:LogError(String) (at C:\Projects\sirenix-development-framework\Sirenix Solution\Sirenix.Serialization.Config\CustomLogger.cs:59)
Sirenix.Serialization.DebugContext:LogError(String) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Core\Serializers\Serializer.cs:84)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, IDataReader) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Utilities\Misc\DoubleLookupDictionary.cs:152)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext, Boolean, List`1) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Utilities\Misc\DoubleLookupDictionary.cs:101)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext) (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Utilities\Misc\DoubleLookupDictionary.cs:83)
Sirenix.OdinInspector.SerializedMonoBehaviour:UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize() (at C:\Projects\sirenix-development-framework\OdinSerializer\OdinSerializer\Unity Integration\SerializedUnityObjects\SerializedMonoBehaviour.cs:37)

(Filename: C:/Projects/sirenix-development-framework/Sirenix Solution/Sirenix.Serialization.Config/CustomLogger.cs Line: 59)

[Fred]

I started getting these errors when opening a scene or when modifying and save the faulty prefab:

Encountered invalid entry while reading serialization data for Unity object of type 'Tangier.Workers.WorkerInteractionPoint'. This likely means that Unity has filled Odin's stored serialization data with garbage, which can randomly happen after upgrading the Unity version of the project, or when otherwise doing things that have a lot of fragile interactions with the asset database. Locating the asset which causes this error log and causing it to reserialize (IE, modifying it and then causing it to be saved to disk) is likely to 'fix' the issue and make this message go away. Experience shows that this issue is particularly likely to occur on prefab instances, and if this is the case, the parent prefab is also under suspicion, and should be re-saved and re-imported. Note that DATA MAY HAVE BEEN LOST, and you should verify with your version control system (you're using one, right?!) that everything is alright, and if not, use it to rollback the asset to recover your data.

A delayed error message containing the originating object's name, type and scene/asset path (if applicable) will be scheduled for logging on Unity's main thread. Search for "DELAYED SERIALIZATION LOG". This logging callback will also mark the object dirty if it is an asset, hopefully making the issue 'fix' itself. HOWEVER, THERE MAY STILL BE DATA LOSS.

IF YOU HAVE CONSISTENT REPRODUCTION STEPS THAT MAKE THIS ISSUE REOCCUR, please report it at this issue at 'https://bitbucket.org/sirenix/odin-inspector/issues/526', and copy paste this debug message into your comment, along with any potential actions or recent changes in the project that might have happened to cause this message to occur. If the data dump in this message is cut off, please find the editor's log file (see https://docs.unity3d.com/Manual/LogFiles.html)) and copy paste the full version of this message from there.

Data dump:

Reader type: SerializationNodeDataReader
Data dump: Nodes: 

- Name: blueprints
  Entry: 7
  Data: 0|System.Collections.Generic.List`1[[Tangier.Workers.BlueprintInfo, Assembly-CSharp]], mscorlib
- Name: 
  Entry: 12
  Data: 0
- Name: 
  Entry: 13
  Data: 
- Name: 
  Entry: 8
  Data: 
- Name: 
  Entry: 0
  Data: 
- Name: 
  Entry: 0
  Data: 
- Name: 
  Entry: 0
  Data: 
- Name: 
  Entry: 0
  Data: 
- Name: 
  Entry: 0
  Data: 
- Name: 
  Entry: 0
  Data: 
- Name: 
  Entry: 0
  Data: 
- Name: 
  Entry: 0
  Data: 
- Name:     <<<< READ POSITION
  Entry: 0
  Data: 

UnityEngine.DebugLogHandler:Internal_Log(LogType, LogOption, String, Object)
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
UnityEngine.Logger:Log(LogType, Object)
UnityEngine.Debug:LogError(Object)
Sirenix.Serialization.CustomLogger:LogError(String) (at X:\Repositories\sirenix-development-framework\Sirenix Solution\Sirenix.Serialization.Config\CustomLogger.cs:59)
Sirenix.Serialization.DebugContext:LogError(String) (at X:\Repositories\sirenix-development-framework\OdinSerializer\OdinSerializer\Core\Misc\SerializationConfig.cs:223)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, IDataReader) (at X:\Repositories\sirenix-development-framework\OdinSerializer\OdinSerializer\Unity Integration\UnitySerializationUtility.cs:1677)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext, Boolean, List`1) (at X:\Repositories\sirenix-development-framework\OdinSerializer\OdinSerializer\Unity Integration\UnitySerializationUtility.cs:1427)
Sirenix.Serialization.UnitySerializationUtility:DeserializeUnityObject(Object, SerializationData&, DeserializationContext) (at X:\Repositories\sirenix-development-framework\OdinSerializer\OdinSerializer\Unity Integration\UnitySerializationUtility.cs:1147)
Tangier.Core.OrderedSerializedMonoBehaviour:UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize() (at Assets\Scripts\Core\OrderedMonoBehaviour.cs:70)
UnityEditor.PrefabUtility:SaveAsPrefabAsset_Internal(GameObject, String, Boolean&)
UnityEditor.PrefabUtility:SaveAsPrefabAsset(GameObject, String, Boolean&) (at C:\buildslave\unity\build\Editor\Mono\Prefabs\PrefabUtility.cs:1271)
UnityEditor.Experimental.SceneManagement.PrefabStage:SavePrefab() (at C:\buildslave\unity\build\Editor\Mono\SceneManagement\StageManager\PrefabStage\PrefabStage.cs:393)
UnityEditor.Experimental.SceneManagement.PrefabStage:SavePrefabWithVersionControlDialogAndRenameDialog() (at C:\buildslave\unity\build\Editor\Mono\SceneManagement\StageManager\PrefabStage\PrefabStage.cs:534)
UnityEditor.Experimental.SceneManagement.PrefabStage:PerformDelayedAutoSave() (at C:\buildslave\unity\build\Editor\Mono\SceneManagement\StageManager\PrefabStage\PrefabStage.cs:492)
UnityEditor.EditorApplication:Internal_CallUpdateFunctions() (at C:\buildslave\unity\build\Editor\Mono\EditorApplication.cs:303)

‌

I can repro this 100%.

[Killian Grey]

Any update on this? I’m on latest Unity 2019.2.14f1 and Odin Inspector 2.1.6.

The issue manifests itself in broken (null) references to a SerializedMonoBehaviour inside prefabs, that happen to also contain other, nested prefabs.

• This happens when opening the project for the first time in Unity Editor (or after Library folder was deleted).
• These references fix themselves if we close the Editor without saving anything and just re-opening the project.
• We have SerializedScriptableObject class with a Dictionary field. Values of this dictionary are normal C# classes with a reference field of SerializedMonoBehavior type mentioned above. This field has [OdinSerialize] attribute.
• The issue is always reproduced on the same parts inside the same assets.
• The issue does not happen if we replace the reference with different prefab.
• The issue does not happen if we delete the nested prefab inside the referenced prefab or if “Unpack prefab completely” is used.
• Duplicating this asset does not make the copy break. It seems that only asset that are actually used (referenced) from other places are affected (additional requirements for reproduction).

I couldn’t yet deduce a 100% repro steps for this issue. Nor a reliable way to fix or avoid it, short of re-opening Unity after the first project load. This might not help though if, for example, new changes are pulled from git, imported and somehow trigger the same situation.

‌

[Tor Esa Vestergaard]

What you describe is a challenging situation for us to attempt to fix, since this is more Unity’s asset system doing crazy things, dropping references and destroying data, as far as we’ve been able to tell ourselves. We have no control over the internals of Unity’s asset system - all we can do is put our data into some arrays, and hope that Unity preserves it correctly. We are entirely at their mercy :)

I should note that we’ve officially deprecated support for Odin-serialized prefabs, so if this is happening on a SerializedMonoBehaviour which is also a prefab (sounds like it), you’re a bit out of luck - that is no longer expected to work in Odin since Unity 2018.3, and we have given up on trying to fix issues with it because we would spend all our time doing nothing else, and we likely would still not succeed. Hopefully you have seen the very strongly phrased warning message we put on top of all Odin-serialized prefabs.

That being said, if you do manage to find a clear and repeatable set of reproduction steps, I would love to have a look at it and see if there is some way we can fix it or at least figure out what is going on so we can provide better error messages - especially since this issue doesn’t always happen on just prefabs.

Edit: I should also say, when I write reproduction steps, I mean a series of steps that can reliably take an asset from a working state to a “broken” state in this way, where the data just randomly vanishes or is deleted.

[Killian Grey]

Thanks for the reply. I’ve changed the base class of the class being referenced from SerializedMonoBehavior to normal MonoBehavior (it didn’t use any Odin features, didn’t really needed to be SMB). This didn’t help, reference was still broken. The prefab game object has another SerializedMonoBehavior. The object containing the reference is a SerializedScriptableObject though. I have a vague idea when this happens and will try to make a repro project if time allows. Basic idea is like this:

• Unity figures out the chain of references between assets and schedules some kind of queue for asset import
• It loads the main chain including my config asset into memory, resolving the reference correctly to a loaded MonoBehavior C# object in-memory
• For some unknown reason, Unity triggers the change to a nested prefab asset, which in turn triggers re-import of the prefab containing it
• When prefab is re-imported, new C# objects are created, but the reference in my config still points to an old C# object (which is now a “fake null”) and is not updated

‌

[Killian Grey]

I did it! Minimum repro project is sent to you via email.

Just open it, check the null ref in the dictionary in MyConfigAsset. Then re-open the project, and the null ref will fix itself.

Apparently the issue is that Unity somehow doesn’t recognize those references handled by Odin and don’t fix them when new versions of MonoBehaviors are loaded in memory after prefab re-import. I tried adding simple reference field like this:

‌

[OdinSerialize][NonSerialized]
public MyMonoBeh PeskyReference2;

And it still gets corrupted, so it’s not related to the usage of Dictionary, but to any reference field managed by Odin.

PS: I think this issue is not so “minor”. You can’t realistically expect users NOT to use nested prefabs at all since it’s THE way to use prefabs in Unity now. And since it’s not about what’s inside those prefabs, but that you can’t safely reference them at all. Which makes custom serialization solutions like Odin an unsafe choice over default serialization features of Unity. We are stuck with Odin in our project though, so any kind of workaround safety solution would be greatly appreciated.

[Killian Grey]

Any plans on looking into adding full support for SerializedMonoBehavior in Nested Prefabs and Prefab Variants? This is a deal breaker for our project, we heavily rely on prefab workflows introduced in 2018 but also used Odin Serializer features heavily without prior knowledge that this will be such a hard to fix issue as to be officially abandoned. This far into project development, its so hard to rewrite components written as SerializedMonoBehavior back to normal MonoBehavior. Not using Nested Prefab features is out of question for us, it’s too deeply rooted in our workflows.

Have you tried getting in touch with Unity to try and work together with them to resolve this? Maybe creating a thread on Unity forums? They seem to be more focused on QoL improvements and bug fixes now than a year ago, so you might have a shot.

Fixing this would be an important milestone to be able to finally use those must-have features together.

[Tor Esa Vestergaard]

Patch 3.1 of Odin is slated to be all about QoL and upgrading/revamping of old features that could use it. I’ve also heard that Unity have been making strides in the stability of the prefab system, so I think I can say that I will dedicate a full week or two of Odin 3.1’s development process to attempting to once more solve this problem. Believe me, we would like this to work as much as you would!