Godot: Add debug/logging macro(s) for togglable debug output in the Godot source

[akien-mga]

Follow-up on https://github.com/godotengine/godot/pull/7079#issuecomment-259449908

Currently we have lots of print_line and printf calls in the source code, that are either active (and often noisy) or commented out.
It would be better to have a macro like DEBUG_PRINT for those debugging statements, that would only output the string passed as an argument when in debug mode (triggered by the -d, -debug command line arguments).

It might be worth discussing if we want several levels of verbosity too.

[akien-mga]

IMO this is a must have for 3.1, it's starting to be hard to manage. We now have a nice logging interface, it's time to make proper use of it.

[rxlecky]

A proper logging system would definitely be very helpful for engine development. I think, though, that more in-depth discussion about the scope and intended use case is required.

Is it going to be a tool that will be solely used by the engine developers for debugging and thus should adhere to the "the simpler, the better" philosophy? Or is it going to be a more robust tool with more functionality that could be used by the engine developers, but would also be exposed to GDScript to be used as a flexible logging utility for the game devs as well?

I personally think that a proper logging system would be helpful for game dev as well and thus it should be implemented for GDScript, sooner or later. However, maybe there is a good reason why the engine logging system should be more lightweight and thus separate from the more generic game logging system? Please, share your thoughts!

[neikeq]

What's the difference between this and the verbose printing we currently have.

[rxlecky]

I am not entirely sure what you are referring to by _this_?

Do you mean the lightweight engine-only version?

Is it going to be a tool that will be solely used by the engine developers for debugging and thus should adhere to the "the simpler, the better" philosophy?

Well, @akien-mga himself said about the print_verbose() function that he implemented:

It still doesn't handle #7095 in a satisfactory way, IMO we need to refactor the way we do logging in the first place (and add more relevant info messages as different verbosity levels). But it's an improvement over the current hack :)
I think verbosity levels would be only the first step towards a better logging system and it should be first designed to fit the engine needs.

In case you refer to the more generic version:

Or is it going to be a more robust tool with more functionality that could be used by the engine developers, but would also be exposed to GDScript to be used as a flexible logging utility for the game devs as well?

Well, I can see multiple additions that the game devs would appreciate and some have already been mentioned in other issues and gathered in the #19122 tracker issue. These include: Coloured output, folding/grouping same messages together, verbosity levels and filtering based on them, logging to file, ... Some of these would also be beneficial for the engine development as well, but not necessary.

Or is there something else you had in mind?

[neikeq]

I was asking what would be the difference between DEBUG_PRINT with -d,--debug and print_verbose with -v,--verbose.

Regarding different verbosity levels, that would be definitely welcome.

[rxlecky]

Oh, that... Well, I guess that was just an example?? And the idea is that the current logging system should be reworked?

But that's just my understanding of it. Maybe @akien-mga can explain what he had in mind.

[akien-mga]

This was partly obsolete by the print_verbose which I added already indeed.

Yet I'd want to see the whole system refactored in a cleaner interface with different verbosity levels, and well documented guidelines on what to use and where. The log messages should be integrated in the RotatedFileLogger so that we can also get them in file.

It should be not done to be exposed to GDScript, that would force overengineering something to make it configurable for all possible use cases, instead of focusing on what engine devs need.

[rxlecky]

I also see a benefit in implementing a proper log system with good guidelines on how to use it.

And I also see your point in why you'd prefer having the system separate from GDScript - and I partially agree. On the other hand, the reason why I suggested this in the first place is that I'd see a benefit in implementing this kind of system for GDScript too. So, would you prefer developing two separate systems, one for the engine devs and one for GDScript? What I had in mind is implementing the system for GDScript - you described it right, probably overengineered and configurable for all possible use cases - and then exposing the necessary functionality needed for the engine devs via macros.

Still, the priority would be developing the system for the engine first. Hence, the system would not be exposed to GDScript immediately. First, the necessary functionality would be implemented for the engine dev and the full functionality would be implemented later.

[Perrottacooking]

Hello Mr . akien-mga
Still with the same problem at v3.1.1 Stable?
You wanted a better debug feature right?
About code,did you can use VsCode then send to Godot
Im will see about legacy code of godot but,can you help me to create a better code feedback?