Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Linux: use XDG directories #373

Open
twolife opened this issue May 20, 2024 · 7 comments · May be fixed by #628
Open

[Feature Request] Linux: use XDG directories #373

twolife opened this issue May 20, 2024 · 7 comments · May be fixed by #628
Labels
request Request for a feature
Milestone

Comments

@twolife
Copy link

twolife commented May 20, 2024

Hi,
Currently, the configfile on linux is saved in $XDG_DATA_HOME/Outrage Entertainment/Descent 3/ (as returned by SDL_GetPrefPath()), that's cool !

In addition to that, it would be nice if:

Thanks!

@JeodC JeodC added the request Request for a feature label May 20, 2024
@JeodC
Copy link
Collaborator

JeodC commented May 20, 2024

Hi there!

As outlined by #282 and #326, the eventual goal is to confine everything to the game folder itself. Personally I fail to see an argument for keeping Registry (in windows) and XDG (in Linux) when we can consolidate it all and reduce overhead by aligning all platforms to use the same process. I'll expand on this reasoning:

Regarding screenshots, I would like to allow the user to define where they're saved. As for the pilot files, that logic is performed in pilot.cpp where the variable Base_directory is searched for any *.plt files. The temp directory (custom/cache) is also io'd based on that variable, so in the end it would be more effort than it's worth to change it for a specific platform (whereas Windows would have to use the Documents/ library folder).

@twolife
Copy link
Author

twolife commented May 20, 2024

I completely see your point to reduce maintenance overhead.
But let me explain why I see value in splitting write() operations to the user directory and leaving the rest of the commercial game data elsewhere (in a readonly directory):

  • the game engine, GPL3 code, could be packaged by a linux distribution (the binary would be installed as /usr/games/descent3)
  • the non-free game data could by installed by the user with something like g-d-p https://wiki.debian.org/Games/GameDataPackager in /usr/share/games/descent3 (this is not hypothetical, I wrote the descent3 support to g-d-p some months ago, targeting the old Loki port from 2000)

If everything is confined in the game folder, that "workflow" dies

@Jayman2000
Copy link
Contributor

Jayman2000 commented May 20, 2024

But let me explain why I see value in splitting write() operations to the user directory and leaving the rest of the commercial game data elsewhere (in a readonly directory):

  • the game engine, GPL3 code, could be packaged by a linux distribution (the binary would be installed as /usr/games/descent3)

  • the non-free game data could by installed by the user with something like g-d-p https://wiki.debian.org/Games/GameDataPackager in /usr/share/games/descent3 (this is not hypothetical, I wrote the descent3 support to g-d-p some months ago, targeting the old Loki port from 2000)

If everything is confined in the game folder, that "workflow" dies

I’m actually working on a PR that would make that workflow possible. Specifically, my PR is going to add a command-line option called --additionaldir. It will allow you to do something like this:

Descent3 --setdir <path-to-writable-dir> --additionaldir <path-to-nonfree-game-data> --additionaldir <path-to-free-game-data>

If you want to take a look at what I have so far, then you can check out the additionaldir-arg-5 branch in my fork this PR.

@chewi
Copy link

chewi commented May 31, 2024

I would package this game for Gentoo Linux, but supporting XDG directories is critical for that.

@ErikMcClure
Copy link

Hi there!

As outlined by #282 and #326, the eventual goal is to confine everything to the game folder itself. Personally I fail to see an argument for keeping Registry (in windows) and XDG (in Linux) when we can consolidate it all and reduce overhead by aligning all platforms to use the same process. I'll expand on this reasoning:

Regarding screenshots, I would like to allow the user to define where they're saved. As for the pilot files, that logic is performed in pilot.cpp where the variable Base_directory is searched for any *.plt files. The temp directory (custom/cache) is also io'd based on that variable, so in the end it would be more effort than it's worth to change it for a specific platform (whereas Windows would have to use the Documents/ library folder).

Trying to write to the game folder will not work on linux distros that make the app directory immutable, like NixOS. In fact, this can also be the case on Windows, depending on where you install the game! In some locations, you might have to give the game admin permissions to let it write to it's own directory. This is actually why many auto-updating apps now install to %APPDATA% on windows (like Chrome or Firefox), so they can update themselves without needing elevated permissions.

