Playercontrols object not set to instance

Im not sure why but after adding the Instance = this; part of the tutorial i get a lot of debug errors saying Object reference not set to an instance of an object, all relating to instances of the playerControls variables across several classes. I assume VSC is agnostic to the hierarchy structure for the scripts’ location so that isnt the cause (also because it’s run before with the folder ‘tidy up’ having moved scripts around), but also seems coincidental after adding in the self referencing of the Instance object to ‘this’.


PlayerController class:

As you can see the playerControls is being instantiated but i feel maybe this is a red herring debug error and the problem lies elsewhere …

Any help appreciated

If you click on one of the errors in the console, there will be more details; a stack trace. This tells you where the issue originates. It appears (and I can’t see the console properly so it’s an educated giess) that you are accessing PlayerController.Instance in another class’s Awake method. This is what is referred to as a race condition. The other class is trying to access Instance before PlayerController executed its Awake method, so Instance is not set up yet

That tracks … the debug log in the console gives me as much as you can see there, and when i double click the error it takes me to the lines in various classes that refernce the ‘playerControls’ variable. but how do i get PlayerController to execute before the other classes try to reference the instance?

Although the error seems to be more in relation to PlayerControls which is the action mapping and other than the PlayerController having an instance of PlayerControls (which i guess is still the instance referring to itself for all of its private variables) i cant see why else this would cause an issue. so im going to assume it’s still the instance = this; thing.

Also, thanks, Bix for the fast response and knowledgeable insight to the problem, it’s appreciated. I realise i didnt thank you in my last reply haha.

There’s usually a lot more detail (the stack trace) down at the bottom here if you click on one of the errors. If you look at it carefully you will see (from the bottom up) where the error started. It should show you which other class was trying to access PlayerControls.Instance

The rule is to not access other classes from within Awake. You can set references to things, but you should not call functions and methods inside Awake. You should rather do that in Start.
So, in this case, if you discover whichever class is trying to access PlayerControls.Instance when the error happens, you may find that this is happening in that class’s Awake method. Move it to Start and you should be fine.

Thanks, Bix.

Ill give that a try. Two points of curiosity, if you can answer, id be grateful to know:

What is the different between Awake and Start? I ask because the second curio point is

Why does it work in the tutorial code? I watched through a couple of extra times to make sure i hadnt missed anything but the code is the same in mine as the tutorial.

Thanks in advance :slight_smile:

See the documentation for Awake but especially Start. The Start documentation specifically says

There is no guarantee that objects instantiate in the same order on all machines. In the course, these objects instantiated in the correct order and PlayerControls's awake happened first, but in some cases, that does not always happen. On your machine, Unity finds these objects in a slightly different order and they then executes in a different sequence. Trust me, you’re not the first person to have race conditions because it all works well on the lecturer’s machine, but not on another one. Awake's happen first, but they can happen in any order. This is why we have this ‘rule’ to never call methods on other classes in Awake; you just don’t know if the other class has run its own Awake yet. If you wait until Start, you can be sure that the other class’s Awake has executed and it should be fine.

Awesome, thanks, Bix.

I felt like i was gaslighting myself and some code was wrong. But I always try to fix it myself before asking.

Thanks for the great explanations and fast responses.

One other question though because im not sure if moving the following will break anything else:

The other classes that take issue with the playerControls do indeed have the playerControls = new PlayerControls in the Awake method. I moved that line into a Start method but the error remains:


playerControls = new PlayerControls();

should be in Awake, this is the initialization for the class that is using the PlayerControls

Here’s the order of the methods as Unity calls them

  • Awake() - this is called on every MonoBehaviour in the scene when the scene loads (when Play is pressed)
  • Enable() - this is actually called immediately after Awake() on each MonoBehaviour
  • Start() - this is called after all Awake()/OnEnable() are called within the scene
  • Update() - this is called every frame

What I’m not sure of is why in the original code OnEnable wouldn’t have already had

playerControls = new PlayerControls();

ran, assuming that the first error line 30 is the line with the Lightbulb.

The sword makes sense because it’s very possible that Sword’s Awake() and OnEnable() ran before PlayerController, but I’m not seeing why the OnEnable is throwing an error.

Let’s add something to your Awake() method in PlayerController
After playerControls = new PlayerControls();

Debug.Log($"{} Awake - PlayerControls created = {playerControls!=null)}");

And then in OnEnable, add this as the first line

Debug.Log($"{} OnEnable - PlayerControls exist = {playerControls!=null}");

For future code pastes, pasting in the actual text of the code is much easier for us to work with than screenshots of the code. See the guide below.

Hey Brian,

Thanks for the reply. When i opened unity today and reloaded the project, none of the debug errors were there and the game runs fine. The old ‘turn it off and on again’ seems to have fixed it! But this was still an interesting learning point for future consideration and good practice for coding in unity :slight_smile:

Thankyou for the note on formatting, ill be mindful to post the code as code in future for easier help with support.

This happens a lot more often than you might think. My next recommendation if the Debugs were inconclusive was going to be to close Unity and delete the Library folder in your project, essentially forcing Unity to look at everything again.

ill bear the deletion of the library folder in mind, forcing a rebuild is always useful!

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms