- Home /
All inspector fields reverting to default values when built to executable
Howdy,
I've been smacking my head against this issue for two days now, and could really use some help. I have a project that's recently been exhibiting some dismaying behavior: every public field that is assigned to in the inspector (both reference and value types), in all scripts and all scenes, is being set to its default value when the project is built. It can be played from the editor just fine, but building a separate executable results in piles of null references and wrong values in the resulting executable. The problem occurs both for scripts attached to gameobjects in scene, and also some other associations (e.g., the materials being stripped off of models so that they look untextured when instantiated at runtime).
I’ve tried the following: re-assigning the values by hand in the inspector, renaming variables within scripts and re-assigning the values in the inspector, deleting the metadata files for the scripts to force Unity to remake them, deleting the metadata files for whole scenes to force Unity to re-make them, explicitly marking classes with [System.Serializable], deleting the Library folder to force a rebuild of its contents, deleting the Visual Studio solution files to force their rebuild, and duplicating whole scenes and using the copies. The only fix that seems to work is re-establishing the links via code at runtime; not an ideal solution to implement for every public variable in the whole project.
I know that data corruption isn’t too rare in larger Unity projects, but this is a scale and impenetrability beyond any that I’ve seen before. None of the usual fixes appear to be working, so I’m somewhat stumped. As it may be relevant, we're using Perforce as our version control (using P4V as our client, not any Unity perforce plugin) and Visual Studio as our IDE.
Does anyone have any wisdom that they can impart? I have a deadline looming, and this hurts.
Cheers, jonathan
Answer by BigBuckleDeveloper · Jul 26, 2015 at 07:12 PM
So it's embarrassing, but in case any else has a similar issue, I'll admit that the bug was our fault, and was due to singleton stomping.
We had a custom generic singleton class that we used for a bunch of our manager scripts. The bug was exposed when a script started referencing the singleton before the scene in which we had our configured instance of the class had been loaded, so it created a new (unconfigured) instance. Then, when our configured instance showed up, it happily destroyed itself like a good redundant singleton should. In addition, since many of our manager singletons were on the same object, it murdered a bunch of the other configured instances as well. The carnage was extreme.
Watch your singleton loading, folks!