search

beyond-all-reason / Beyond-All-Reason

www.beyondallreason.info
Other
1.58k stars 258 forks source link

Change Install Directory #2635

Open seedship opened 4 months ago

seedship commented 4 months ago

Description

It seems the install directory is hardcoded based on platform and cannot be changed. It would be nice if there was a dialogue to look at a different directory for install like so: image

Why?

I run a dual boot and would like to run the game on both installations without needing to copy the data directory for both installations. I would like to set both installations to point to the same install directory.

What area of the game does this feature request pertain?

Settings, Controls or Hotkeys

Other (optional)

No response

p2004a commented 4 months ago

It's possible already to change install directory

Under Windows, in the installation dialog you can select any directory you want. I recommend first backing up your settings, uninstalling and then installing again in desired location.

Under Linux, assuming AppImage, you can specify the command line argument -w /path/to/directory. To set the install location to whatever you want.

Under both systems symlinks will also just work.

Note that currently sharing the full installation between Linux and Windows won't work. For example the engine binaries are different for those operating systems and a bunch of places currently assume names of those directores. There might be also some other things like that. So, in practice you need to do selective symlinks for some of the directories you want to be shared between installations.

We don't have plans to add dynamic changing of installation location to launcher.

h0lley commented 4 months ago

applications - and especially heavy ones like games - should not assume install directories / drives without prompting the user.

I remember I had a really bad time when installing BAR for the first time where the patcher had the audacity to assume I want the game to sit in /home/holly/.local/state/Beyond All Reason/ which was very mistaken.

I solved it with a symlink after 30 mins or so of looking for a cleaner solution as I could not believe that there wasn't a proper option, which of course an obscure launch flag is not.

p2004a commented 4 months ago

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html exists defining standard locations for Linux software and we are following it. Running application with --help is also standard on Linux.

But, contributions welcome to https://github.com/beyond-all-reason/spring-launcher for AppEngine version to add such selection and storing the configuration of that selection somewhere in $XDG_CONFIG_HOME. I as current launcher maintainer don't have any plans on adding it myself but will do any review/merge/release.

h0lley commented 4 months ago

$HOME is for user-specific files as the page you linked states. user specific files are configs, cache, documents, and such pertaining to a specific user. the engine and assets of a game are arguably not user-specific as any user can use the same files.

even then though, that doesn't really matter as this is a question of user-experience. silently assuming install dirs is simply poor UX and no amount of standard specifications resolves that.

a dedicated partition is the proper way to go for things like 10 GB games, but the point is that the user must be able to decide this to their liking if the application is to be user-friendly.

"they are a Linux user so we can expect them to be familiar with the command line, checking --help of every application" is a downright user-hostile stance. modern Linux distros have desktop environments that are as or even more user-friendly than Windows, giving rise to new Linux users that never touch the command line.

this should probably be moved to the spring-launcher repo then, no?

p2004a commented 4 months ago

(closed by accident)

There is already issue for it in launcher repo https://github.com/beyond-all-reason/spring-launcher/issues/40, I'm fine keeping this one open as here is where people are more likely to run into it.

I personally disagree with your reasoning about what should and not should be in $HOME, especially given the standard and the fact that AppImage is by definition running only with user permissions. In addition, there are technical issues related to how engine etc works with splitting the installation into pure config and data files: that's why xdg state is used and not both xdg data and config dirs. That is outside of the scope of this issue though.

Again: anybody is free to contribute that feature, and it will be integrated if done in a non obtrusive way. I'm just declining to implement it myself.