Resource Directory location/approach proposal

[Dilvish]

We've had a bit of discussion about writing/modifying files to/in the resource directory, which is generally problematic on Windows and can also be so in other OS's as well. It most frequently comes up when a user wants to modify a resource file but then finds they don't have write access to the default location. We've spoken about putting other user-modifiable files in a more standard user-directory where we know they'll normally have write access, and one possibility might be to specify a location there as the Resource Directory. The user can always do that themselves of course via the options page or a command line option, but it would be nicer if our default setup worked better for them.

I am wondering if it might be better to take an approach similar to what we do with the stringtable entries, for which we check for an entry in one location/file with a fallback check to another location/file. In this more general case, dealing with whatever resource file is in question, it would check to see if the file exists within the resource directory tree at the user-designated location (the default location for which would likely be the same as where we currently write the logs and config file), and if the file is not found there then it retrieves the file from the 'standard library' resource tree (located at its current default location), for which the user would then never need to have write access for. If they want to mod a file they could just copy that one file over to their user directory resource tree, where it is easy for them to edit.

[Geoff the Medio]

An issue to consider is replacement of all content in a file vs. adding content without affecting the existing content.

A possibility would be to have some (empty) files in the default directory that have the same names as the current content files, but with "custom" added at the start (or somewhere).

These would be included in the main content files using an include "filename" line.

Overriding the custom content files would then add content without removing default content. Overriding the main content files would replace all the default content.

[Dilvish]

A possibility would be to have some (empty) files in the default directory that have the same names as the current content files, but with "custom" added at the start (or somewhere).

I like that idea a lot, it would really facilitate organizing customizations (at least those consisting purely of additions rather than changes, but I think that's a majority). I'd suggest organizing them into a subfolder of the default directory, with the folder named perhaps "user_additions", and individual files could be named along the lines of "buildings.user.txt", "ship_parts.user.txt", etc. (the extra "." is ok these days in Windows filenames, right?). I'm just suggesting the use of "user" rather than "custom" because it's slightly more concise, but I don't have any argument with sticking with "custom" instead. There could also be a "stringtable.user.txt" file there with stringtable entries that get read in along with whatever main stringtable the user has specified.

[Geoff the Medio]

I'd suggest organizing them into a subfolder of the default directory...

That doesn't make much sense to me... the point of the default directory is that it has all the default content. A sibling directory for custom stuff might make more sense...

[Cjkjvfnby]

We've had a bit of discussion about writing/modifying files to/in the resource directory, which is generally problematic on Windows

It is bad style. And it is bad style on all systems.

What behavior you expect at uninstall? Silent delete user created content or leave some trash?

If you need palce you have setting dir.

[Dilvish]

I'd suggest organizing them into a subfolder of the default directory...

That doesn't make much sense to me... the point of the default directory is that it has all the default content. A sibling directory for custom stuff might make more sense...

Ah, so your idea of putting those same files directly into the 'default' directory makes sense to you, but my idea of organizing them together in a subfolder doesn't make much sense to you because the files, the same ones you spoke about, are not really 'default'? I'll confess I feel I must be missing something here. I thought we had always been treating that folder as simply the 'default' location for the Resource Directory and hence its name. I had not previously seen suggestions it was to be absolutely only for preset-default content, I thought that in the past we had been talking about users customizing in-place (or in an alternate resource directory they had copied everything to). My suggested alteration to your idea had seemed to me just one of increasing organization. But regardless, either way, I don't see that we need to feel 100% wed to past practice; the whole discussion is inherently one about changing our practice. It's just a matter of what seems most sensible and suitable going forward.