Add `-additionaldir` command-line option

[Jayman2000]

Pull Request Type

• [ ] GitHub Workflow changes
• [ ] Documentation or Wiki changes
• [ ] Build and Dependency changes
• [x] Runtime changes
  • [ ] Render changes
  • [ ] Audio changes
  • [ ] Input changes
  • [ ] Network changes
  • [x] Other changes

Description

This PR adds a command-line argument named -additionaldir. -additionaldir allows users to store game assets in multiple different directories. For example, if a user installs Descent 3 using a package manager, then they’ll be able to do this:

Descent3 -setdir <path-to-proprietary-assets> -additionaldir <path-to-assets-installed-by-package-manager>

Related Issues

This is related to #373, but it doesn’t implement it.

Checklist

• [x] I have tested my changes locally and verified that they work as intended.
• [x] I have documented any new or modified functionality.
• [x] I have reviewed the changes to ensure they do not introduce any unnecessary complexity or duplicate code.
• [x] I understand that by submitting this pull request, I am agreeing to license my contributions under the project's license.

Additional Comments

This PR is meant to be a first step. If it gets accpeted, then I’ll open PRs to do the following:

• Add a CMake option called DEFAULT_ADDITIONAL_DIRS. This way, package maintainers will be able to create Descent3 executables that automatically find the other files that get installed by their Descent 3 package.
• Add documentation for -additionaldir and how it compares to -setdir.
• Allow Descent 3 to load .pld files from -additionaldir directories.

[winterheart]

Hi. I'm working on cfile / ddio refactoring and some of your changes already done in my branch. I'd suggest to wait it since after that path handling and general filesystem operations will be much simpler.

Still, there some comments on general idea (as I see it, regarding to #373 and similar issues). We have read-only and writable paths. Read-only are some preconfigured on build-time paths (like /usr/share/Descent3 in Linux or values from Registry in Windows from preinstalled D3) and defined by configuration/command line options. Writable paths are paths that known to belong to current user (like $HOME/.config, $HOME/.local in Linux, and C:\users\USER\AppData in Windows). All of these paths together forms search path list, that should be searched from writable to read-only. Descent3 should use relative path notation for resource lookup, and cfile / ddio will handle all work to search and open requested file. There no current dir in search for reason. Unless we going to make "portable" mode for game, Descent3 should use proposed scheme to write user-data (cache/temp files included) to writeable paths that belongs to user. Current dir may not belong to user, so we should avoid overuse it.

[Jayman2000]

Hi. I'm working on cfile / ddio refactoring and some of your changes already done in my branch. I'd suggest to wait it since after that path handling and general filesystem operations will be much simpler.

So you’re saying that I should rebase this PR on main once your PR gets merged?

Still, there some comments on general idea (as I see it, regarding to #373 and similar issues). We have read-only and writable paths. Read-only are some preconfigured on build-time paths (like /usr/share/Descent3 in Linux or values from Registry in Windows from preinstalled D3) and defined by configuration/command line options. Writable paths are paths that known to belong to current user (like $HOME/.config, $HOME/.local in Linux, and C:\users\USER\AppData in Windows). All of these paths together forms search path list, that should be searched from writable to read-only. Descent3 should use relative path notation for resource lookup, and cfile / ddio will handle all work to search and open requested file. There no current dir in search for reason. Unless we going to make "portable" mode for game, Descent3 should use proposed scheme to write user-data (cache/temp files included) to writeable paths that belongs to user. Current dir may not belong to user, so we should avoid overuse it.

I agree. This PR implements all of what you said, except for these things:

• This PR makes it so that there’s only one writable path.
• There’s no way to specify additional/read-only paths at compile time yet. Like I mentioned before, I’ll do that in a later PR.
• This PR doesn’t add any code that looks in the Windows registry.
• At the moment, the default value for the writable directory is still the current working directory. A future PR can make it default to something else.