Question Show variable value debugging

Well I have looked at several videos saying "it's easy" start this, click that and viola you can see variables while debugging. They are all different in how they do it. Some want me to install something else others say it's build in. Well none of it works for me. I've spent 90m researching this to figure out an issue I am having that using Debug.Log takes too much work to do.

It's VS2022. woth Unity 2022.

I run my game, do the attach to unity in VS, run the build in development build and VS is doing nothing to show me the information on my variables. It just sits there.

So I have given up and finally am asking for help.

 

Depends what you mean:

- in the editor, via the inspector you can see all see all serializable variables

- in the build you would need to make a system to present them

- if you attach the debugger you can breakpoint and inspect any variables in scope where your breakpoint is halted

This will hold you back greatly. Debug.Log() is EASILY the best debugging tool for the simple reason that it is continuous and does not HALT the gameplay the way breakpointing does.

Debug.Log is so useful I have an entire blurb dedicated to it:

You must find a way to get the information you need in order to reason about what the problem is.

Once you understand what the problem is, you may begin to reason about a solution to the problem.

What is often happening in these cases is one of the following:

- the code you think is executing is not actually executing at all
- the code is executing far EARLIER or LATER than you think
- the code is executing far LESS OFTEN than you think
- the code is executing far MORE OFTEN than you think
- the code is executing on another GameObject than you think it is
- you're getting an error or warning and you haven't noticed it in the console window

To help gain more insight into your problem, I recommend liberally sprinkling

Debug.Log()

statements through your code to display information in realtime.

Doing this should help you answer these types of questions:

- is this code even running? which parts are running? how often does it run? what order does it run in?
- what are the values of the variables involved? Are they initialized? Are the values reasonable?
- are you meeting ALL the requirements to receive callbacks such as triggers / colliders (review the documentation)

Knowing this information will help you reason about the behavior you are seeing.

You can also supply a second argument to Debug.Log() and when you click the message, it will highlight the object in scene, such as

Debug.Log("Problem!",this);

If your problem would benefit from in-scene or in-game visualization, Debug.DrawRay() or Debug.DrawLine() can help you visualize things like rays (used in raycasting) or distances.

You can also call Debug.Break() to pause the Editor when certain interesting pieces of code run, and then study the scene manually, looking for all the parts, where they are, what scripts are on them, etc.

You can also call GameObject.CreatePrimitive() to emplace debug-marker-ish objects in the scene at runtime.

You could also just display various important quantities in UI Text elements to watch them change as you play the game.

If you are running a mobile device you can also view the console output. Google for how on your particular mobile target, such as this answer or iOS: https://forum.unity.com/threads/how-to-capturing-device-logs-on-ios.529920/ or this answer for Android: https://forum.unity.com/threads/how-to-capturing-device-logs-on-android.528680/

If you are working in VR, it might be useful to make your on onscreen log output, or integrate one from the asset store, so you can see what is happening as you operate your software.

Another useful approach is to temporarily strip out everything besides what is necessary to prove your issue. This can simplify and isolate compounding effects of other items in your scene or prefab.

Here's an example of putting in a laser-focused Debug.Log() and how that can save you a TON of time wallowing around speculating what might be going wrong:

https://forum.unity.com/threads/coroutine-missing-hint-and-error.1103197/#post-7100494

When in doubt, print it out!(tm)

Note: the

print()

function is an alias for Debug.Log() provided by the MonoBehaviour class.

 

Currently and for the last 4 years I have been using Debug.Log. I wanted to move up to using modern tools.

So you are saying just stick with Debug.Log because it is better.

 

This is engineering, everything comes with a tradeoff. Debug.Log() is the simplest to use and most flexible as far as showing what (simple) code is doing and displaying the values in a small quantity of variables.

If you need to freeze execution and runtime explore objects with the debugger, Debug.Log() is not well-suited to that purpose. Use the debugger.

If you need to change variables at runtime, Debug.Log() is also not useful.

Understand the tools and what they can do for you, and reach for the correct tool for the problem you are having.

 

Ok then I will stick to what I have been doing. I don't need to stop the code. I create wargames. I just need to see the data.

 

AWESOME!

You can also put cheesy bits of debugging numbers on the runtime screen: just make a debug UI Canvas and stick your output texts in there.

You can even use something like Lunar Console to see the Debug.Log() on devices.

 

I do that too. I guess the latest and greatest fancy tools aren't always the best solution.

 

Sure, Debug.Log is great, but sometimes we might need to analyze crash reports from users. There is an extreme lack of information about how to use debugging with Unity as attempted by the OP (i.e., attaching a debugger to a built game executable).

There's https://docs.unity3d.com/Manual/WindowsDebugging.html, which explains how to setup the debugger, but it doesn't talk about how to actually use the debugger to get valuable information about issues.

For example, I've got a crash happening in a user's project that happens right when the Splash Screen of Unity is shown. I go through the debugging process and am able to see the Call Stack that lead to a breakpoint in Unity's internal code. However, I have no clue what triggered that breakpoint besides the method names, as the parameter names and values are all gibberish (what does ESI with a value of 6F747548 mean!?).

In all likelihood I am doing something completely wrong, but the point is the docs for this are virtually nonexistent!

If anyone can point to some learning materials, it would be a huge help.

 

I figured out how to use the Unity Debugger in Visual Studios to track where it is locked.

 

You mean the option to "Attach Unity Debugger"? In my case, I can't seem to use it. The game launches and crashes almost immediately and the debugger just automatically closes.

However, if I use the Local Windows Debugger, a breakpoint is at least reached and I can see a call stack before the game crashes. I don't know why I am not able to use the Unity Debugger.

 

Yea I use it to look for lockups so it might not be good for your problem

 

I also recommend using OnGUI for simple value debugging. No need to create another Canvas or anything and it's super quick to add. An example I frequently use:

Code (CSharp):

1.  
2.         private void OnGUI()
3.         {
4.             if( Debug.ShowOnScreenInfo )
5.             {
6.                 int line = 0;
7.  
8.                 GUI.Label( new Rect( 20, 20 + line++ * 20, 500, 30 ), $"Distance={m_TargetDistance:N2}. Pitch={m_TargetPitch:N2}. Yaw={m_TargetYaw:N2}" );
9.                 GUI.Label( new Rect( 20, 20 + line++ * 20, 500, 30 ), $"Camera: Moving={IsCameraMoving}. Rotating={IsCameraRotating}" );
10.             }
11.         }
12.  

You can then have somewhere you toggle Debug.ShowOnScreenInfo on and off with the press of a button.
One thing with this approach you'll want to do is wrap all the OnGUI calls with a compiler flag to avoid it running on release code.

 

I do that on occasion.