Add a way to access log path when "--log-file <file>" is used

[Germenzi]

Describe the project you are working on

N/A

Describe the problem or limitation you are having in your project

In multiplayer projects several instances are opened when debuggind, so one file specified in ProjectSettingns can't be used, so --log-file <file> cmdline arg is used, but in this case there is not way to access this path in instance runned with this argument. So one can't read this file to show stdout in application gui, for example.

Also such arguments can't be accessed via OS.get_cmdline_args(), so there is no way to catch log file path reassigning.

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

Add a way to acces path, by overriding related project setting for example. Or define standalone function for this, OS.get_stdout_file_path for example.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

if ProjectSettings.get_setting("debug/file_logging/enable_file_logging") or ProjectSettings.get_setting("debug/file_logging/enable_file_logging.pc"):
    print(ProjectSettings.get_setting("debug/file_logging/log_path"))

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

N/A

Is there a reason why this should be core and not an add-on in the asset library?

N/A

[Calinou]

So one can't read this file to show stdout in application gui, for example.

For this use case, https://github.com/godotengine/godot-proposals/issues/8964 is more suited than reading a file continuously.

Also such arguments can't be accessed via OS.get_cmdline_args()

I'm surprised these arguments can't be accessed. It definitely sounds like these should be exposed as these are engine command line arguments, not user command line arguments (they're specified before an optional -- separator).

cc @KoBeWi

[KoBeWi]

main.cpp checks all arguments, and if an argument doesn't match, it adds it to the returned argument list: https://github.com/godotengine/godot/blob/3978628c6cc1227250fc6ed45c8d854d24c30c30/main/main.cpp#L1746-L1748 Which means that all recognized arguments will not end up there.

[Germenzi]

Maybe it's worth to create something like OS.get_builtin_cmdline_args?

[KoBeWi]

IMO we don't need a new method, they can be part of get_cmdline_args(). The fact that they are skipped is either intentional (so they shouldn't be in any list) or an oversight.

[Calinou]

IMO we don't need a new method, they can be part of get_cmdline_args().

Yes, I'm not sure why they are removed from get_cmdline_args() in the first place. Was this behavior in place in 3.x? If so, this may have been changed during https://github.com/godotengine/godot-proposals/issues/2797.

[KoBeWi]

The code is the same in 3.x. It's likely always have been like that.