Godot-proposals: Add a way to access stdout and stderr's contents from the engine

[EIREXE]

Describe the project you are working on:

A Rhythm Videogame

Describe the problem or limitation you are having in your project:

I would like to redirect standard outputs to my game so that I can log it myself and use it with steam logging services.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

Some sort of mechanism to redirect stderr and stdout, this would not only include print() calls but anything the engine has printed too.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

Could be a global singleton (or an existing one) that has a signal that is fired when a line is printed by the engine.

If this enhancement will not be used often, can it be worked around with a few lines of script?:

You could continuously read the log files, but I am not sure how well that would work.

Is there a reason why this should be core and not an add-on in the asset library?:
It needs to be core because the only way you could solve it is with an engine module, and I am not entirely sure if it could even be done without changing the engine's code.

[groud]

I don't really get it, redirecting stderr and stdout is a feature your OS is supposed to have.
At least on linux it's pretty easy to do.

[EIREXE]

I don't really get it, redirecting stderr and stdout is a feature your OS is supposed to have.
At least on linux it's pretty easy to do.

The point is to redirect STDERR and STDOUT to the game itself, exposing an API for it, unless there's a different way to do this already.

I think I may have worded it wrong, I want a way to access all engine logs at runtime, this includes whatever the engine prints.

[linkpy]

and use it with steam logging services.

You can't do that by piping the STDERR/OUT of Godot's process. It could also be useful for multiple loggers working at the same time (writing to a file, to the console, etc at the same time), which would print everything, even the message from the engine itself.

[willnationsdev]

So you want a built-in Log singleton that wraps all of the print statements made by the engine and enables you to override/redirect/reprogram the logging behavior? I fully support that idea. Would be very useful.

[EIREXE]

So you want a built-in Log singleton that wraps all of the print statements made by the engine and enables you to override/redirect/reprogram the logging behavior? I fully support that idea. Would be very useful.

Yes, this is exactly what I mean.

[Calinou]

What would be the most logical singleton for exposing this? I'm thinking about Engine::get_stdout() and Engine::get_stderr(). That said, I wonder if performance and memory usage would become an issue if stdout/stderr gets large after several hours (or days) of process uptime.

[EIREXE]

What would be the most logical singleton for exposing this? I'm thinking about Engine::get_stdout() and Engine::get_stderr(). That said, I wonder if performance and memory usage would become an issue if stdout/stderr gets large after several hours (or days) of process uptime.

Could add a boolean to enable monitoring of stderr and stdout (maybe a ProjectSettings option) and making get_stdout and get_stderr clean the buffer.

[CRHough]

Maybe versions of functions which print to stdout or stderr which return strings?

[Calinou]

@CRHough That requires modifying the code so you can get stdout/stderr, which is a no-go if you want to get output from C++ code (the engine itself) or add-ons you'd prefer not to modify.