Search Issue Tracker
By Design
Votes
0
Found in
2019.4
2020.3
2021.2
2021.2.3f1
2022.1
2022.2
Issue ID
1415941
Regression
No
A serialized by reference field is not overwritten when the class is deserialized using JsonUtility.FromJsonOverwrite
How to reproduce:
1. Open the attached project ("1415941_repro.zip")
2. Run Test -> Test in the menu bar
Expected result: "True" logged in the Console, old and new hash codes are equal
Actual result: "False" logged in the Console, old and new hash codes are not equal
Reproducible with: 2019.4.37f1, 2020.3.32f1, 2021.2.19f1, 2022.1.0b15, 2022.2.0a9
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- NavMeshModifier.OnEnable/OnDisable gets progressively slower when called repeatedly
- "System.Net.CookieContainer" throws an "ArgumentException" error when using a non-UTF-8 machine locale and hostname
- Crash on ModelImporter::ImportSkinnedMesh when disabling "Strip Bones" on a specific FBX model
- WebGL Development builds ignore the "Compression Format" setting when using "Gzip" compression
- [tvOS] Project crashes on startup on Apple TV simulator (both X86_64 and ARM64 architectures)
Resolution Note (2022.2.X):
Because SerializeReference permits entire graphs of objects, it is not possible to reliably match referenced instances with whatever structure was serialized. Therefore rather than risk potentially unexpected and unpredictable results, we do a clean load into fresh instances. Note: in the case of SerializeReference on MonoBehaviours and ScriptableObjects we now have stable identifiers for referenced objects, which does enable smart matching in some scenarios. But this is not available when JSONUtility is used, especially on a custom object that does not derive from a UnityEngine Object. We will take this ticket into consideration when planning future improvements to the SerializationReference and JSONUtility functionality.