Launching a game which executable is in a subdirectory of the main directory

[Aqa-Ib]

Imagine the following folder structure for a game:

• Game main folder: /home/user/game
• Executable folder: /home/user/game/x64/launcher.exe

In this case, the main game directory is different than the executable directory.

This game won't work when launched like this:

• cd /home/user/game/
• ulwgl-run /home/user/game/x64/launcher.exe

Using vanilla wine, a solution is to run it like this:

• cd /home/user/game/x64/
• wine start /d "/home/user/game" launcher.exe

Using Steam, we have the "Start in" field available:

Using Lutris we have a "Working directory" field.

How do we achieve this using ulwgl-run ?

[Aqa-Ib]

Alright I got it, it works when launched with a relative path to the current working directory:

• cd /home/user/game/
• ulwgl-run /x64/launcher.exe

Notice that the ulwgl-run command can't contain the full path in this case or it won't work.

[R1kaB3rN]

What's your specific use case? Personally, I've never used it when launching my games so I never saw the point of changing to a specific directory before launching a game.

I can give you this feature if it's not too niche, but it'd be via the configuration file usage. For example:

[ulwgl]
exe = "/home/user/game/x64/launcher.exe"
start = "/home/user/game/" # Directory to change to
proton = "/home/user/.local/share/Steam/compatibilitytools.d/GE-Proton9-1"
prefix = "/home/user/.wine"
game_id = "0"

[Aqa-Ib]

For some games I need to give ulwgl-run the .exe path relative to the cwd (current working directory).

When the game has its executable in a directory below the main game directory, it won't work without a relative path to the cwd.

However, I have also found a bug with ulwgl-run that is not present in vanilla wine. Consider a game directory with the main executable called frontend.exe, and a secondary executable called start.exe.

• cd /home/user/game
• If I execute ulwgl-run frontend.exe it works.
• If I execute ulwgl-run /home/user/game/frontend.exe it will launch start.exe instead.

I guess the bug is caused because of a Proton specific feature that I am not aware of.

P.S.: I don't need the feature personally, I am fine giving it relative paths. However, I appreciate it. Thanks.

[loathingKernel]

I can give you this feature if it's not too niche, but it'd be via the configuration file usage. For example:

FWIW, this is unusual but not niche in any way. Even recent triple-A games sometimes require such handling. IMO ULWGL should explore avenues to facilitate this for compatibility reasons.

I do not know how steam handles this though, if we are to emulate it, it is possible that the client itself switches to the working directory before executing the proton command.

[Aqa-Ib]

I do not know how steam handles this though, if we are to emulate it, it is possible that the client itself switches to the working directory before executing the proton command.

It has to be something else, because in Steam you can pass the absolute path to the executable contained in a subfolder and it works. In wine and ulwgl you have to pass the relative path. In Lutris you can also pass the absolute path. Maybe we can ask @strycore about this.

[loathingKernel]

It has to be something else, because in Steam you can pass the absolute path to the executable contained in a subfolder and it works.

Indeed Steam changes into the working directory of the game, as evident by printing the environment when a game is launched through Proton. PWD env variable is set to the game's directory.

to test set the following command as the launch options for any Steam game env | tee ~/game-env.txt #%command%

[Aqa-Ib]

Maybe after changing to the working directory of the game, it does something like this:

Compare the two strings:

• "StartIn" = /home/user/game
• "Target" = /home/user/game/x64/launcher.exe

If $Target contains $StartIn, then remove the contents of $StartIn from $Target, leaving it as a relative path:

• "Target" = /x64/launcher.exe

Now we can just execute $Target relative to $StartIn, and it will work.

[Aqa-Ib]

On the Linux side it doesn't matter if you use an absolute path for the executable as long as you are in the correct working directory before calling the executable, because ultimately the executable will be called from the directory it expects.

I have tried it, and in a case like the one I mentioned, it only works using a relative path to the cwd. I don't know why, but it is the reality on my system.

[loathingKernel]

