Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Aqa-Ib opened this issue Mar 12, 2024 · 24 comments
Open

Comments

@Aqa-Ib
Copy link

Aqa-Ib commented Mar 12, 2024

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:

image

Using Lutris we have a "Working directory" field.

How do we achieve this using ulwgl-run ?

@Aqa-Ib
Copy link
Author

Aqa-Ib commented Mar 13, 2024

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.

@Aqa-Ib Aqa-Ib closed this as completed Mar 13, 2024
@R1kaB3rN
Copy link
Member

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"

@R1kaB3rN R1kaB3rN reopened this Mar 14, 2024
@Aqa-Ib
Copy link
Author

Aqa-Ib commented Mar 14, 2024

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
Copy link
Contributor

loathingKernel commented Mar 14, 2024

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
Copy link
Author

Aqa-Ib commented Mar 14, 2024

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
Copy link
Contributor

loathingKernel commented Mar 17, 2024

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
Copy link
Author

Aqa-Ib commented Mar 17, 2024

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
Copy link
Author

Aqa-Ib commented Mar 17, 2024

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
Copy link
Contributor

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.

@Aqa-Ib Aqa-Ib changed the title How to define the Working Directory for a game Launching a game which executable is in a directory below the main directory Mar 18, 2024
@Aqa-Ib Aqa-Ib changed the title Launching a game which executable is in a directory below the main directory Launching a game which executable is in a subdirectory of the main directory Mar 18, 2024
@Yoghurt4C
Copy link

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
Copy link

ltsdw commented Mar 28, 2024

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
Copy link
Author

Aqa-Ib commented Mar 28, 2024

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

@loathingKernel
Copy link
Contributor

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
Copy link

Ketrel commented Apr 1, 2024

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
Copy link
Contributor

loathingKernel commented May 14, 2024

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

@R1kaB3rN
Copy link
Member

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
Copy link
Contributor

loathingKernel commented May 17, 2024

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
Copy link
Author

Aqa-Ib commented May 17, 2024

@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
Copy link

SteamDB shows the installdir config info.

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

installdir Grim Dawn

@R1kaB3rN
Copy link
Member

R1kaB3rN commented Jul 1, 2024

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
Copy link
Member

R1kaB3rN commented Jul 1, 2024

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
Copy link
Author

Aqa-Ib commented Jul 2, 2024

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 added a commit to R1kaB3rN/ULWGL-launcher that referenced this issue Jul 4, 2024
@R1kaB3rN
Copy link
Member

R1kaB3rN commented Jul 4, 2024

@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
Copy link
Member

R1kaB3rN commented Jul 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants