You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unofficial mod loader for an existing game made with Godot. When launching the game, a temporary directory with a override.cfg file and main loop script is created, from where the game is ran.
Describe the problem or limitation you are having in your project
OS.execute, execute_with_pipe, create_process and create_instance all lack a way to change the working directory and environment variables of the new process without relying on OS specific shell commands.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Adding extra arguments to the mentioned functions would completely fix this issue. The new arguments would default to null. When null, the the child process inherits parent's working dir and enviroment.
Alternatively, a new class containing all the process start info would be created akin to C#'s ProcessStartInfo. It would include the executable path, arguments, working directory, environment variables and pipe configuration.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
If this enhancement will not be used often, can it be worked around with a few lines of script?
This issue can be worked around in C# by using it's process library.
In GDScript, shell commands can be used to change the working directory and environment variables and run the process, but they're OS specific. sh -c and cmd /C expect the series of commands to be passed as a single argument, requiring escaping logic for paths, environment variables and arguments.
On Linux, sh may link to bash, dash, GNU sh or busybox, potentially leading to inconsistent results.
Is there a reason why this should be core and not an add-on in the asset library?
There's already process start functions in Godot, not having these features severely limits their functionality for specific use cases
The text was updated successfully, but these errors were encountered:
Describe the project you are working on
Unofficial mod loader for an existing game made with Godot. When launching the game, a temporary directory with a override.cfg file and main loop script is created, from where the game is ran.
Describe the problem or limitation you are having in your project
OS.execute
,execute_with_pipe
,create_process
andcreate_instance
all lack a way to change the working directory and environment variables of the new process without relying on OS specific shell commands.See also godotengine/godot#5708
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Adding extra arguments to the mentioned functions would completely fix this issue. The new arguments would default to null. When null, the the child process inherits parent's working dir and enviroment.
Alternatively, a new class containing all the process start info would be created akin to C#'s ProcessStartInfo. It would include the executable path, arguments, working directory, environment variables and pipe configuration.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The extra arguments way:
The class way:
If this enhancement will not be used often, can it be worked around with a few lines of script?
This issue can be worked around in C# by using it's process library.
In GDScript, shell commands can be used to change the working directory and environment variables and run the process, but they're OS specific.
sh -c
andcmd /C
expect the series of commands to be passed as a single argument, requiring escaping logic for paths, environment variables and arguments.On Linux,
sh
may link to bash, dash, GNU sh or busybox, potentially leading to inconsistent results.Is there a reason why this should be core and not an add-on in the asset library?
There's already process start functions in Godot, not having these features severely limits their functionality for specific use cases
The text was updated successfully, but these errors were encountered: