minigalaxy
minigalaxy copied to clipboard
sharkwouter
Launching some games via minigalaxy leads to various errors due to the wrong executable being launched
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)
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.
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.
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.
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?
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.
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.
No, there is no info file. There is a .ink file in the main directory, maybe we could launch that.
I did a quick test with this code and wine can launch lnk files, which makes Unreal Gold start: https://github.com/sharkwouter/minigalaxy/commit/9f394dc449acae03287bb6213e4e4fcff13df518
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.
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.
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:
- playTasks from goggame*.info file
- (if not 1) - found link files (because fewer and can also contain correct launch arguments)
- (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.
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.
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.
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.
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.
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.
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.
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.
I created a PR for this issue: https://github.com/sharkwouter/minigalaxy/pull/666
Based on the latest 1.3.2 flatpak version of minigalaxy, here are a few more common wrong executables:
Lands of Lore 3: seems to be launching either app/ngilde_config.exe or Lands of Lore 3/nglide_config.exe, should be launching Lands of Lore 3/LOL3.exe
$ ls
3DfxSpl.dll Support.ico
3DfxSpl2.dll cdcache.hdr
3DfxSpl3.dll cdcache.lst
CDCACHE.LS_ cdcache.wsx
DAT gfw_high.ico
EULA.txt glide.dll
GameuxInstallHelper.dll glide2x.dll
Keycard.pdf glide3x.dll
LAUNCHER.BMP gog.ico
LOCAL.WSX gog_lol3.sdb
LOL3.DAT goggame.dll
LOL3.EXE locallng.wsx
LOL3.LCF minigalaxy_setup_languages.log
LOLSETUP.INI nglide_config.exe
Launch Lands of Lore 3.lnk nglide_readme.txt
MP3DEC.ASI options.ini
MSS32.DLL prefix
Manual.pdf thumbnail.jpg
NOTES.ICO unins000.dat
PATCHGET.DAT unins000.exe
PATCHW32.DLL unins000.ini
PROMPT.TRR unins000.msg
SMCACHE.ICF
Quake II Original: Seems to be launching Q2Launcher.exe which seems to be correct but it seems to lack mandatory command line arguments that are likely specified in the .lnk
$ ls
3.20_Changes.txt kick
3dfxgl.dll libogg-0.dll
CTF_readme.txt libvorbis-0.dll
EULA.txt libvorbisfile-3.dll
Eraser license.txt
Extremities Help minigalaxy_setup_languages.log
GameuxInstallHelper.dll music
Launch Quake II.lnk pb2
Q2Launcher.exe prefix
Q2Launcher.ini pvrgl.dll
README - ground zero.txt q2.ico
README - reckoning.txt quake2.exe
Support.ico qwar2
action rail
arena readme.txt
baseq2 ref_gl.dll
capture ref_soft.dll
chaos rogue
ctf rover
docs thumbnail.jpg
gog.ico unins000.dat
goggame-1441704824.dll unins000.exe
goggame-1441704824.hashdb unins000.msg
goggame-1441704824.ico webcache.zip
goggame-1441704824.info winmm.dll
goglog.ini xatrix
jail
$ cat goggame-1441704824.info
{
"version" : 1,
"gameId" : "1441704824",
"rootGameId" : "1441704824",
"standalone" : true,
"dependencyGameId" : "",
"language" : "english",
"name" : "Quake II: Quad Damage",
"playTasks" : [
{
"isPrimary" : true,
"type" : "FileTask",
"path" : "Q2Launcher.exe",
"workingDir" : "",
"arguments" : "1441704824 Q2Launcher.ini"
}
],
"supportTasks" : [
{
"name" : "Support",
"type" : "URLTask",
"link" : "http://www.gog.com/en/support/quake_ii_quad_damage"
},
{
"name" : "Manual",
"type" : "FileTask",
"path" : "DOCS\\Manual.html",
"workingDir" : "DOCS"
},
{
"name" : "Readme",
"type" : "FileTask",
"path" : "DOCS\\readme.txt",
"workingDir" : "DOCS"
}
]
}
Unreal Gold: Currently launches something foxit related, perhaps ./tmp/FoxitReader.exe, should be launching Unreal Gold/System/Unreal.exe instead.
$ ls
Unreal Gold prefix tmp
app thumbnail.jpg unins000.exe
$ ls app/
GameuxInstallHelper.dll Music Textures
Help Sounds gfw_high.ico
Manual Support.ico gog.ico
Maps System gog_unreal_gold.sdb
$ ls app/System/
3DfxSpl2.dll IpDrv.u UPak.dll
ConfigLogo.bmp IpServer.int UPak.int
Core.dll IpServer.u UPak.u
Core.int MSVCRT.dll UWindow.u
Core.u Male1Skins.int Unreal.exe
D3DDrv.dll Male2Skins.int Unreal.ico
D3DDrv.int Male3Skins.int Unreal.ini
DefUser.ini Manifest.ini Unreal.int
Default.ini MeTaLDrv.dll Unreal.log
Editor.dll OpenGlDrv.dll UnrealEd.exe
Editor.int OpenGlDrv.ini UnrealEd.int
Editor.u Render.dll UnrealI.int
Engine.dll Setup.int UnrealI.u
Engine.int SkTrooperSkins.int UnrealShare.int
Engine.u SoftDrv.dll UnrealShare.u
Female1Skins.int SoftDrv.int User.ini
Female2Skins.int Startup.int WinDrv.dll
Fire.dll UBrowser.int WinDrv.int
Fire.u UBrowser.u Window.dll
Galaxy.dll UCC.exe Window.int
Galaxy.int UCC.log glide2x.dll
GlideDrv.dll UDSDemo.int goggame.dll
GlideDrv.int UDSDemo.u nglide_config.exe
IpDrv.dll UMenu.int nglide_readme.txt
IpDrv.int UMenu.u
$ ls Unreal\ Gold/
EULA.txt Music gog.ico
GameuxInstallHelper.dll Sounds gog_unreal_gold.sdb
Help Support.ico unins000.dat
Launch Unreal Gold.lnk System unins000.exe
Manual Textures unins000.ini
Maps gfw_high.ico unins000.msg
It would help with investigating this if the error message showing the wine errors actually also showed the path that was launched. It seems sometimes to be impossible to find out via trial and error what it has been trying to launch.
It would help with investigating this if the error message showing the wine errors actually also showed the path that was launched. It seems sometimes to be impossible to find out via trial and error what it has been trying to launch.
Running Minigalaxy in debug mode will print this.
flatpak --env=MG_DEBUG=1 ...
Format of the log line: Launch command for <game_name>: <command string>.
If you are going to report more issues like this, please make it a habit to also attach the respective game's goggame*.info file (if existing) and a simple ls of the game directory. This is valuable information. Minigalaxy uses this to find the right executable.
All games have a different structure which we simply don't know about if we don't own the games ourselves. And i certainly don't plan to buy all games that report errors just to get a look at their directory structure and metadata.
I added the requested info by editing above comment. For what it's worth, I'm interested in gifting games if in a particular situation that might help with debugging a pesky corner case.
Yeah, the fix from the PR is not in 1.3.2. It will be in the next release. We should think about if we're at a point yet to do another release. I feel we could use some more stability fixes. There are some issues with the gui getting stuck while installing/downloading/running games on which I cannot put my finger. Maybe we are just using too many threads at the same time.
About the threads: thats something i mentioned before. I think the idle busy loop of download threads is taking the GIL too often.
I'd also like to finish work on the download stuff first. Just 2 more points for the basic stuff:
- handling of multifile downloads
- io/install actions on the same directory must be sequenced. Either via a lock or queue to prevent multiple dlcs from starting their installations at once concurrently.
I also think we should enhance the goggame*.info parsing to read the contents of playTasks more flexibly (just requiring a primary entry and not checking for type=playTasks - this would already fix some of the games above)
Sorry about the delay these last few days. I was sick and needed a bit of a break to recover.
Your work on the downloading stuff sounds downright amazing. This sounds really great.
A lot has been done already. There's a new dedicated UI to stop, pause and restart downloads. It also shows a size estimate and even allows to change the number of parallel downloads. Plus some bug fixes. What's missing is the overall progress bar percentage fix on the game tiles (plus the improved controls there) and a few more nice-to-haves which aren't really necessary for the basic functionality. Feel free to have a look at the changelog.md on the master branch for more details of what's coming.
@ell1e
I've had a look in your detailed post above again.
The entire directory structures of Lands of Lore 2 and Lands of Lore 3 appear strange.
They both contain a game directory named after the game and a directory app. Moreover, both directories seem to contain the same files (which the game named one also having goggame.info or .lnk files)
They seem to be some kind of mixed installs between innoextract and wine.
Did you maybe install these games with an older version of minigalaxy first, then started an update installation over that afterwards with mg 1.3.2?
If you don't have any save games, would you please try to fully uninstall and reinstall them? I'd like to see if the directory structure will be correct afterwards. If yes, then the update installation might have some issue with correctly setting up the game directory name when the game directory exists already (because it is nested in itself).
If the game directories would just be what is in the sub directory named after the game, they should launch normally.