godotengine / godot

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

`get_cmdline_args` not contains the used Godot arguments #92831

Open MikeSchulze opened 5 months ago

MikeSchulze commented 5 months ago

Tested versions

v4.2.2.stable.mono.official [15073afe3]

System information

Windows, macOS, Linux

Issue description

I want to determine the engine is running outside the Godot editor by checking the used command line arguments to decide my plugin should be load or not. This is need to not load the plugin UI stuff when running in a test environment, e.g. GitHub CI action.

e.g. $GODOT_BIN --path ./ -e --quit-after 2000 --headless Printing the result of

    var args := OS.get_cmdline_args()
    args.append_array(OS.get_cmdline_user_args())
    prints("plugin cmd args", args)

shows only plugin cmd args ["--editor"]

I would expect to get all used arguments here. I found this issue https://github.com/godotengine/godot/issues/84019 about --headless but it is a common issue.

There are a bunch of engine arguments like this that get trimmed from get_cmdline_args()'s output from some reason, but I could never understand why.

So at least it is inconsistent, the --editor is not filtered. This blocks me to decide to run the plugin UI part or not when calling form command line. Using a custom argument will me not help because my tool can be used by custom users, e.g. rebuild the Godot cache by only using the Godot --import parameter.

Steps to reproduce

use the simple plugin example

@tool
extends EditorPlugin

func _enter_tree() -> void:
    check_running_in_test_env()

func _exit_tree() -> void:
    pass

func check_running_in_test_env() -> bool:
    var args := OS.get_cmdline_args()
    args.append_array(OS.get_cmdline_user_args())
    prints("plugin cmd args", args)
    if args.has("--add") or args.has("-a") or args.has("--quit-after") or args.has("--import"):
        return true
    return false

try running the godot via command line $GODOT_BIN --path ./ -e --quit-after 2000 --headless --foo shows plugin cmd args ["--foo", "--editor"] or with the new --import option $GODOT_BIN --path ./ --import --headless --foo shows plugin cmd args ["--foo", "--editor"]

So there is no way to detect Godot is running with specific Godot arguments.

Minimal reproduction project (MRP)

n/a

AThousandShips commented 5 months ago

This is intentional and documented, this should be a proposal instead IMO as it arguably hurts compatibility and might be undesirable in various ways

You can already access the --editor and --headless for example can be accessed by better means from code

MikeSchulze commented 5 months ago

This is intentional and documented, this should be a proposal instead IMO as it arguably hurts compatibility and might be undesirable in various ways

No, is it not, it's nothing about the standard editor arguments will be filtered.

Passing custom user arguments directly is not recommended, as the engine may discard or modify them. Instead, the best way is to use the standard UNIX double dash (--)

If this is the case, then it is very vague, and rather imprecise in the sense of “it is best to use the standard UNIX double dash (--)”, e.g. “--import” has the double dash but is filtered

This is intentional Why should these arguments be filtered out? What is the reason for this?

Can you provide me a solution to check the editor is running the --import mode?

AThousandShips commented 5 months ago

I'd say it's pretty obvious the engine wouldn't filter out your custom commands that aren't engine commands, that goes without saying, but sure it could be made even more obvious

If this is the case, then it is very vague, and rather imprecise in the sense of “it is best to use the standard UNIX double dash (--)”, e.g. “--import” has the double dash but is filtered

That's not what it's saying, it's godot --editor -- foo as explained below, it doesn't mean the --import it means the double dash on its own, it says pass the standard UNIX double dash (--) and then the custom arguments, the "and then the custom arguments" part is what clarifies this

You can see it explained with this example from the docs:

# Godot has been executed with the following command: # godot --fullscreen -- --level=2 --hardcore

Can you provide me a solution to check the editor is running the --import mode?

Why do you need to? But to my knowledge no, but it doesn't change anything in the editor code beyond when it exists

If you need special behavior just provide extra flags, the editor doesn't do anything different when calling --import, it just exits after, if you rely on that flag itself your code is likely fragile and you should use some better method IMO

MikeSchulze commented 5 months ago

Why do you need to? But to my knowledge no, but it doesn't change anything in the editor code beyond when it exists

The use case is quickly explained, the plugin code should not be executed if, for example, --import or --quit-after is used. These arguments are usually used to restore the Godot cache, in this case the plugin code should not be executed. The workflow for CI workflows is:

AThousandShips commented 5 months ago

Then just add your own custom argument? Simple and reliable, unlike possible changes to what --import does, again the editor doesn't do anything differently with the --import command except just exiting after importing

0xafbf commented 4 days ago

I have another use case for this: I am spawning a new godot instance (a headless gameserver) and I want to send the --remote-debug and --editor-pid arguments to it so it attaches to the editor.

I did some changes to allow this in my custom build, but I think it should just send all the unfiltered arguments to the game. Maybe it would break some games that don't expect these (--remote-debug, --editor-pid, --position, etc...) but I think games should only use get_cmdline_user_args in the case they are very sensitive to flags being passed, and games that check get_cmdline_args should be confident they're getting everything, and not only some blessed (undocumented) parameters.

I'll try to find some time to make a proposal