Having the ability to log an entire object to the console and have it be explorable (in the same way hierarchy objects are explorable - with a dropdown arrow that expands each property of the object) would be incredibly useful for debugging. Think of web debugging - every property, collection, and nested object can be expanded and viewed in the console.
Currently there are a few ways to do something similar to this:
Using JsonUtility.ToJson: this results in an ugly serialized object.
Using recursion: this allows you to get the properties and/or fields of an object and can be custom formatted to be more readable.
The biggest problem with both of these methods (and all others like them, as far as I’m aware), is that they don’t show collections and nested objects. Ultimately this means that if you want to see collections, nested objects, or any data type that these methods don’t support (or don’t display in a human-readable format); you have to use multiple debug statements (often inside loops for collections) or use a function that recursively logs absolutely everything and then wade through mountains of text. This can end up adding a lot of time to the debugging process.
I would love to see the addition of something like: Debug.LogObject() and Debug.LogObjectRecursive() that produces a well-formatted expandable objects (and includes collections and nested objects when using the recursive option).
EDIT: Thinking about this some more, there’s actually no need for new Debug methods since Debug.Log on an object currently just logs the class name (which is not very useful). Just modify Debug.Log so that it logs an explorable object on the next line (if there are strings being logged as well) and add a recursive parameter.
I would write my own utility function to do this, but I don’t think it’s possible without replacing the default console; since Unity’s console only displays text, and not interactable objects.
Oooh… it should be like a “Prefab Editor” dive into the deepening hierarchy of objects, each one inspectable for all of its public / serialized fields. I like it.
AND… it should have a < > back and forth navigation tab, just the same way the scene hierarchy and project windows NEED SO DESPERATELY!!
I think it’d be useful enough if the Debug.Log() just told you which object it came from. Maybe you double click it and it highlights the GameObject in the Inspector. All the other stuff can be seen by just going into Debug mode in the Inspector.
The only problem with this is it doesn’t “take a snapshot” of when the Log was actually posted, but I think you can just get around that by using Debug.Break() when you want to pause.
But that only works for GameObjects (and only ones that haven’t been destroyed). What I’m proposing would work for all kinds of objects, including ones dynamically created during runtime. Personally, I find myself debugging my custom C# objects far more often than I do GameObjects.
Traditional breakpoint debugging is great for tracking down tricky bugs; but it takes time to enter debug mode, make your breakpoint/s, hook your IDE into Unity, and then step through the code until you get to the point of failure (which isn’t always obvious). When you just need to take a look at an object’s state at a given point in time, simply being able to serialize and log that entire object at that moment in time (and have it be explorable) would be invaluable.
What I’m really asking for is for the console to support more complex interactive data, like what other Unity views (Hierarchy, Inspector, Prefab, and many others) have. If that were implemented, then we could create custom log objects containing all the data we need and have it formatted exactly how we want, which would really speed up the debugging process. Logging entire objects is already possible; it’s just extremely clunky and hard to find the info you’re looking for.
In the editor there should be a searchable, sortable diggable picklist of every object derived from UnityEngine.Object that has been created since the last STOP PLAY.
It would start with everything in your scene that gets stood up when you LoadScene, then go to all the other stuff you add in code. With an editor-time log of all the items, one after the other, presented as a big list, by default sorted by “most recently created,” you could easily get to the bottom of a lot of typical mysteries.
I theorize that somewhere there are is a malloc() call deep in the native engine and all it would have to do is linearly write down each object in a long blob of memory, which would be a tiny performance hit. Only when you go back digging would it require lots of digging, reflection, editor UI updating, etc.
It would sorta be like Process Explorer but for UnityEngine.Object blobbies of all kinds: Components, MonoBehaviours, GameObjects, everything!
Except Debug.Log can already do that. Check the 2nd overload in the docs, where you can provide a context object that is highlighted when you select the log entry.
If you want something you can do right now, I bet somewhere on the Internet is a program where you can copy/paste in some JSON and view it in a nicely-formatted expanding hierarchy.
(Any extra work you’d need to do to tell your JSON serializer what data to serialize or not is work that you’d also need to do in a hypothetical Unity built-in system, for the same reasons, i.e. that the person writing the serializer has no way of knowing which references are “conceptually” part of the same object vs which are “external”, unless you tell them.)
Didn’t get the chance to reply at the time, but calling Debug.Break pauses it in the editor, stopping it so you don’t need to pull up the IDE and set break points and what not. You won’t be able to view things like static classes in the unity editor, but as long as something is serializable and connected to a gameobject some how you should be able to view it through the debug menu in the inspector.
I see. Well, lots of wasted time then which could’ve been saved by looking at the docs.
Agreed RadRed… Debug.Break() is another amazing bridge between your running game and figuring out what is going on, but beware:
Debug.Break() simply sets a flag, nothing else. All the rest of your code, 100% of every bit and bob, all the Update() calls and probably any pending FixedUpdate() and everything WILL be executed for that frame.
Just want to point this out since if you have a weird edge case where you turn something OFF and then some other piece of code turns it ON in the same frame, Debug.Break() won’t really help you find that, since both OFF and ON will have happened by the time you observe it in the paused editor.
Right. This probably should have gone in the Editor forum, because what’s really needed is an upgrade to the console. Obviously copying your objects into a web app isn’t very practical, but this would be something interesting to explore as a Console extension asset.
This is true - and I already use this debugging method extensively. Singletons are very useful for holding references to runtime data that you want to debug. It’s just that I very often find myself working with non-Unity objects that are created and destroyed during runtime (or an object that couldn’t be fully created due to the error I’m trying to fix).
Even when this approach does work, it’s often pretty tedious to have to find the parent GameObject and then dig all the way down (in my case, through many views, panels, objects, collections, and more objects) to the data you need - versus just having it dumped directly into the console.