Welcome to The Bug Genie

Darn, all the formatting was screwed up. Sorry. Any clarifications let me know.

Hi, thanks for the detailed report. Let me start by describing the install modes we considered for Arx Libertatis under Linux:

1. System-wide install  ⇑ top

In this mode, shared read only data is loaded from /usr/share/games/arx (for data installed by package managers) or /usr/local/share/games/arx (for data installed without a package manager) or from games/arx in any $XDG_DATA_DIRS

Per-user files are stored in ~/.local/share/arx ($XDG_DATA_HOME/arx) and config in ~/.config/arx ($XDG_CONFIG_HOME/arx)

Data files are also loaded from ~/.local/share/arx to support per-user mods etc

User and config directories are automatically created if the system-wide data directory is found.

2. Per-user install  ⇑ top

For this install mode there is no system-wide data directory. Instead, all data is loaded from the user directory ~/.local/share/arx ($XDG_DATA_HOME/arx).

Config is still loaded from ($XDG_CONFIG_HOME/arx)

The config directory is created if the user directory was found.

3. Portable / not installed  ⇑ top

This mode is intended to package data and user files in one directory that can be quickly moved between systems. It is also how pre-release Arx Libertatis worked for a long time.

Here there is no system-wide data directory and both user and config directories are the current working directory.

In thus mode nothing should ever be created in $HOME as that is outside of the install.

Now to your comments...  ⇑ top

If the USER_DIR_PREFIXES/USER_DIR and CONFIG_DIR_PREFIXES/CONFIG_DIR directories are not manually pre-created then Arx does not create them itself and falls back to current working directory. Reading http://wiki.arx-libertatis.org/Data_directories I believe this due to the data directory not being found

Correct. However, if a data directory is found or specified on the command-line, both user and config directories are created automatically.

install locations may, especially with games, not always match XDG specifications.

Well, they should! Also, to be clear, the XDG Base Directory Specification does *not* specify install locations (except defaults). Instead it specifies environment variables that contain install location prefixes (amongst other things). Actual locations are covered by the Filesystem Hierarchy Standard (FHS) standard here does not mean that all distributions follow it completely, which is complete orthogonal standard and doesn't really interest arx that much - it is the responsibility of the distro to specifies the XDG variables if the defaults are not sufficient.

Arx should try creating these user directories if not present regardless of data directory not being found

Why? If the data and user directories could not be found, arx will not start due to missing data files - so why spam the user's home directory with files/dirs that won't be used (yet). After all, the user might have wanted to use an install mode that did not include those directories.

I would suggest that this be a file copy rather than a file move to support system installs by changing fs::rename to fs::copy in Application::InitConfig() in src/core/Application.cpp perhaps.

If you looked at that code you must have noticed that that move is only executed if no config file exists in the config directory, but one exists in the *user* directory, which is defined to be the user's data and should always be writable to the users. The system-wide data directory is never searched for "cfg.ini". If you want a custom system-wide cfg.ini that is copied on the first start, name it "cfg_default.ini", which is loaded from the user and system-wide data directories (in that order of preference).

The only purpose of the move is to migrate old config files as pre-release AL did not always use ~/.config

Also, that is a warning only and will not break the game - it will simply use the hardcoded default config values and save those (and any changes) to ~/.config/arx/cfg.ini later.

However then creating ~/.local/share/arx causes game to fail to run even though current working directory is still the game directory and was running previously!

Yes, this is expected. If the user directory was not found arx will fall back to use the current directory and will the load the data from there. Now that a different user directory is found (the one you created) arx has no more business looking in the CWD - consider that the CWD when launching arx from the .desktop shortcut will be '~' for most users or any random location - why should we look for data files there. What you really want is arx to find your system-wide data directory. Note that you can pass relative directories to --data-dir, so --data-dir=. will load the data files from the CWD even if a user directory is found.

I would suggest using getExecutablePath() in src/platform/Environment.cpp as possible data directory too rather than requiring --data-dir be passed.

The only scenario I can think of (in a FHS world) where the binary directory is also the data directory is the portable install mode and there the binary dir = user dir = config dir (and no system-wide data directory!) so the data will be found through the user directory.

--data-dir=/srv/games/ArxFatalis

What, why would you store game data in /srv/? Is this actually common in any distro? The FHS says /srv is for "Data for services provided by this system" and "contains site-specific data which is served by this system.". As arx is not a service and the data should not be site-specific, i don't see why this directory would be used.

Now as for possible solutions (assuming you want data to be stored in /srv):

• Use --data-dir=/srv/games/ArxFatalis

• Define XDG_DATA_DIRS, for example:

 $ export XDG_DATA_DIRS="/srv:$XDG_DATA_DIRS"

