Reputation: 31
I'm having trouble with my inspector and I'm not sure what I did. Before this problem, when I would update a variable in my script, it would show the new value in the inspector when I saved the code. For some reason all of a sudden, this stopped happening. I'm not aware of any changes I made to the inspector or code that would have caused this. Is there some sort of setting to adjust this functionality? I've been pretty much working with a default unity installation and doing C# in Visual Studio. I've seen other similar problems on the web but no answers that quite fit the issue I'm having.
Here is an example variable with two different values. Basically, I initialized it in C# code with a value of 2f. Then, later on I updated the same C# code with the value 3f and saved. Normally, the inspector would update to reflect this new value but it no longer does.
Upvotes: 3
Views: 13042
Reputation: 11
I think the key to this problem has to do with where the assignment of your fields takes place.
Usually in c#, the top of a class is where you declare your fields, but not where you assign them. For example, you would expect to see something like int x;
, but not something like int x = 2;
That’s because code in the body of a class is considered compile-time behavior. The first time Unity ever sees your script compiled, it will fill the inspector with whatever default value you provided - in the case of int x;
, it’d fill with 0. In the case of int x = 2;
, it’d fill with 2. But once Unity remembers that value (by serializing it), it will stick with it till the end. It won’t even listen when you update the assignment in the body of your class in code! At this point, the only thing calling the shots is whatever value you end up typing into the inspector. (Or some of the resetting type procedures mentioned above).
Fortunately, if you do want your code to be the one calling the shots, all you have to do is make the assignment of your field during runtime. Runtime behavior can be considered any code inside the method bodies of your class. In the case of Unity, though, that will usually mean the Start() method. By making your assignments at runtime, you will effectively override whatever values ended up getting set in the inspector.
So in a nutshell, there is an order of operations that determines the final say on what your field will be; First comes compile-time assignment, then the serialized inspector value, and finally runtime assignment. If you want the inspector calling the final shots, don't assign any initial values at runtime. If you want your code calling the shots, assign them not in the body of your class, but within one of its runtime methods, (most likely Start())
This design effectively allows Unity users to decide if they want to do the bulk of their work in the inspector, or in code. It might also explain why in the beginning, you felt that Unity would prioritize listening to your code, and then all a sudden, it started listening to the inspector instead. Perhaps one of your scripts assigned fields in Start(), but then a later one assigned them in the class body. It's a subtle but heavily consequential distinction!
Hope this helps, good luck!
Upvotes: 0
Reputation: 180
This happens when you have changed a variable in your inspector most of the time. the smartest thing to do would just be change the variables in your inspector so you don't have to constantly change your script. after you have changed all the variables to your liking then go to your script and set them there to be fixed.
you could reset your script but this sets all the variables to the declared variables in your script. also a good thing to do is to update the variables in your scripts to the ones in your inspector, and make backups of your scripts.
the reason why they don't override the values in the inspector is because its easier to change values in your inspector and more time consuming to keep changing them in your code.
when building your game it DOES keep the values from the inspector for the game.
Upvotes: 0
Reputation: 90590
That is because the fields in the Inspector are serialized and get always overwritten with the serialized values stored in your Scene or Prefab asset.
A later change in code of the default value has therefore no effect.
So I doubt it has done it before.
The only thing that does change it would e.g. be if you rename the field.
As already mentioned by Yash Vakil you can Reset
the entire component and all its field via the component's context menu.
But afaik you can also reset individual fields by directly right click the field and click Reset
from this context menu. Not 100% sure on that one though.
The little bit dirty hack around would be to make one compilation where this value is not serialized anymore.
E.g. by making it
[NonSerialized] public float jorneyTime = 3f;
let it compile once and then change it back by removing the [NonSerialized]
again. This forces Unity to lose the serialization of that field entirely.
Upvotes: 3
Reputation: 71
Reset the Script from the Inspector
It will take all the Default values from the Script
Upvotes: 1