Open KoBeWi opened 2 months ago
My concern here is how to ensure arguments are correctly identified as invalid, for example test specific arguments are not listed on the main list and aren't directly available there, so we'd need some way to reliably perform this check
We need to make sure that the process of adding command line arguments doesn't become too messy or difficult and error prone
I've seen many 4.x projects that don't use the user command line argument syntax (it can be a bit tedious to always have to write -- --<argument>
after all), so this is a change that would impact existing projects.
One way to make its impact more reasonable would be to print a warning instead, and have this warning be disableable in the project settings. (This means warnings would have to be printed after project.godot
is read though, as opposed to happening truly at engine initialization time.)
Warnings would also help with flexibility between versions, where a potentially non-critical argument is passed where it not being used isn't critical, but it'd be annoying to have to adjust the arguments for automation
I concur with a warning. The proposal's idea is potentially too disastrous. There's no real proper way to define "invalid" command line arguments, distinguishing them from user-defined, intentional arguments (for example no Project Settings on the matter). Use of standards is not always guaranteed.
I've made an implementation of this proposal that should be as unobtrusive as possible: https://github.com/godotengine/godot/pull/98895
Reopening as the PR was reverted.
Describe the project you are working on
Godot
Describe the problem or limitation you are having in your project
When running Godot with unrecognized arguments, they will be ignored and the engine will proceed normally. This can cause some unexpected problems.
My experience just now - I tried to generate mono glue. I ran Godot with
--headless --generate-mono-glue
. The engine started and... nothing was happening. I realized after a while that I ran non-mono executable by mistake. I then ran correct executable, but it printed "assemblies not found" error. So I went to documentation to see if I didn't setup something, and no, no such thing was mentioned as prerequisite. Then I noticed I had a typo in generate command (made when I was testing something before). This made Godot ignore the generator and attempt to start normally, which prompted the error. I wasted time, because the engine ignored incorrect commands.Describe the feature / enhancement and how it helps to overcome the problem or limitation
When running Godot with unrecognized arguments, print an error and quit instead of doing nothing with it.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The implementation is rather simple, but there are 2 considerations:
--scene
or something), so sometimes it will try to interpret a command as scene name, resulting in weird errors.For the first case, we can add
--scene
argument for providing scene. For the latter case, users can provide user arguments after--
(get_cmdline_user_args()
). Both changes however break compatibility. If it's not acceptable (which I assume so), the engine could be stricter only in dev builds. The problem is more relevant for engine development.If this enhancement will not be used often, can it be worked around with a few lines of script?
No.
Is there a reason why this should be core and not an add-on in the asset library?
Yes.