Unfortunately, this means making everything behave the same on all OSes simply isn't possible if you want it to actually work properly. However, you can still avoid using things like the windows registry simply by storing a config file in an appropriate place. You could simplify the code a lot by simply putting the config, screenshots and everything else in a single directory, like %APPDATA%/Descent 3 on windows, and some folder determined by XDG on Linux, then the only platform specific code necessary is getting the writable folder location. So long as this writable folder isn't the actual game folder itself, everything should work on Windows and all Linux distros. If you want screenshot location to be configurable, you could just default to the config directory at first.

@MaddTheSane
Copy link
Contributor

SDL2 has a function that can get a user-writable directory for saving save data/preferences. It's SDL_GetPrefPath.

@Lgt2x
Copy link
Member

Lgt2x commented Jun 18, 2024

That function is already used in the loki_utils utility https://github.com/DescentDevelopers/Descent3/blob/main/Descent3/loki_utils.c#L187

Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Jun 27, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Jun 29, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Jun 29, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Jun 29, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
@Lgt2x Lgt2x added this to the 1.6 milestone Aug 14, 2024
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Aug 19, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>

TODO: Why am I getting uninitialized memory access on Windows?
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Aug 20, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Aug 20, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Aug 20, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Aug 20, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Aug 22, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Sep 12, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>

TODO:
• Test on Windows.
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Sep 12, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

Or, if the user is loading a mod that replaces .hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Sep 22, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to load a mod that replaces
.hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Sep 22, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to load a mod that replaces
.hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Sep 22, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to load a mod that replaces
.hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Sep 29, 2024
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.

Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.

The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:

  Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:

  Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>

The -additionaldir option can also be used to load a mod that replaces
.hog files:

  Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>

[1]: <DescentDevelopers#373 (comment)>
@winterheart winterheart linked a pull request Oct 8, 2024 that will close this issue
13 tasks
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Dec 29, 2024
The main motivation behind this change is to make it easier to package
Descent 3 for Linux. For example, let’s say that you’re packaging
Descent 3 for Debian and you want to make the package work well with
Debian’s game-data-packager. The package for the Descent 3 engine will
put d3-linux.hog in one directory, and the package for the proprietary
Descent 3 game data will put d3.hog into a different directory. The
Descent 3 engine package can use the DEFAULT_ADDITIONAL_DIRS CMake
option in order to make sure that both d3-linux.hog and d3.hog are
located automatically.

For the example value in USAGE.md, I decided to use Windows paths in
order to showcase the fact that you have to escape backslashes.

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Dec 29, 2024
The main motivation behind this change is to make it easier to package
Descent 3 for Linux. For example, let’s say that you’re packaging
Descent 3 for Debian and you want to make the package work well with
Debian’s game-data-packager. The package for the Descent 3 engine will
put d3-linux.hog in one directory, and the package for the proprietary
Descent 3 game data will put d3.hog into a different directory [1]. The
Descent 3 engine package can use the DEFAULT_ADDITIONAL_DIRS CMake
option in order to make sure that both d3-linux.hog and d3.hog are
located automatically.

For the example value in USAGE.md, I decided to use Windows paths in
order to showcase the fact that you have to escape backslashes.

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Jan 1, 2025
The main motivation behind this change is to make it easier to package
Descent 3 for Linux. For example, let’s say that you’re packaging
Descent 3 for Debian and you want to make the package work well with
Debian’s game-data-packager. The package for the Descent 3 engine will
put d3-linux.hog in one directory, and the package for the proprietary
Descent 3 game data will put d3.hog into a different directory [1]. The
Descent 3 engine package can use the DEFAULT_ADDITIONAL_DIRS CMake
option in order to make sure that both d3-linux.hog and d3.hog are
located automatically.

For the example value in USAGE.md, I decided to use Windows paths in
order to showcase the fact that you have to escape backslashes.

[1]: <DescentDevelopers#373 (comment)>
Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this issue Jan 3, 2025
The main motivation behind this change is to make it easier to package
Descent 3 for Linux. For example, let’s say that you’re packaging
Descent 3 for Debian and you want to make the package work well with
Debian’s game-data-packager. The package for the Descent 3 engine will
put d3-linux.hog in one directory, and the package for the proprietary
Descent 3 game data will put d3.hog into a different directory [1]. The
Descent 3 engine package can use the DEFAULT_ADDITIONAL_DIRS CMake
option in order to make sure that both d3-linux.hog and d3.hog are
located automatically.

For the example value in USAGE.md, I decided to use Windows paths in
order to showcase the fact that you have to escape backslashes.

[1]: <DescentDevelopers#373 (comment)>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request Request for a feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants