Resolved Code works, but 1 of 11 identical prefabs generates error message.

I'm working on a little mini space 4X prototype. I'm trying to create green and red prefab border sprites around stars controlled by the player. The code works exactly how I want -- the screen looks good.

The console, however, is complaining. On the 9th of 11 stars -- and only on this one star -- I get the console message "the Object you want to instantiate is null." I've triple-checked, and the red and green sprite prefabs populate each and every star's Inspector fields. I have 11 stars, and I see 11 cloned prefabs (3 green, 8 red, but I can vary these numbers and get the identical result.) Why is the computer objecting to just one of these clones, and seemingly rendering it anyway? Here's the relevant code.

Code (CSharp):

1.  public StarBorder greenCircularBorder;
2.     public StarBorder redCircularBorder;
3.  
4.     private void Start()
5.     {
6.         if (ownedByPlayer)
7.         {
8.             Instantiate(greenCircularBorder, this.transform.position, Quaternion.identity);
9.             Debug.Log("Instantiated green");
10.         }
11.         else
12.         {
13.             Instantiate(redCircularBorder, this.transform.position, Quaternion.identity);
14.             Debug.Log("Instantiated red");
15.         }
16.     }

 

The easy way is to jump straight to the source of the problem:

Code (CSharp):

1. if (greenCirclularBorder == null || redCircularBorder == null) {
2.   Debug.Log($"Something was null on {name}!", gameObject);
3.   Debug.Break();
4. }

Because I included that second parameter to the Debug.Log() call, you should be able to click on the log message (ONE TIME, double click will take you to the code, we don't want that) and it will take you directly to the object which has the issue. This will either be in the project window or the hierarchy window.

 

You are a hero! I had not dragged the prefabs to the base Star class. Easy fix!

I'm new to Unity, and I haven't learned much about the debugger yet. I'm glad to have a way to zero in on problems. Thanks for the help!

 

To be pedantic,

Debug.Log()

and

Debug.Break()

are not the debugger, although it is often referred to as such.

Debug

is the class used to output stuff to the console. That's it.

The debugger on the other hand is Visual Studio or whatever IDE you have, when you correctly Attach to Unity so that you can set breakpoints and debug code. That's the debugger.

https://docs.unity3d.com/Manual/ManagedCodeDebugging.html

Depending on your proficiency at problem solving and instrumenting your code, anywhere from 50% to 100% of problems DO NOT require you to actually use the debugger. The main drawback to the debugger is that it FREEZES the game (or editor) completely rock solid when you hit a breakpoint, which makes debugging interactive UI stuff difficult. Calls in the

Debug

class do not stop the game / editor from running its main update loop, allowing you to continue interacting with your game while studying the output at the same time.

 

@kurt, thanks for that explanation of the Debug class vs the debugger. I have been using Visual Studio. I think I've also installed the Visual Studio Tools plugin, which I gather is required for its debugger. I haven't tried it at all. Up until now, using the Debug class has worked great for me.

With other engines, like Godot and GameMaker, I've sometimes found it invaluable to use breakpoints and line-by-line iteration through code. But yeah, in many cases, a little more thought might have solved the problem without getting down into the weeds like that.

Thanks again. So far one big plus about Unity is how quickly you folks answer my questions here!

 

And you can ALMOST get this with Unity with the Debug.Break() statement, or else with the >| single-step button at the top.

In fact, putting those two together is super-handy. Let's say you have a weird glitch that happens at the moment you destroy an enemy, something in his animation or loot toss-out perhaps. Then you:

- put Debug.Break() in the enemy's death routine
- play the game until you kill him, and now the editor will pause (from the Debug.Break())
- single-step ahead watching for the glitch.

 

That sounds great! Very good to know.

 

I'd like to add that Debug.Break only "requests" the editor to enter "pause mode". Pretty much like you pressed the pause button. The current code and frame will still complete. Debug.Break is much more useful when you need to evaluate references inside the editor as you can use the inspector and Unity editor for those tasks. The real debugger is more useful if you need to analyze the pure code and variables as they execute line by line. So both approaches have advantages and disadvantages. When the normal debugger hits a break point, the editor would freeze. So you can not inspect things in the editor.

So essentially Debug.Break works on a frame by frame basis while the debugger works on a line by line basis. Depending on the kind of problem you have one or the other approach is more useful. They are all just tools in your toolbox. Understanding how they work is essential when deciding which you want to use in which case. At least you should know the limitations of both approaches.

 

Thanks for that further info, @Bunny83. That’s good to know about monitoring the inspector vs watching code and variables line by line.

Incidentally, the inspector is awesome. Sometimes I just watch it as my game runs and I catch bugs or oddities just by casually watching variables change or components attach. Today I happened to notice that an object acquired a duplicate script at runtime. I had no clue that was happening. Fixed it.