Allow Godot to skip parsing CLI options and pass them to projects

[bend-n]

Describe the project you are working on

A command line argument parser addon for my projects.

Describe the problem or limitation you are having in your project

Many command line options(--help, --version) are used immediately by the engine, and removed from the args array.

So, if you do, say, godot -f, godot:

• removes the argument
• changes to fullscreen
• returns [] when you call OS.get_cmdline_args().

This is suboptimal if you want to make a CLI app, or a game with a CLI.

Note This proposal does not attempt to remove --editor(and friends) from tool builds.

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

I am now able to use --help in my game! Now I can change godots help message.

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

I think there should be a way to turn off godot's CLI handling.

Like so:

godot --fullscreen
# script has print(OS.get_cmdline_arguments())
[--fullscreen] # godot is not full screen

There are a few args that cant be removed however, such as --main-pack and --rendering-driver, but they're long enough as to not come up as a problem.
I think movie writer args can stay too.

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

With a lot of lines.

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

Not possible, cmdline args are core

[bend-n]

#2797 is somewhat related, but still wants the engine to have it's own args.

[YuriSizov]

and at best a option/method that lets YOU handle the arguments FIRST and then pass the leftovers to godot.

I mean, that's impossible. Godot needs to parse and consume command line arguments to launch your project in the first place. Some of the options define the work environment for the runtime too, and probably can't be set up afterwards.

Either way, I think this proposal is missing both technical know-how and a good explanation of the use case.

[bend-n]

I mean, that's impossible. Godot needs to parse and consume command line arguments to launch your project in the first place. Some of the options define the work environment for the runtime too, and probably can't be set up afterwards.

Objection! The exported godot needs not handle cli arguments.

Its like how ./exported_project -e doesnt launch the editor... Whatever arguments you give it, it will always open the project.
It also completly ignores --path, not sure why thats even included in the -h...

[Calinou]

The exported godot needs not to handle cli arguments.

A lot of people require their exported projects to handle command line arguments. This is the case for non-game applications using Godot, but also many Godot games exposing "power user" options.

[YuriSizov]

@Calinou They are saying that the Godot executable of an exported project doesn't need to handle our default arguments (-f, -e, --path, etc).

[bend-n]

The exported godot needs not to handle cli arguments.

A lot of people require their exported projects to handle command line arguments. This is the case for non-game applications using Godot, but also many Godot games exposing "power user" options.

Assuming you mean the --fullscreen options and such, thats why i think it would work if you handled the args, handle it yourself(allowing you to override -f), and then pass it to godot to deal with -f IF -f wasnt handled already, OR implement custom --fullscreen options (and using OS.fullscreen), which would be the only way to go if all cli handling was disabled, and you still wanted the "power user" experience.

If you mean generally handling command line arguments, what i mean is the default arguments (save for --main-pack in JS builds), (many of the default arguments are culled already in the exported project, but it seems some were forgotten, and hence do absolutely nothing except gulping the args) my argument is that they are completely unnecessary, frivolous, and can all be culled(with a project setting of course), to make way for complete custom argument handling. or the other options i outlined in the issue.

[Calinou]

@Calinou They are saying that the Godot executable of an exported project doesn't need to handle our default arguments (-f, -e, --path, etc).

I don't like the direction this proposal is going in, as many CLI arguments are useful to power users in exported projects. This is also a prerequisite for some proposals to be truly useful, such as #5449. Not all games will implement extensive settings menus (especially gamejam games), but sometimes having some way to override a parameter makes the difference between an unplayable and a playable game to some.

Any change of this kind needs to be strictly opt-in, and warned against in the documentation as it worsens accessibility. (This will break compatibility otherwise, as many projects rely on the ability to pass engine arguments in projects exported in release mode.)

Regarding the ability to print project-specific help with --help, I think this is a pretty good idea. However, instead of removing Godot's own --help, I would prefer having some dedicated handling that allows you to do that. This won't be trivial to implement as --help currently doesn't initialize the engine – it only prints text. To allow for project-specific help while making the engine help "robust" (it should have no dependency on the engine actually working), we could make the engine initialize itself and check for project-specific help after the engine prints its own help. This could also be a dedicated but standard CLI argument, such as --project-help.

[bend-n]

I mean of course the optimal way to do this (but also the hardest) would be to have some kind of user cli script, and to have a cli arg handler class that the cli script can touch

projects rely on the ability to pass engine arguments in projects exported in release mode

which project?

[bend-n]

Also, could just add a --script arg that lets you put in a get_window().fullscreen = true, then you can have full powa.

[Calinou]

Also, could just add a --script arg that lets you put in a Window.fullscreen = true, then you can have full powa.

This still makes usability worse than the status quo, as you have to write a script, save it to disk, possibly learn GDScript, etc. Remember that players are generally not Godot users.

To give a point of reference, most other popular engines have CLI arguments to force windowed/fullscreen mode and window size.

[bend-n]

Your saying that theyre power users, not random players that dont know how to use godot.

[Calinou]

Your saying that theyre power users, not random players that dont know how to use godot.

What I mean is that "power users" of a game are generally not Godot users. They just play various games and don't care (too much) about the engine it's running on – until it makes bad technical decisions that harms their experience 🙂

[bend-n]

I would still like to see a game that gets broken by this; And also, how did they learn the arguments anyways?
If they learnt the arguments from the documentation, we could just put in a page that details how to use it.
At the very least, I want to remove the short form arguments, as they are unreadable, and have conflicts with your cli.

[Zireael07]

Any change of this kind needs to be strictly opt-in

Agreed. @bend-n Consider that godot uses CLI arguments to specify renderer, or to run the project in current folder.

[bend-n]

Ive addressed those 2 examples:
renderer argument will stay, and editor builds will have all args.