will get arx so search for /srv/games/arx as a possible system-wide data directory. Now this should really be done by any XDG-basedir-compliant distro that considers /srv to be a "directoriey relative to which data files should be searched".

• If these run-time methods of setting the data directory location are not acceptable, you can overwrite the directories at compile time.

 $ cmake .. -DDATA_DIR=/srv/games/ArxFatalis

will then cause the arx binary to use /srv/games/ArxFatalis and only /srv/games/ArxFatalis as the data directory. You should make this change clear to everyone you distribute the binary to.

Note: cmake will remember changes to these variables until you remove CMakeCache.txt

• Alternatively use

 $ cmake .. -DDATA_DIR_PREFIXES=/srv:\$XDG_DATA_DIRS

which will then cause the arx binary to consider /srv/games/arx as well as /usr/share/games/arx and /usr/local/share/games/arx as the data directory (and whatever else your distro has in XDG_DATA_DIRS). Remember to reset DATA_DIR (e.g. by removing CMakeCache.txt) if you tried the previous solution first.

Darn, all the formatting was screwed up. Sorry. Any clarifications let me know.

Signed in users can edit their descriptions / comments ;-). The next bug tracker version will support OpenID, so that should be even easier.

Regarding creating user directories, I concur as I was probably making the point against the data directory not being found. Regarding the cfg.ini copy, I understand now.

However, XDG_DATA_DIR specifications are definitely in the minority for commercial and ex-commercial game installs. The vast majority of commercial and ex-commercial games for Linux uses the executables path as the data directory, whether started via a symbolic link in bin path or a desktop entry. Whilst this can be in part related to install methods used, the real reason is often due to the sheer size of commercial games. Users create specific partitions for games that do not lie in the XDG specifications. In my example it was /srv/game but is more usually /usr/local/games. Yes, users could add this to XDG_DATA_DIRS but also consider users defining their own directory names to which games are installed such as /usr/local/games/ArxFatalis.

In a system install asking each user to define data-dir when the game could simply resolve the executable path itself is not friendly.

Perhaps I'm just old school.

What commercial games do is fine for them, but not really relevant to us as we have a completely different distribution model. For commercial games you get everything in one big package that is rarely updated, if ever. For us, the game data is also not updated as that is not in our control (although we might provide patches at some point) - however the game binary is expected to change more frequently and thus it's better to install it through the package manager - meaning it gets installed in a standard (distribution-specific) location. In this setup there is no relation between the binary location and the data location, so loading the data from the executable path (or even trying to do so) would not make much sense.

Users create specific partitions for games that do not lie in the XDG specifications. In my example it was /srv/game but is more usually /usr/local/games. Yes, users could add this to XDG_DATA_DIRS

And they should (/usr/local/games is part of the default list for XDG_DATA_DIRS). How would you install other open source games with larger data files? Why should the install locations be different just because the game is ex-commercial?

I have no problem with adding additional logic to the data directory detection algorithm to make more users happy, as long as it doesn't break existing install modes. And using the executable dir as the data dir does break at least the portable install, as the game doesn't know if the config/saves should be put in the home dir (your system install) or in the game dir (the portable install). I also realize that the portable install is probably not much more common than a custom install such as yours - maybe even less - but as far as changes go, not breaking things for existing users has priority.

My opinion is that such custom installs that don't fit in with the XDG-basedir/FHS specs is best done with a wrapper script that sets the data dir to the custom location - that is after all not too uncommon in the commercial game install you want to emulate. Something like

 #!/bin/sh
 cd "$(dirname "$(readlink -f "$0")")"
 ./arx --data-dir=.

but also consider users defining their own directory names to which games are installed such as /usr/local/games/ArxFatalis.

That is very much something worth considering. But how should the game detect this without the user having to define something? (they can already achieve this by creating a wrapper script) Looking at the executable path is just not a general solution, especially considering how AL is normally meant to be installed.

One option would be to pre-define a list and then use the first one found (e.g 'arx:ArxLibertatis:ArxFatalis') but there will surely be someone this does not cover.

Again, may be this is better covered with a wrapper script.

Using a wrapper script is common for games (and I've done so for Arx Libertis) but, as previously mentioned, since there is already getExecutablePath() in src/platform/Environment.cpp it could be reused obviating the need for any wrapper script. Regardless of your decision, thanks for the port again.

Git master now always uses/creates ~/.local/share/arx and ~/.config/arx unless told not to do so on the command-line.

Also, more directories are now considered for data dirs: - $XDG_DATA_DIRS/games/arx - $XDG_DATA_DIRS/arx - /opt/games/arx - /opt/arx - executable path

The issue was updated with the following change(s):

• This issue has been closed
• The status has been updated, from New to Fixed.
• The resolution has been updated, from Not determined to RESOLVED.
• This issue's progression has been updated to 100 percent completed.