Allow to specify command-line arguments when running project instances from the editor

[naturally-intelligent]

Related to https://github.com/godotengine/godot-proposals/issues/3357.

Describe the project you are working on: Multiple games and small apps.

Describe the problem or limitation you are having in your project: When running any project, often I will use a "dev.gd" file or other file to change the launch state of the application. However, doing this is problematic because:

1 - Finding the "dev.gd" file is frustrating when many GD files are open 2 - Don't want the changes to always be permanent across sessions 3 - Don't want the changes to always be included with a release build (often forget to undo the changes back to blank state, end up building again to wipe debug settings)

Describe the feature / enhancement and how it helps to overcome the problem or limitation: A simple line text edit, white font on black background. Optional and must be enabled in Godot Editor Settings. In this, the user of the editor can set a string for command line arguments to be passed to the application. For example:

"level=10 cash=50 health=800 scene=end-fight"

The application would be responsible for parsing these arguments just like regular command line arguments. When the Godot Editor is restarted, this console is blank. This console does not have permanence, the arguments could not be included in a release build. Something like these removes a bulk of the need for a constantly changing development GD file, a file which can cause havoc if not reset to blank on release. Having the arguments always visible and handy in the editor would be a relief.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: The argument string would be passed to the application at execution. The application would be responsible for using the arguments (would be ignored by default).

If this enhancement will not be used often, can it be worked around with a few lines of script?: It would be used very frequently, practically every session.

Is there a reason why this should be core and not an add-on in the asset library?: A lot of developers would love this feature!! :)

[KoBeWi]

2 - Don't want the changes to always be permanent across sessions 3 - Don't want the changes to always be included with a release build (often forget to undo the changes back to blank state, end up building again to wipe debug settings)

I use a similar thing. My debug file has lots of commented lines. If I want to "revert" something, I just comment it, for potential later use. It's not that bad tbh.

As for the second thing, you can just use if OS.has_feature("debug") as condition for executing your debug file, which will disable it automatically in release builds.

[naturally-intelligent]

I use a similar thing. My debug file has lots of commented lines. If I want to "revert" something, I just comment it, for potential later use. It's not that bad tbh.

This brings up another point, if you want to comment out all your debug statements... well now you have to make sure to add "pass" in your function or it won't compile. Which is another slog. Now I have quite a large project, is very annoying to maintain these debug statements. I would only really want to use hard-coded parameters for complicated testing.

As for the second thing, you can just use if OS.has_feature("debug") as condition for executing your debug file, which will disable it automatically in release builds.

Yes I also have a trick like this, but doesn't it make you uncomfortable to leave debug code in a release? I always wonder if it's really going to execute, ehhe. Also I check for existence of a file like "debug.txt" beside the executable, that I would only manually place there and (fingers crossed) not include in a build.

Another related issue, when you want to demo your game to someone, you run it and it starts funny, have to kill it, say "oops I forgot these debug lines" comment them out, run again. With this console widget idea, that will never happen on a new session, and easy to notice if you already have stuff in it.

[linkpy]

@naturally-intelligent why don't you simply exclude the file from the build ? Just make a build configuration "release" with "dev.gd" excluded from it.

[naturally-intelligent]

I suppose so, I mean there are a lot of handy suggestions to solve issue point #3 here, but hopefully that doesn't take away from the points #1 and #2 which are (in order) more important!! Cheers

[naturally-intelligent]

And also point #4 in another comment which is dealing with large dev files, scrolling up and down, commenting, and dealing with 'pass' in empty functions, etc. Basically I shouldnt need to be editing a gd file to get custom option into my app. Command line is a major part of that (and, as a common feature, in other engines/apps) and also running Godot apps from command line with arguments is something I used to do (but doesn't have a debugger there, so catch-22). Anyhow, the main point is getting command arguments into the app with a convenient method (and before anyone says it: no, editing the project file is not convenient, and would also be permanent)

:)

[Calinou]

I like the idea of being able to supply temporary CLI arguments, but I'm not sure how we can expose this in the main editor window without cluttering it. Right now, you can edit Main Run Args in the Project Settings, but it has two downsides:

• You need to open the Project Settings every time you want to change the arguments.
• The arguments will be saved to project.godot (and therefore in version control) if you forget to remove them before committing.

[naturally-intelligent]

If I have time I will make a screenshot with proposal interface mockup!

Just thought of another use for this feature:

• when you have multiple instances of Godot open on the same project, you can use this to specify different runtime configurations without changing shared code! :)

[Calinou]

Thinking about how to expose this feature with support for multiple debug instances…

This is what it looks like in the current master branch:

What about adding an Edit Command Line Arguments option below Run Multiple Instances? It would display a modal dialog allowing you to edit the arguments for instances 1, 2, 3 and 4.

The Main Run Args project setting would remain as its value is stored in the Project Settings. Its value would be preprended to the per-instance command line arguments. This way, you can use both features in tandem.

[naturally-intelligent]

Hey Calinou, excited and happy to see you taking an interest in adding this - thanks!

My two cents: I didn't realize you could run multiple instances. So my feedback here might not be perfect. But I would suggest either:

a) Using the same command line arguments for all instances

b) Adding a + button the command line argument widget, to add more lines, 1 for each instance, expanding the widget vertically.

