Allow editor plugins to modify run arguments and re-run from within project

[dsnopek]

This PR aims to allow GDExtensions on desktop platforms to do what PR #103972 does (but that other PR targets the Android editor)

The ultimate goal is to allow the godot_openxr_vendor extension to simulate running a hybrid immersive/flat VR app on desktop, so you don't need to deploy to the headset for testing.

See GodotVR/godot_openxr_vendors#312 for the rest of the implementation of that

This is a DRAFT for now, because I need to do more testing (especially with the new embedded game view on multiple platforms)

[dsnopek]

This could still use more testing, although, it's working well for me on Linux (both with the embedded game view and not) so I think I'll take it out of draft

NOTE: this is squarely targeting Godot 4.6 at this point

[KoBeWi]

I think it would be more efficient if you just passed the Vector as argument and don't expect it to be returned. Since it's passed as reference, the plugin can modify it all the same, without making an unnecessary copy. Although the copy is only made when a plugin implements the method, so it's probably fine either way.

I also noticed that there is discrepancy between arguments passed to the new method and the ones returned by OS.get_cmdline_args() in running project. Specifically, the _run_scene() is called with empty array, while at runtime the array includes --scene and scene path. Not a big deal though.

[KoBeWi]

What are the debugger changes for?

[dsnopek]

@KoBeWi Thanks for the review!

I think it would be more efficient if you just passed the Vector as argument and don't expect it to be returned. Since it's passed as reference, the plugin can modify it all the same, without making an unnecessary copy.

While passing it as a reference and modifying it in place would work in the engine itself, I don't think it would work from GDScript or GDExtension. In that case, I think a copy would be made as soon as any elements were removed or added to the Vector, and the whole point of this virtual method is to add or remove stuff.

Since this only happens when the user clicks the "Run project" or "Run scene" button, I don't think we have to worry about being very efficient here.

I also noticed that there is discrepancy between arguments passed to the new method and the ones returned by OS.get_cmdline_args() in running project. Specifically, the _run_scene() is called with empty array, while at runtime the array includes --scene and scene path.

This is by design. I don't think we want plugins to mess with all the arguments that the editor adds automatically, just the additional ones. Otherwise a plugin could sneakily change which scene is being run, or the port the debugger is going to connect to, etc.

What are the debugger changes for?

To allow the application to trigger itself to relaunch with different arguments, while still allowing the new instance to run in the embedded game view (if enabled) and connect to the debugger.

These changes are to enable PR GodotVR/godot_openxr_vendors#312 for the godot_openxr_vendors GDExtension.

That PR aims to allow basically the same as PR #103972 (which only works when running the editor on Android), but instead simulating it on the desktop, so you can test hybrid apps (XR apps that can switch between immersive and 2D panel modes) without having run on a real headset.

[KoBeWi]

To allow the application to trigger itself to relaunch with different arguments, while still allowing the new instance to run in the embedded game view (if enabled) and connect to the debugger.

How can this be tested?

[dsnopek]

@KoBeWi:

How can this be tested?

Well, you can test it via GodotVR/godot_openxr_vendors#312 and the Meta XR Simulator, but that's a lot of extra stuff to setup :-)

So, here's a minimal demo app to test it:

editor-plugin-run-test.zip

[KoBeWi]

Here's a scene that does (almost) the same in vanilla Godot:
main2.tscn.txt
The only difference is that the project re-launches without debugger (though that can be fixed probably), and set_restart_on_exit() sometimes fails.

I guess adding request_run_scene is fine, but it's not really related to this PR and can be done separately.