A small demo/example project could be shipped in an example folder, showcasing out to setup the Logger for the various strategies, and the results one would get from it.

See e.g. https://github.com/KOBUGE-Games/godot-logger/actions/runs/1093521056

So I disabled it for now.

In #10 we were discussing how to use the modules the "right" way. I want to start a discussion on this topic and want to make a suggestion.

What is the purpose of the modules?

I don't know what the initial purpose of the modules was, but I think it was mainly to distinguish between logging locations.
This means to have the possibility to display the location of the code from where the log is published.
For example:
Class A logs with module A and Class B with module B and so on.

But @akien-mga may have more insight.

I don't think that this behavior is necessary or valuable for a Singleton Logger and if it is needed a new Logger can be created.
If this behavior is wanted we should make the Logger-Singleton more of a "factory" for logger than the "actual thing" to solve the modules problems.
This is just my opinion please discuss!

Suggestion

I want to convert modules more towards an "Appender" approach.
Which means the Logger holds modules which are all called if something is logged.
This means you can have a module for a file logging with custom logging and a module for the console and so on.

This would result in a change of the API and how the logger is used.

Any feedback is welcome!

Hi,

there appears to be some leftovers from converting godot-logger from Godot 3.x to 4.x:

Flushing the buffer checks the result of file.open(...) to see if there was an error. As FileAccess.open now returns the file handle as opposed to how it returned an error code in 3.x, we will always land in the following error-handler – which will fail itself, as the resulting file handle is not a valid parameter for the %d string formatter.

[ERROR] [logger] Could not open the 'user://logfile.log' log file; exited with error <FileAccess#-9223371805681513908>.

(output when I fix the %d issue)

Following the GD doc, you'll probably want to use get_open_error instead for this handling.

Since the singleton is starting to get lengthy (over 400 lines), we can't really expect users to read it all through to know how to use :)

The instructions could be in the README.md plus maybe a header in the file itself.

Currently, godot-logger is a singleton script that needs to be added manually to the project settings.
I propose to make godot-logger a Godot addon that can be installed from the AssetLib.

The plugin can do :

• install logger files to addons directory.
• Automatically once installed, add the script as a singleton to the project.

The purpose of this strategy is to remember/queue a fix number of messages, that can be retrieved using e.g. Logger.get_remembered_messages(module = "main"). Those messages can then be e.g. displayed in the game UI itself.

If we want it to be customisable by module and by level, then the queue probably needs to be shared in a similar way as done for logfiles, so that each module can reference its own or shared queue.

Any chances that this could be ported to Godot 4?

Right now everything can be configured, but would have to be done in the _init, _enter_tree or _ready of the main scene.

The singleton should have a mechanism to save and load its configuration (default parameters, defined modules and their parameters).

This could likely be done by appending the project's engine.cfg with a logger section, or maybe using an own logger.cfg file. I'm not sure how saving the settings should be handled though, as these settings would typically be overridden at runtime, and then saving them would imply that they're saved in user://. So that doesn't prevent the developer from having to define everything manually at least once somewhere.

Thoughts?

Hey,

I like this approach of a single file as a logger. But I think it lacks some nice-to-have features.
Like:

• Adding the option to print a time stamp
• Error handling (Using the return codes of Godot for better logs)
• Also using multiple modules at once, so they behave more like appenders / log configs and make them more modular to comfort more needs
• Signals to confirm logging for more loose coupling
• Integration in the Godot Asset Library

But a lot of these features are already done:

• Error handling and signals: Samuel-Lewis@4245a8d
• Time stamp: hedin-hiervard@211f007

But some of these changes are in PR #6 but it seems dead.
So I'm asking how to go forward should I do pull requests for each topic?
Are these topics wanted?
And how active do you maintain this repository?

I make "normal" Software with Godot and this logger is extremely useful and I like to expand it.

The setting string should be "application/config/name" for Godot 3.0.
see: ProjectSettings

I think it would be a good idea to use a code style for this project.
It would make it easier to review and contribute.

I would propose using gdscript-toolkit, which includes a linter and a code formatter to create uniform code.

What are your thoughts on this topic @akien-mga @Samuel-Lewis?