- Home /
Monobehaviour resets variables after the initialization cycle
I have a really weird problem. I've written a code that looks like this:
UtilitiesList utilities; // Not derived from MonoBehaviour
bool DEBUG_UtilitiesExists = false;
void Start () {
utilities = new UtilitiesList ();
DEBUG_UtilitiesExists = utilities != null;
Debug.Log ("DEBUG_Utilities exists: " + DEBUG_UtilitiesExists);
//... Here I create utilities and add them to the UtilitiesList
}
void FixedUpdate () {
if(utilities == null)
Debug.Log ("DEBUG_Utilities exists: " + DEBUG_UtilitiesExists.ToString ());
utilities.Update ();
//... Further processing
}
It works properly in 99 % of cases. But sometimes when I start the game it throws a NullRefernceException in the following string from FixedUpdate():
utilities.Update ();
The most astonishing is that no exception is thrown from the Start() function! So initialization seems to be performed properly. And this is the only place where I assign a value to the "utilities" variable (and this variable is private). That makes me think that it doesn't depend on the script execution order; anyway, dependencies from the other monobehaviour components are not tight.
I added some variables for debugging as you can see above. And when it occures that the "utilities" variable becomes a null reference in FixedUpdate, "DEBUG_UtilitiesExists" variable is always true. That means that the initialization in Start is always performed successfully, but somehow it resets the reference somewhere between Start() and FixedUpdate().
The same situation occures with the other class which works with the XML files. The variable that is reset on its own, is a public property with a private set method.
I have absolutely no idea, what's happening)) Only that this is a Unity bug. If it is so, will it occur in the built game?
As a sanity check, can you confirm that same occurs with a super-basic class, maybe even one without functions, rather than UtilitiesList?
Super-basic class? What is it? I just have the other $$anonymous$$onoBehaviour-derived scripts which use the simple classes, and they never throw such exceptions.
public class superBasic{ public int anInt; }
By the way, I found out how to establish conditions to ivoke this problem, it will occure (for my project, of course) immediately rather than with a 1% probability as I denoted above. What I do: 1) Open "Script Edition Order" in inspector (Edit -> Project Settings -> Script Edition Order). 2) Place absolutely arbitrary class to the list of ordered scripts. 3) And start the game WITHOUT pressing the "Apply Button". The messagebox, requiring to apply the settings will be shown, and I apply the settings in this messageBox. Whenever I do this I always get this resetting variables problems. And I forgot to mention in the first place (I just thought this is obvious) that if I do nothing and just restart the game i editor there will be no problem again until a few days. Or (as I've just found out) until I change scripts execution order in any way. So I became more reassured that this is a Unity bug.
Ok, so you are doing SO$$anonymous$$ETHING (hitting apply in the message box) between hitting start and the game actually running; Odd, but makes SO$$anonymous$$E sense. But if you don't do that, is there still a 1% chance it will happen?
Yes, this problem is really-really rare if not to touch those exec order settings. Anyway, I'll report it as a bug and send them some of my project files. But if this is a problem occuring only in editor and it won't pass to the final built, I wouldn't warry about it, but I need to know for sure.
Report it as a bug.
It's nice that it has a workaround though. Press apply before running your game :)
))) I can't. Because it occures from time to time without me changing these settings)