Open erri120 opened 1 year ago
Aragas
commented
1 year ago Mods are also used to distribute tools. In case of Bannerlord, we have BLSE or custom launchers. With BLSE, we could hardcode the tool in the game's project, but we'll need a way to determine whether to show a tool to the user or not, based on OS or other conditions.
This could be expanded to automatic tool discovery, but it will definitely require some kind of a metadata file distributed with the mod, much like FOMOD?
halgari
commented
1 year ago Waiting on #312
erri120
commented
1 year ago Related to #463.
MattSturgeon
commented
2 months ago I wrote up some ramblings on this topic over on discord the other day. It was rightly suggested I should be posting them here instead, so here they are, on the record.
I've tried to proofread and re-word a little, but it's late and there's a lot to go over. Apologies that it's not very well formulated, may be largely stating the obvious, and otherwise raises more questions than answers!
- A **launcher** is an app that launches games. E.g. Steam, Lutris, Heroic, GoG Galaxy, Legendary, Itch.io, etc. Technically, NM.App will be a launcher too, but to avoid confusion I won't refer to it as such. This post mainly focuses on launchers that configure and use wine/proton to run windows games. - A **modmanager** is an app like NexusMods.App, Vortex, MO2, etc. - A **runner** or **run config** is a modmanager's way of running user-facing external games and/or tools. - A **prefix** (short for `WINEPREFIX`, aka compatdata) is the windows file hierarchy, where wine mounts its `C` drive (etc). While it can be shared, it usually unique a given game/tool/config. This is probably the most "fragile" part of the wine ecosystem; a user might reset/wipe/relocate/damage a wineprefix, possibly update their config in one place, but neglect to update it in others, leading to modmanagers/runners getting _out of sync_ with launchers/stores.
I don't know how far we'll expand it. (to other launchers) But for the time being, on Linux we launch games via Steam i.e. by asking Steam to launch it. @Sewer56
In these last month, a new project called "Unified Linux Wine Game Launcher" has been created, and we might just use that: https://github.com/GloriousEggroll/ULWGL (up-to-date version: https://github.com/Open-Wine-Components) @erri120
While a game will launch and run find regardless of where you point WINEPREFIX and what wine version you use (within reason), it would soon get confusing for users if they end up with two or more WINEPREFIXs for the same game (e.g. one used by the launcher, another used by modmanager's runner). To pick an obvious example, save games from one place are likely to be missing when launching in the other.
This could be mitigated by detecting (or guessing) the WINEPREFIX used by the launcher you think is in charge of the game. Allowing the user to configure the locations manually would offer an escape hatch for edge-cases where the guess is wrong.
Anecdotally, I've noticed it is difficult to launch steam games "directly" outside of steam, unlike on windows. Even if you ignore that ideally you'd use a consistent wine version, environment, & prefix, games appear to fail steam's DRM.
I suspect this is because steam's drm-related libraries don't end up on the LD_PATH unless launched through steam, but there could be more too it than that.
This is a non-issue for GoG games, since there is no drm handshake.
Most launchers offer a CLI interface to launch a specific game. While this too has plenty of downsides (one being you have to configure/guess which launcher is in control of the game), it does mean you don't have to figure out the details of launching the game via wine/proton.
That said, it is likely you'd need to know the game's WINEPREFIX anyway so that it can be used by modding tools associated with the game, and the modmanager itself, which may need to deploy to locations in the WINEPREFIX such as %APPDATA%.
On the other hand, if the NM app took charge of proton & the prefix, that would then be out of sync if a user chose to launch the game occasionally through the launcher(steam) and occasionally through the mod manager(app). It'd also get out of sync if the prefix path is (e.g.) auto detected once, but later changed or reset on the launcher's end.
At a high level, I think there should be different classes of run config that can be selected from when writing a run config.
WINEPREFIX.We'd ideally want wine-settings to default to the same used by the game (if the game needs wine).\ For Linux-native games with win32 tools, there should be a sane default wine & prefix, installed and managed by the modmanager.
In an ideal world the run-config class would be auto-detected by the configured command's argv[0]'s mime-type:
A third class of run config might be "via
This would have launcher-specific configuration, for steam's case I think it'd mainly be the game ID to be launched.\
If a given launcher supports running arbitrary commands "as" a game, that could be useful for tools too. e.g. run xEdit as app-id 377160, with steam's proton settings for that game.
Epic
Outline
Users should be able to launch the game, as defined by the primary file, any launchers, loaders (SKSE) and modding tools through the app. Users should also be able to add and remove any executables they want, configure commandline arguments, environment variables and other settings we might expose via a UI.
Since the app is available on both Windows and Linux, we need to interop with comparability tools like WINE, and the Steam-specific fork Proton, to run Windows-only executables on Linux.
Issues
stdoutandstderrsteam://rungameid/<appId>(docs) (#152).WINEPREFIXused to run the tool in.WINEDLLOVERRIDES).steam://rungameid/<appId>(#152).Related: #854.