search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.99k stars 21.16k forks source link

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

Closed akien-mga closed 3 years ago

akien-mga commented 8 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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

rxlecky commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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?

Calinou commented 3 years ago

Closing, as this has been addressed on the engine side with the introduction of print_verbose(). Further imporvements should be requested on the Godot proposals repository after searching for duplicates.