Skip to content

Conversation

@sjp761
Copy link

@sjp761 sjp761 commented Jan 27, 2026

This is some partial work towards per-game wine prefixes. I also happened to implement file exclusion for both the user's benefit and to make testing easier when downloading games. Will help close #44

Included work in this PR so far

  • File Exclusion (Tested and working, download size reflects files being excluded)
  • Ability to set custom proton, custom prefix, and the ability to use Steam Linux Runtime directly (still in a unified state, configured through environmental variables, some paths are hard-coded right now)
  • Refactor GameSettings to be handled through maxima-lib (saves everything to json files in maxima's config dir, UI was updated to handle it, settings save and load correctly, this will allow accessing game settings through maxima-cli as it will need the prefix location when querying if the game is installed later on)
  • Handle Game Detection through json file with install flag (Basically a game will be detected as installed if the file exists and the installed flag inside the file is set to true (mainly as an error catcher in case that file get written when a game is uninstalled)

Example of environmental variable configuration

MAXIMA_USE_SLR=true
MAXIMA_SLR_PATH="/mnt/games/Other/Steam/steamapps/common/SteamLinuxRuntime_sniper"
MAXIMA_PROTON_PATH="/mnt/games/Other/Steam/steamapps/common/Proton - Experimental"
MAXIMA_WINE_PREFIX="/mnt/games/Other/Prefixes/Mass Effect Legendary"
MAXIMA_DISABLE_EAC=true (Still need to quickly exclude the environmental variable from being set in the UMU pathway)

@sjp761 sjp761 changed the title [DRAFT}: Rework to allow wine prefix selection for games [DRAFT]: Rework to allow wine prefix selection for games Jan 27, 2026
@wannkunstbeikor
Copy link
Collaborator

ability to use Steam Linux Runtime directly

Just curious, why would you want to do that when you can use umu? Seems like way more work.

@sjp761
Copy link
Author

sjp761 commented Jan 30, 2026

ability to use Steam Linux Runtime directly

Just curious, why would you want to do that when you can use umu? Seems like way more work.

Just something personal I added. This fork was supposed to be just my subjective improvements before I decided I'll try to add per game prefix support. I'll remove it and keep the PR focused going forward

@wannkunstbeikor
Copy link
Collaborator

I'll remove it and keep the PR focused going forward

You dont have to remove it, I was just curious why u use the runtime directly. Also I think it might be a good idea to split the pr, since then its easier to see what you did. So one pr for the exclusion, one for the settings, etc. Or do they depend on each other too much to split them?

@sjp761
Copy link
Author

sjp761 commented Jan 30, 2026

I'll remove it and keep the PR focused going forward

You dont have to remove it, I was just curious why u use the runtime directly. Also I think it might be a good idea to split the pr, since then its easier to see what you did. So one pr for the exclusion, one for the settings, etc. Or do they depend on each other too much to split them?

I can split exclusion into its own PR but any work towards separate wine prefixes and the JSON installation detection relies on the settings refactor. Moving it to the library allows easy access to the user-set wine prefix location when wine needs to be run and the cli/tui can access said settings as well when running a game

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Store installed state separately from the wine prefix

2 participants