-
Notifications
You must be signed in to change notification settings - Fork 72
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
Support UMU-Launcher #622
base: master
Are you sure you want to change the base?
Support UMU-Launcher #622
Conversation
Ok, i'll start.
I will update the following table as i go one (cant test all at once, takes too much time).
|
91a9db5
to
1794328
Compare
completely reworked wine installer to get rid of errors once and for all tested manually with 'Rise Eterna' which has a simple setup: 1. has goggame.info file 2. no workingDir adjustment 3. only one game executable Unit tests are still broken, a lot of method signatures were changed.
1794328
to
a484c4b
Compare
f284efa
to
9463ea5
Compare
Description
This code change introduces a dropdown in preference giving a choice between 'Wine' and 'UMU-Launcher' as windows game runner.
I've introduced a helper, wine_utils, to handle everything about wine: environment variables, locating the executable etc. There were quite a few other code changes/refactorings as well, partly for maintenance, partly to actually use the new utils.
I also started revising the entire install strategy for windows games as a lot of issues i can see here stem from the different ways to install and that they both seem to have issues.
I'm in favor of using the conventional install within wine over innoextract.
The main reason is that innoextract is basically just like unzip, it doesn't perform any post-file-copy steps, nor does it execute the installer scripts. This leaves the 'installations' in a potentially undefined intermediate state where a lot of additional code is needed to 'make it work'. That's why i temporarily disabled innoextract hard-coded in my branch. Therefore the system installation won't matter. The revised installer does not utilize a temporary directory (with file moving around afterwards) anymore. instead it configures the installer to use a well-known pre-defined directory within the wineprefix.
If there is a desire to still keep innoextract even when the changed installation proves to be stable, i also have a few other changes in stock to make this an option, allowing to toggle between innoextract and regular install without having to remove inno from the system.
I'm putting this up as a draft PR here already (although it is in a bit of an early stage with lots of broken tests) because i need some help. I need information about games and 'constellations':
1. Test of game installations, both with regular wine and umu
I don't own too many windows games on GOG yet and my wallet is not infinite.
I'm mostly interested in the following things:
gamedirectory/prefix/drive_c/setup.inf
. I'm currently considering whether this file contains any reliable input usable to make workingdir and executable detection easier.2. Running games
Installation should basically work for all games, since the working directories and installer executables are well known.
This does not apply when running a game, however. Even before my code changes, minigalaxy had quite some logic to try and detect the game's exe file.
There's some try to parse the goggame-*.info file (these appear to be optional), then a direct search for the first exe to found in the game's install dir (some games place their exe in a subdir like bin).
But all installers generate desktop shortcuts. It might be possible to leverage them instead.
That's why i need input on games that install, but don't launch. These are most likely not simple cases.
3. Protonfixes
Some games require winetricks etc.
The folks from UMU started to track this in a database UMU-DB
UMU-Launcher requires a variable named 'GAMEID', which can be arbitrary, but should correspond to value of UMU_ID for a game in that database (if it is there). I've implemented a lookup function and what i need to know is if it actually retrieves the right values for games with protonfixes. This requires a working internet connection. Without internet, the lookup will generate a reasonable default and try again the next time anything within that game's prefix is launched with umu.
I added a tempory dirty log statement to see the full wine launch commands on installation, including GAMEID= when umu is chosen as runner.
So, if anyone owns a game that appears in the database, under store gog, steam or none, please let me know if the value of GAMEID matches what is in that table for UMU_ID.
4. Simple case
A 'simple' case either:
5. Savegames / home pollution
This is something that i have not touched, but it is related to wine configuration.
Regular Wine normally tries to integrate windows applications as seamlessly as possible into the desktop environment. As such, it will link windows user folders like 'Documents' or 'Downloads' to those in /home/user. Depending on the game, it will start putting stuff there. I think it's arguable whether this is desired and this behavior can be changed. When this integration is disabled, the 'Documents' etc will just be regular folders nested somewhere deep within the game's wineprefix directories. The question here is, shall Minigalaxy provide a default configuration or leave it to the users to configure each and every game installation by themselves regarding that?
This is also roughly related to cloud saves or similar. But to achieve this, a uniform and well known save location is necessary which is very hard to do when running games from stone age vs brand new ones for more recent windows versions. But i'm not going on elaborating this here, since this is going off track.
The sandboxing/pollution issue might not apply the same way in UMU since it uses the isolated proton stuff.
The changes to the installer potentially impact or fix:
#618, #605, #602, #512, #506
#289 - i did an adjustment to the /VERYSILENT argument in the wine installer. I found not having any visual feedback at all during a long-running installation makes me feel impatient or that there's something wrong. So i changed the flag to /SILENT which only shows the installation progress, but no configuration options dialog. Potential candidate to go into preferences.
The wine_env configuration might fix:
#117, #313 - i have disabled the winemenubuilder in all prefixes managed by minigalaxy, so shortcuts from within wine are not automatically added to the linux desktop. Only applies on new installations. If there already are shortcuts, they need to be removed manually.
The enhancement of preferences to pick a wine variant opens up the possibility to work on:
#288
Checklist