I've made a quick little mockup of how I (kinda) envision it. It didn't work out as good as I hoped, but here it is anyways:

Had always envisioned it to be always there Under the pane below "Ouput/Debugger", but I don't know the complexities of the Godot interface internals. So maybe it would be best as another tab there (see Possible Placement red arrow).

[Calinou]

@naturally-intelligent Editing CLI arguments isn't a common operation (especially for beginners), so a bottom panel feels overkill to me. Also, since the number of running instances is limited to 4, we probably don't need to bother with a dynamic list.

My two cents: I didn't realize you could run multiple instances.

Support for running multiple instances from the editor was added in the master branch. It's not available in 3.2.x and can't be backported there due to the EditorDebugger rewrite.

[sairam4123]

Editing CLI arguments isn't a common operation (especially for beginners), so a bottom panel feels overkill to me. Also, since the number of running instances is limited to 4

Could it be increased to 8 anytime soon?

[Calinou]

Could it be increased to 8 anytime soon?

It could be increased to allow running any number of instances, but having to manage more than 4 windows at once (plus the editor's) is going to be inconvenient from a window management perspective. Not to mention you may run out of RAM (and swap to disk) if you try to run lots of instances on a system that has a low amount of RAM available.

[sairam4123]

I would suggest adding a argument when compiling the editor to have more instances or less instances, and keep the default to 4.

[Calinou]

I would suggest adding a argument when compiling the editor to have more instances or less instances, and keep the default to 4.

This doesn't need to be a compile-time option – we can just add more options to the menu that lets you select the number of instances to start. The question is, how many people will be equipped to make use of more than 4 instances (both in terms of hardware and ability to alt-tab through similarly-titled windows quickly)?

I think the usability benefits start to decrease as you start more instances, and the use cases also become more rare. It's not uncommon for a complex 3D project to slow down a PC to a crawl when you run just 2 instances of it at the same time, let alone 3 or more.

[sairam4123]

I think the usability benefits start to decrease as you start more instances, and the use cases also become more rare. It's not uncommon for a complex 3D project to slow down a PC to a crawl when you run just 2 instances of it at the same time, let alone 3 or more.

We can possibly disable running instances more than 4 on PCs with lower RAMs.

(both in terms of hardware and ability to alt-tab through similarly-titled windows quickly)?

For this we can let the users name the Titles, like having a custom title name for every window.

And I guess this is going off-topic, I'll probably make a Proposal for this later if necessary.

[akien-mga]

Following discussion in https://github.com/godotengine/godot/pull/57975 and on chat, I propose the following:

Configuration

Adding a dialog that lets users configure the amount of instances to run (thus replacing the existing hardcoded "Run 1 Instance" to "Run 4 Instances" menu entries), and the command-line arguments for each instance.

Here's a quick mockup of the idea (proper UX research still needed to actually make things user-friendly and good looking):

As discussed with @Faless on https://github.com/godotengine/godot/pull/57975, the run args for the additional instances should be saved in project metadata (in res://.godot/editor) and not in Project Settings: they are debug features that are not relevant to store in the project settings and shouldn't be applied at runtime (unlike "Main Run Args" which affects the main instance). See EditorSettings::get_singleton()->set_project_metadata().

The number of instances could configurable as needed from 1 to as many as you want (here I used a simple SpinBox but this could be done with a more advanced widget that allows adding/removing entries with + and - buttons, as well maybe as reordering them).

In the above mockup, "Main Run Args" is included as a convenience feature to be able to edit it easily (and reference it while adding potential other arguments - or replacing all arguments - for a given instance). It would still be tied to application/run/main_run_args so changing it here would also update the Project Settings.

For each run instance, it should be possible to either append to the "Main Run Args", or replace them. When appending, the %command% substitution shouldn't be supported as it doesn't make sense. But when replacing, it should be supported so that you can have full control over environment variables etc. for a given instance.

The configuration dialog would be access from the Debug menu for now I suppose.

The UI is just a general idea, things could be organized differently used e.g. a Tree. I trust folks from the editor usability team to come up with good ideas :)

Running

Instead of the "Run Multiple Instances" debug menu shown in https://github.com/godotengine/godot-proposals/issues/522#issuecomment-699537498, I would add a new "Play" button that uses the configuration done in the above dialog (e.g. named "Run Multiple Instances").

If we're worried that it adds too "Play" buttons, we could implement some kind of "More" menu as described in #1072 for another (but tangentially related) feature. That menu could then even be the one that gives access to the above configuration dialog.

Using the simple "Play" button would only run one instance like usual, using "Main Run Args".

[cyraid]

@akien-mga I like it! Would like to see this as well. :)

[Calinou]

@cyraid Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

[cyraid]

@Calinou Fair, but may I ask what's blocking this from being implemented? I believe I've seen others with small edits that would do the trick, and this would be really nice to have coming from Unity with Multiplayer Game Objects and their Multiplayer multiple instance support.

This PR https://github.com/godotengine/godot/pull/65753 may be close to what is required? So you could add a 'relates to' in the original post?

[cyraid]

For the impatient, there is a Plugin which (now) implements a lot of the functionality I needed, and hopefully others too. It allows custom arguments per instance, and launching several instances with the click of a button.

https://github.com/xiezi5160/MultirunForGodot4

(Since it's not yet updated on the asset library site, you may have to download the .zip directly from the github and import it for now)