Support for game detection is limited on Linux #1900
Labels
Comments
|
I've installed Lutris and Heroic Games Launcher as Flatpak applications and had a play around with them, and here are some notes I've made: HGL
So finding games installed by HGL should be pretty straightforwards:
Lutris
So, to detect GOG games installed through Lutris:
This would need yaml-cpp to be built and linked as part of LOOT's build process so that the YAML files could be parsed. I guess detecting EGS games installed through Lutris would be similar. I don't think there's a good way to detect EGS games installed through the EGS that Lutris installs, as that happens inside Wine. You could find the Wine prefix from Lutris's game YAML file for EGS, and from there you could either interface with Wine to do the same detection that LOOT does on Windows, or you could guess the default location of the manifests (which is correct on my install), but then the manifest contains a Windows path which would need to be mapped to a Linux path: Lutris definitely seems more customisable and supports many more sources than HGL, but the UX is relatively unpolished, it seems buggier, and it's making a mess of my home directory with those symlinks. Based on my short experience, I definitely prefer HGL over Lutris for managing EGS and GOG games. Maybe I'll come back to Lutris after v0.5.14 is released. |
|
I've implemented support for detecting GOG and EGS games installed through Heroic Games Launcher in 499552e. |
|
Lutris 0.5.14 was released, so I tried it again:
SteamThe Steam integration just prompts Steam to download and install the game when you first try to play it after "installing" it through Lutris, so it'll get picked up by LOOT's existing Steam support. GOG
EGS
I wasn't able to get as far as before with GOG or EGS. The EGS issue seems to be because the install script relies on archive.org as a mirror for some files (which doesn't seem like the best idea), and from searches it seems like it can be a bit flaky. I didn't notice the DXVK error last time I tried running Oblivion, so it seems to be failing for a different reason now, but I'm not sure that's progress. |
|
Can I help providing required information? I have both TES 4 & 5 installed. |
|
@375gnu How have you installed them, and what store are they from? |
|
They both are from GOG, installed using Lutris (it itself was installed from native Debian package, not Flatpak). |
|
@375gnu Can you share your |
game:
exe: /home/redacted/Games/gog/the-elder-scrolls-iv-oblivion-game-of-the-year-edition-deluxe/drive_c/GOG
Games/Oblivion/OblivionLauncher.exe
launch_configs:
- exe: /home/redacted/Games/gog/the-elder-scrolls-iv-oblivion-game-of-the-year-edition-deluxe/drive_c/GOG
Games/Oblivion/Oblivion.exe
name: 'The Elder Scrolls IV: Oblivion'
- exe: /home/redacted/Games/gog/the-elder-scrolls-iv-oblivion-game-of-the-year-edition-deluxe/drive_c/GOG
Games/Oblivion/TESConstructionSet.exe
name: TES Construction Set
- exe: /home/redacted/Games/gog/the-elder-scrolls-iv-oblivion-game-of-the-year-edition-deluxe/drive_c/GOG
Games/Oblivion/manual.pdf
name: Manual
name: 'The Elder Scrolls IV: Oblivion'
game_slug: the-elder-scrolls-iv-oblivion-game-of-the-year-edition-deluxe
name: 'The Elder Scrolls IV: Oblivion - Game of the Year Edition Deluxe'
requires: null
script:
files:
- goginstaller: N/A:Select the installer from GOG
game:
exe: /home/redacted/Games/gog/the-elder-scrolls-iv-oblivion-game-of-the-year-edition-deluxe/drive_c/GOG
Games/Oblivion/OblivionLauncher.exe
launch_configs:
- exe: /home/redacted/Games/gog/the-elder-scrolls-iv-oblivion-game-of-the-year-edition-deluxe/drive_c/GOG
Games/Oblivion/Oblivion.exe
name: 'The Elder Scrolls IV: Oblivion'
- exe: /home/redacted/Games/gog/the-elder-scrolls-iv-oblivion-game-of-the-year-edition-deluxe/drive_c/GOG
Games/Oblivion/TESConstructionSet.exe
name: TES Construction Set
- exe: /home/redacted/Games/gog/the-elder-scrolls-iv-oblivion-game-of-the-year-edition-deluxe/drive_c/GOG
Games/Oblivion/manual.pdf
name: Manual
name: 'The Elder Scrolls IV: Oblivion'
installer:
- autosetup_gog_game: goginstaller
system: {}
wine:
version: wine-ge-8-25-x86_64
service: gog
service_id: '1458058109'
slug: elder_scrolls_iv_oblivion_game_of_the_year_edition_deluxe_the_game
system: {}
variables: {}
version: GOG
wine:
version: lutris-GE-Proton8-13-x86_64
year: nullNote that long lines are split, this is an my artifacts. |
|
@375gnu is the |
|
@Ortham yes, it's the same. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Support for detecting Steam games is being done as part of #1893, but aside from that all game installs need to be manually configured.
There are two aspects of game detection, detecting install paths and detecting local data paths.
For install paths:
.GamingRootfiles to find MS Store library locations. This could be done on Linux by scanning mount points instead. Older MS Store installs are found by looking them up in the Registry.For local data paths, all three game sources have the same problem: there's no obvious way to detect what the correct path is. It can be done for Steam because Steam provides a native Linux application that manages the local data paths, so they exist at consistent, guessable locations. GOG, MSS and EGS don't provide native game launchers / managers.
That said, there are native third-party launchers/managers that might manage games' local data paths. Those I've heard of are:
From searching around, Heroic seems to be most commonly recommended, followed by Lutris, and I saw a few mentions of Bottles. However, with Bottles being a Wine prefix manager, I don't think it would be possible to detect games installed through it, because they'd actually be installed through launchers/managers running in Wine, so you'd need to have LOOT interface with the Wine prefixes to do game detection like it does on Windows.
MSS games don't seem to be available on Linux at all (no surprise there), so I think the only way a user would end up trying to play one would be if they had a Windows drive mounted. If that's the case then LOOT could potentially look for Windows user directories on the same drive to see if any had an existing local app data path, and detection could just fail if none is found. However, if there's more than one user with such data then LOOT could end up picking the wrong path, which wouldn't necessarily be obvious to the user.
The text was updated successfully, but these errors were encountered: