Launching some games via minigalaxy leads to various errors due to the wrong executable being launched

[ell1e]

Trying to launch Unreal Gold leads to minigalaxy error with backtrace:

~ $ flatpak run io.github.sharkwouter.Minigalaxy
Traceback (most recent call last):
  File "/app/lib/python3.11/site-packages/minigalaxy/ui/gametile.py", line 121, in on_button_click
    err_msg = start_game(self.game)
              ^^^^^^^^^^^^^^^^^^^^^
  File "/app/lib/python3.11/site-packages/minigalaxy/launcher.py", line 48, in start_game
    error_message, process = run_game_subprocess(game)
                             ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/lib/python3.11/site-packages/minigalaxy/launcher.py", line 205, in run_game_subprocess
    get_execute_command(game),
    ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/lib/python3.11/site-packages/minigalaxy/launcher.py", line 65, in get_execute_command
    exe_cmd = get_windows_exe_cmd(game, files)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/lib/python3.11/site-packages/minigalaxy/launcher.py", line 142, in get_windows_exe_cmd
    filename = os.path.splitext(os.path.basename(executables[0]))[0] + '.exe'
                                                 ~~~~~~~~~~~^^^
IndexError: list index out of range

It seems like the install has worked fine though, so I think the wine prefix setup and everything works and only launching it once it's ready to go doesn't work.

Affected minigalaxy version: 1.3.0 (from flathub)

[sharkwouter]

Interesting, my guess is that there is no binary in the root directory of Unreal Gold. It is probably in a bin directory. I do have this game, maybe I can figure this one out.

[sharkwouter]

Turns out I was right, Unreal Gold has no exe files in the main directory and no config file which shows where to find the executable.

[ell1e]

minigalaxy 1.3.2 seems to try to launch some random foxit reader install inside the Unreal Gold folder now. 😆 It doesn't seem to guess the game executable correctly.

[GB609]

Have you tried a full delete + install?

Could you provide an ls of the game dir?
And also the content of the file goggame*.info?

[sharkwouter]

Yeah, Unreal Gold is hard to deal with. There is no info file, so Minigalaxy has to guess. You can delete the exe files which you don't need. I would like to offer the user a selection menu in these cases, but I haven't gotten to that yet.

[GB609]

Yeah, Unreal Gold is hard to deal with. There is no info file, so Minigalaxy has to guess. You can delete the exe files which you don't need. I would like to offer the user a selection menu in these cases, but I haven't gotten to that yet.

Is there really no info file even after we changed the installation procedure? I was partly under the impression that the generation of these files might also depend a bit on proper installation and that the tests before often used innoextract unpacking.

The idea with the selection is good as a last fallback, however. Should absolutely take care of these very last few cases we really can't do anything about.

[sharkwouter]

No, there is no info file. There is a .ink file in the main directory, maybe we could launch that.

[GB609]

That would be another possibility to consider.

[sharkwouter]

I did a quick test with this code and wine can launch lnk files, which makes Unreal Gold start: 9f394dc

[GB609]

That is good news.
But maybe we should also consider, just like with the exe files, that there might be multiple link files. And that iteration order does not guarantee to get the right one.

[sharkwouter]

Yeah, agreed. This was just a test.

[ell1e]

There are a few more games I've found that cannot be launched because it picks the wrong executable:

• Civ 3: it launches the level editor instead, which complains with some error that some file is missing and quits.

• Lands of Lore 3: it launches some nglide wrapper config tool instead, that happens to be included, from where the game cannot be launched.

• Indiana Jones and the Internal Machine: it launches some installer, that gets confused seemingly because the game is already installed.

Perhaps like for DXVK and missing dlls and such, it might be best to let people pull request some simple JSON file for games to override the executable path and subfolder, and to override additional winetricks install commands or something? I feel like that would be the most practical approach to address those issues.

[GB609]

I don't think keeping even more additional files for launch configurations is the right approach.
GOG or any game's devs could change a game's directory structure or launch arguments with every version if they wanted to. We'd never manage to keep up with this.

Plus, depending on where and how we fetch and integrate these launch commands, we're introducing a security issue as these jsons could contain any arbitrary command that has to run on the shell.

I'd rather add a dropdown in the Game properties that lists the possible variants we have:

1. playTasks from goggame*.info file
2. (if not 1) - found link files (because fewer and can also contain correct launch arguments)
3. (if not 2) - listing of executables (which requires a filter or we will add a lot of windows system executables as well)

We could then also open the property dialog on first launch when there is than one choice.

[ell1e]

It wouldn't have more security implications than any other pull request if it was a JSON file baked into minigalaxy. That would make updates take longer, but imho that would still be better than not addressing this.

