Disable some unsafe CLI arguments in template builds by default.

[bruvzg]

Follow up to #108818

Splits disable_overrides into two:

• disable_overrides - disabled by default, only affect project config override (which can be also disabled via project setting).
• disable_path_overrides - enabled by default, disables project path/pack overrides and script CLI arguments, and forces PCK/project loading from executable or resource directory instead of CWD to ensure only project files bundled with executable are loaded.

[Calinou]

Tested locally, it works as expected.

However, I'd make the existing arguments print an error when run, so that it doesn't fail silently like it currently does:

$ path/to/template --path ~/d/3d/truck_town/
Error: Couldn't load project data at path ".". Is the .pck file missing?
If you've renamed the executable, the associated .pck file should also be renamed to match the executable's name (without the extension).

See an example of this here:

godot/main/main.cpp

Lines 932 to 934 in 9cd297b

	ERR_PRINT(
	"`--test` was specified on the command line, but this Godot binary was compiled without support for unit tests. Aborting.\n"
	"To be able to run unit tests, use the `tests=yes` SCons option when compiling Godot.\n");

Also, note that if you cd to a project folder (not a PCK), you can still run it directly with an export template binary:

$ ~/d/3d/platformer: ~/g/bin/godot.linuxbsd.template_release.x86_64

Therefore, I'm not sure the CWD handling is working correctly.

(Moving or symlinking the binary to the project folder and running it there will keep working, but I think that part is to be expected.)

[Calinou]

Note that this PR will impact https://github.com/GodotModding/godot-mod-loader due to the removal of --script, unless the project uses a custom export template compiled with disable_path_overrides=no. It will have to find another means of injecting its code into projects.

godotengine/godot-proposals#6137 could make this possible using override.cfg, as long as the project uses official export templates (or doesn't change disable_overrides from its default no state in custom templates).

[bruvzg]

godotengine/godot-proposals#6137 could make this possible using override.cfg.

There's already a way to use it without any changes (see comment in the proposal), which looks a bit hacky but should work.

[bruvzg]

Also, note that if you cd to a project folder (not a PCK), you can still run it directly with an export template binary

Seems like get_bundle_resource_dir on Linux is ., so this is likely the reason, I will add some extra checks.

[bruvzg]

Some notes:

Options disabled by disable_path_overrides (enabled by default for templates, always false for editor):

• --path and --scene - used to run editor instances (including project running form editor), so should not be needed for the export templates.
• --upwards - used for unit test in the editor, so not needed for templates.
• -s, --main-loop - intended primarily for the engine development (but also used by mod loader, so will break its current installation method).
• --main-pack - seems to be used only on Web, so enabled for this platform only.

Options disabled in release templates:

• --remote-fs and --remote-fs-password - can be used by editor to run project on remote device (editor always use debug template).

[akien-mga]

--upwards - not sure why this option exist, seems completely useless, maybe we should remove in entirely?

Yeah that's a legacy option, it lets you run a Godot project while in a subfolder by looking up the project.godot file recursively. It's dates back to Godot being open sourced.

Let's keep it for now but deprecated (printing a warning about it), so if users rely on it in some scripts, they'll have until 4.7 to adapt their scripts, and we can drop it then.

Edit: Actually scratch that, let's just drop it straight and document it in the migration guide. It's simple enough to work around when upgrading.

[bruvzg]

--upwards - not sure why this option exist, seems completely useless, maybe we should remove in entirely?

Actually, it is used for a bunch (GLTF, DDS, GDScript) of unit tests (which make sense, tests are upwards of bin sub-folder), so I guess it should stay at least in the editor builds. Not as argument, but underlaying code is used.

[bruvzg]

Removed --upwards argument, but not ProjectSetting code for it, since it used (by directly calling setup) by unit tests.