This change makes the auto-installer generate absolute paths for the working_dir, just as it does for the "exe".
In my testing they are both relative to the gog_game_path, so this causes a correct config to be generated.
My previous hackjob remains so that existing configurations woth bad working directories can still work.
We're getting bogus paths in the launch_config options from GOG auto-generated
installers. They have backslashes (boo!) and the "exe" entry is a partial path
that is relative to the *games* working directory, but launch_config may have
its own. Use both together and it all falls apart.
This PR adds logic to fix Windows paths for the WINE runner only, replacing
\ with / and fixing casing.
It also detects when the "exe" is present relative to the game's directory but
not the configs, and generates a new "exe" relative to the config's working
directory if it can.
Resolves#4662
- Adds a new GitHub workflow that triggers on published releases.
- Adds a supporting Bash script to facilitate the building and signing process.
- Adds a new directive to the Makefile for passing a GPG key id to the make process through environment variables.
After closing a game a TypeError `can only concatenate str (not "float") to str` was raised on uninitialized playtime.
This fix just forces playtime to be loaded as float instead of string.
Do migration early if any command line options are present, but do it in the
init dialog if that is shown.
This may result in migration being run twice, but the second time does nothing.
The advantage is that in normal startup (non CLI) scenarios, migration (whcih can take some time) runs while the init dialog is up
Resolves#4646
This way the linux runner can apply it's 'exe' setting without any prefixing
command like WINE has. This makes launch-configs work for the linux runner.
Also, launch_configs can now outright specify a command key to override
the normal command building stuff.
Resolves#4637
We have to update the PATH and set the working directory so we can find
zenity, and it can find its data file.
This will only work if winetricks has zenity in it; there's a separate PR for that.
Resolves#4231
We should be able to use WINE without Proton even if Steam is b0rked.
This commit will cause Lutris to see no Proton locations at all if the Steam
config is unreadable.
Steam corruption shouldn't prevent Lutris from working outside of Steam support.
This PR logs the errors, but continues. Steam functionality
may not work, but everything else will.