I re-read the issue and noticed that you tried that. So I deleted my reply since there is obviously some interaction that I am missing here. This might be related to anything, needs more investigation.

[Yoghurt4C]

you don't have to imagine this structure if you have Grim Dawn in your steam/gog library; it keeps all of the x64 binaries - including dependencies and apis - in a subdirectory, and you will not be able to get to the main menu using the x64 executable if you don't step the working directory out of the subdirectory with said executable. steam (not sure if it's a thing on gog) handles switching between x32 and x64 through a launch argument but it's rather dubious either way

[ltsdw]

As discussed with loathingKernel on discord, I think this is related to my use case, one addon of the game Elder Scrolls Online, TamrielTradeCenter, has a client that should be run, if I run it before the game with either runinprefix or run, and after that I launcher the game, it launches normally, but when I do the opposite it doesn't:

Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: File not found. 

Here is an example:

If I run the game first:

WINEPREFIX=/home/med_user/.local/share/Games/TESO/pfx GAMEID=umu-306130 PROTONPATH=/home/med_user/.local/opt/GE-Proton9-2 /home/med_user/.local/opt/umu/bin/./umu-run runinprefix "/home/med_user/.local/share/Games/TESO/pfx/drive_c/Program Files (x86)/Zenimax Online/The Elder Scrolls Online/game/client/eso64.exe"

then the Client.exe which is in another partition:

WINEPREFIX=/home/med_user/.local/share/Games/TESO/pfx GAMEID=umu-306130 PROTONPATH=/home/med_user/.local/opt/GE-Proton9-2 /home/med_user/.local/opt/umu/bin/./umu-run runinprefix "/storages/xfs_storage_partition/med_user/Desktop/Documents/Elder Scrolls Online/live/AddOns/TamrielTradeCentre/Client/Client.exe"   

...

Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: File not found. 

It won't work.

The inverse works though (running the Client.exe first and after that running the game):

WINEPREFIX=/home/med_user/.local/share/Games/TESO/pfx GAMEID=umu-306130 PROTONPATH=/home/med_user/.local/opt/GE-Proton9-2 /home/med_user/.local/opt/umu/bin/./umu-run runinprefix "/storages/xfs_storage_partition/med_user/Desktop/Documents/Elder Scrolls Online/live/AddOns/TamrielTradeCentre/Client/Client.exe"   

WINEPREFIX=/home/med_user/.local/share/Games/TESO/pfx GAMEID=umu-306130 PROTONPATH=/home/med_user/.local/opt/GE-Proton9-2 /home/med_user/.local/opt/umu/bin/./umu-run runinprefix "/home/med_user/.local/share/Games/TESO/pfx/drive_c/Program Files (x86)/Zenimax Online/The Elder Scrolls Online/game/client/eso64.exe"

Also as discussed there, if I want to run the Client.exe I can also do this, which will work doesn't matter what working directory I'm in:

WINEPREFIX=/home/med_user/.local/share/Games/TESO/pfx GAMEID=umu-306130 PROTONPATH=/home/med_user/.local/opt/GE-Proton9-2 /home/med_user/.local/opt/umu/bin/./umu-run runinprefix start.exe /d "C:\users\steamuser\Documents\Elder Scrolls Online\live\AddOns\TamrielTradeCentre\Client" "C:\users\steamuser\Documents\Elder Scrolls Online\live\AddOns\TamrielTradeCentre\Client\Client.exe"

[Aqa-Ib]

Can you explain what "runinprefix" does and why you call start.exe ?

[loathingKernel]

To understand what these verbs do better, look at proton's __main__ function. In short runinprefix does exactly what it implies, it runs something in the game's prefix.

start.exe here is to use some of its arguments, for a list and a brief explanation, run wine start.exe /h

[Ketrel]

For what it's worth, you can do this still

/path/to/umu-run start /b /d "C:/Some/Folder/Path" "C:/Some/Binary.exe"

[loathingKernel]

The pressure-vessel docs also mention this constraint (first two points), linking it here for discoverability.

[R1kaB3rN]

The first point in the documentation can easily be implemented, but the current working directory in a subdirectory mess should be addressed in a protonfix unless there's a reliable way to handle it. For instance, does the Steam client reference a whitelist or have a configuration file for the correct directory to change to? For each game on Steam, there's a manifest file that contains an installdir field that we can try change to, but I'm unsure.

@Aqa-Ib for Grim Dawn, does the appmanifest_219990.acf file have an installdir field that references the correct directory to start the game?

[loathingKernel]

As far as other stores are concerned, they should provide the working directory in their metadata in one way or another. I know for example that legendary does have that information and sets that as the working directory before launching. It is safe to assume that other clients do that too, and that's why we haven't had a big influx of comments on this issue. This information is also required on windows, as the working directory is part of the desktop and menu shortcut specification. This is mostly relevant when using umu as a stand-alone application from the terminal.

Thus, a likely solution would be to allow users to arbitrarily set a working directory from the command line, for example.

[Aqa-Ib]

@Aqa-Ib for Grim Dawn, does the appmanifest_219990.acf file have an installdir field that references the correct directory to start the game?

I own Grim Dawn from GOG, unfortunately, it does not have a manifest file.
Cheers!

[spiffeeroo]

SteamDB shows the installdir config info.

https://steamdb.info/app/219990/config/

installdir Grim Dawn

[R1kaB3rN]

Hmm, I believe it may be possible solve this problem for Steam and GOG's case. Steam provides an installscript.vdf that contains metadata that is defined by the developer which may include its subdirectory. For example:

"InstallScript"
{
	"Registry"
	{
		"HKEY_LOCAL_MACHINE\\SOFTWARE\\Foo\\Bar"
		{
			"string"
			{
				"Install_Path"      "%INSTALLDIR%"
				"Exe_Path"          "%INSTALLDIR%\\foobar.exe"
			}

			"dword"
			{
				"PatchVersion"      "12"
			}
		}
	}

	"Run Process"
	{
		"DirectX"
		{
			"HasRunKey"     "HKEY_LOCAL_MACHINE\\Software\\Valve\\Steam\\Apps\\480"
			"Process 1"     "%INSTALLDIR%\\DirectX\\DXSETUP.exe"
			"Command 1"     "/silent"
			"NoCleanUp"     "1"
		}
	}
}

As for GOG, they should include an .info file in the game's top-level directory:

{
    "buildId": "55626781736221498",
    "clientId": "55466758769298188",
    "gameId": "1697970811",
    "language": "English",
    "languages": [
        "en-US"
    ],
    "name": "Flowers - Le Volume Sur Printemps",
    "playTasks": [
        {
            "category": "game",
            "isPrimary": true,
            "languages": [
                "zh-Hans",
                "en-US"
            ],
            "name": "Flowers - Le Volume Sur Printemps",
            "path": "FLOWERS.exe",
            "type": "FileTask"
        }
    ],
    "rootGameId": "1697970811",
    "version": 1
}

@Aqa-Ib What's the value of path for Grim Dawn?

[R1kaB3rN]

Steamdb even shows a launch option that's the relative execution path of the 64-bit executable -- x64/grim dawn.exe. It's possible that path may be in Steam's installscript.vdf too.

[Aqa-Ib]

Correct. The file is named goggame-1449651388.info and the path value inside is "path": "x64/Grim Dawn.exe". There is also the 32 bit executable path (the same as in steamdb).

[R1kaB3rN]

@Aqa-Ib Just made a PR to address the problem for GOG games. If you can make time to test it, that'd' be great. Parsing Steam's .vdf files will need to be addressed later -- I have to find some real examples.

Also, do you mind sharing the contents of the *.info file for Grim Dawn? GOG doesn't seem to make those files easily available, but I believe there should be a workingDir field.

[R1kaB3rN]

Actually, for Steam's case, I believe umu would need to get the subdirectory information via a game's launch options but unfortunately it doesn't appear it will be simple to retrieve.