Picking an executable from a list as well as not installing wine in a usable way for probably 30% of the average person's games (since e.g. the wide-spread need for DXVK is currently unaddressed) has the problem that non-technical users will check out at that point.

[GB609]

Let's suppose we implemented such a json input. It would still have to be maintained separately, otherwise game fixes would either frequently inflate the minigalaxy version or take an unspecified amount of time until the next release. At this point in time, the 'fix' contained in minigalaxy might already be outdated again because GOG pushed an update in the mean time.

Lets be honest about one thing here. The base of gamers running linux is small enough for gog to not consider implementing GOG Galaxy support on their own. And wherever you look, it is mostly 'steam' which is then mentioned everywhere (and support for proton is requested).
How many 'none-technical' users are gaming outside of 'steam' on linux? How many of those would then be none-technical?
Using windows games in linux always comes with a certain amount of tinkering, even on steam/proton. PlayOnlinux tried to fix that on their own. Lutris does. GE does.
Then there is the issue with varying wine support on different distributions. Add in the flatpak layer. Some games need certain registry settings, but maybe only in some distributions. Some of it might depend on the actual graphics driver version. All of this would have to be included as config variants or the 'it doesnt run on my pc' messages will come in the same as they do now.
There simply is no 'one-size-fits-all' big green install button that always works for everyone everywhere without any config. Even on window there isnt. Think about driver issues or support of old games with compatibility.

I'm not against taking measures to make things better there. But i personally am strongly against anything that forces us to re-implement the wheel in terms of game fixes which is already done publicly in a pooled effort somewhere else (UMU). It is not maintainable. And most of your 'none-technical' users likely wont help with that. For them, either it works or they move on. Few of them will actually help by investigating the right fixes/commands AND actually contributing them. Git requires technical knowledge as well.

[sharkwouter]

I think we can solve a lot of problems if we prioritize link files over executables and maybe do some pattern matching to exclude files with config in the name and such. I'll look into it.

[ell1e]

I don't think game fixes taking an unspecified time until the next minigalaxy release is a big problem. I doubt the amount of huge game changes invalidating past fixes that you envision to happen will happen.

Nevertheless, I can't see the future ofc and I realize that's easy to say not being currently one of the people who would need to look over the process.

Edit: regarding different wine versions, I think it would make sense to simply focus on flatpak. That would likely work with most other distributions, and where it doesn't, the user could always use the flatpak instead.

[GB609]

Edit: regarding different wine versions, I think it would make sense to simply focus on flatpak. That would likely work with most other distributions, and where it doesn't, the user could always use the flatpak instead.

That wouldn't really solve the issue. When the flatpak upgrades the wine version, all configurations which minigalaxy already has would have to be re-tested and (if necessary) updated before the release with the upgrade. That also applies to new versions of stuff like DXVK. That requires constant, repeated contributions from people that actually own the games.

[ell1e]

Sure, you're correct. I might be severely underestimating this anyway, so feel free to not be convinced. I feel bad for discussing this for so long, it's your choice in any case.

But that said, I just think things aren't going to break that often for most older games, from my own wine experience in the past. And you only need a few users to cover the common ones to give everybody a pretty good experience compared to now. For example, I have 73 games installed via minigalaxy right now of which most use wine, and I'd happily pull request the obvious things like need for DXVK. If a lot of special quirks are needed, often it's better to wait for wine to improve compatibility out of the box anyway, but I imagine that won't affect most games on GOG. In any case, my apologies for harping on about this.

[GB609]

Well. I can't decide anything. At the end its a matter of:

• Priority and
• whether @sharkwouter would accept any PR for such a feature (or go at it himself)

Right now, there's very few people working on Minigalaxy. And i think we should first improve on those areas for which the users can't reasonably apply workarounds themselves before we introduce something new that adds to the overall upkeeping workload instead. The stuff that actually keeps the users from even getting to the point of game configuration.
That is my personal priority right now. After that, i will look at improvements to launching or configuring wine games again (or using alternative runners like umu) because that was the initial reason i started contributing to MG. I want to integrate MG in my couch gaming PC, preferably without any need for a keyboard. So my goal aligns with yours at the end. I want to install and run games without any subsequent need for hacks or configurations. I just think that there is a more effective way to get there by not spending effort on our own little list, but join in on umu-db instead.
My point being: The lists you want are already there, just not within minigalaxy itself. And the joint list would be easier to maintain for all. This is not that different from the result you want at the end. Just another way to get there where we wouldn't even have to start from scratch.

I certainly agree, wine research and configuration can be tedious. It takes effort. But the users can do something there themselves for now. They can't do anything when the downloads don't work.

Edit: I'm not trying to say MG is bad or that nothing works at all. I just want to stabilize it and make it even better, so please don't misunderstand.

[sharkwouter]

I created a PR for this issue: #666