koobas.hobune.stream
Any way to see if a gameObject has a component from MonoDevelop debugger?
Obviously I can use GetComponent() in code, but that doesn't seem to work from the watch window as I would expect it to in Visual Studio. Also, browsing the gameObject in the debugger, I can't find a reference to any of my custom component types. Though, the common base component references are easy to find (renderer, rigidbody, collider, etc.). I guess I'm expecting an array of component references somewhere.
So, short of adding the GetComponent in script and recompiling, is there any way to effectively poke around in a gameObject's custom components from the debugger? I have captured a difficult-to-reproduce test case so it'd be nice to not have to try to recreate it. Also it'd be interesting to find out how this works internally.
I can only find this dead and unanswered similar question
http://answers.unity3d.com/questions/339428/using-functions-in-monodevelop-watch-window.html
Hmm, on trying to call functions from the Watch window in the debugger, I noticed that it claims that the request isn't supported by the protocol implemented by the debugee. So, apparently its a Unity limitation and not a $$anonymous$$onoDevelop limitation (which Visual Studio may also not be able to get around).
Still, any ideas for other approaches would be helpful.
Unfortunately I only have general debugging tips to offer:
Depending on the nature of the bug, you might be able to use Debug.Break() to pause execution of the game. That is the equivalent of pressing the pause button in the Editor only if something goes wrong. This is especially useful if you have a branching logic where a branch is only entered when something goes wrong. Doing it like this allows you to see the general state of the game from the Editor.
if(myNotNullClass == null)
Debug.Break();
To further help with the debugging process, you can view private variables of your custom Components by clicking on the three lines next to the lock icon just above the inspector. Like in this answer.
Good tip, but only usable when you can set up to diagnose a known, repeatable issue.
I use a regular breakpoint or a conditional breakpoint in the debugger ins$$anonymous$$d. That way, I can explore more than what the debug view in the editor's inspector will show and I can keep my scripts clean.
