Change the Linux build to produce FHS-compatible file locations

[AbortRetryFail]

Right now Parsec has to be run out of the same folder its data and configuration files exist in. There's no easy way to make a system wide package for the game, so it's unlikely it'll ever be packaged for a Linux distro's repos.

Change the Linux build system to (optionally?) compile the game so it will run with data files in appropriate places according to the FHS, and keep user data (config, binds, logs) in the user's home folder. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

[slime73]

Related: it might be good to eventually switch to using PhysicsFS. I believe there are permissions issues with the way the game requires write access to its main install location in OS X and Windows, too.

[AbortRetryFail]

Neat library. That'd make it easier to test replacing existing game assets too, right? (I assume it's got a way to resolve name conflicts when given two files with the same name)

[slime73]

Sort of - it determines which file to use in case of identical virtual paths by picking the one whose real location is first in the list (you can either prepend or append new search paths to the list.)

You can also make it use different virtual paths for different real locations, for example:

PHYSFS_mount(real_directory, "foo", true);
PHYSFS_mount(real_zipfile, "bar", true); 

assert(PHYSFS_exists("foo/myfile.txt"));
assert(PHYSFS_exists("bar/myfile.txt"));

Although that's less useful for testing/replacing existing files.

[CrazySpence]

if all the appropriate library files are installed the game should run, so really the question is where should the game search for data? ~/.openparsec and /usr/share/openparsec?

[uberlinuxguy]

I think the data files should be somewhere in /usr/ according to the standards for these things, but I wonder if slime73's suggestion is the right way to go for managing assets. Might require a re-write of the file loading routines, but possibly worth it?

[CrazySpence]

naw not worth it , unless slime got bored and did it but he has a job now so probably not

but /usr/share/ is where a lot of apps when istalled via apt or yum put their data files and ~/.program is where things usually go if user installed but if user installed I'm fine with that stuff staying in the folder to be honest, the /usr/share or /usr/locall/share would be a make install thing or if by some magical occurrence the game was put in a distros repo

[AbortRetryFail]

That's going to have to happen anyway if we ever expect this to run on 64-bit.

[tribad]

As a first step it would be of interest to get the directory from where the binary has been started. For linux I have an solution. in parallel to the binary it would be a good thing to have to library directories lib32 and lib64 where the assets files are stored. For the old files there is no simple way to detect that they are stored with 32-bit pointers/references. So storing them in the lib32 directory makes it easier. If loading failes someone put the asset files in the wrong directory. If there are any configurations to be stored they may go into an etc directory. Anything else would be to discuss if needed.