darkbasic wrote: ↑03 Feb 2021, 10:59
If we're going to use archives then we will need some way to tell openmw "please discard those files inside the archive" to achieve the same effect.
Portmod could always re-compress mods into archives at installation, allowing them to still be modified when installing. Perhaps more importantly, portmod could repackage mods which aren't using this format so that they are all installed this way.
darkbasic wrote: ↑03 Feb 2021, 11:14
By the way I personally think that archives are a thing of the past: it should be the job of the file system to transparently compress data.
This is the way a modern package manager handles compression while never using archives:
https://www.phoronix.com/scan.php?page= ... -Fedora-34
Isn't this more about removing the costly unpacking step? They're still using archives, they're just bridging the archive and the filesystem to make installation faster. Even so, good luck getting Windows to support this sort of thing (while I recall there is a btrfs driver for Windows, I don't imagine we can rely on the presence of a btrfs filesystem).
psi29a wrote: ↑03 Feb 2021, 10:23
Could portmod devs be convinced to to roll an openmw compatible 'pack'? I mean, a zip archive is better than many loose files, or even better... since openmw supports it, lz4 archive? Plain text meta-data op front to make it easily parse-able, then the content in lz4.
When you say roll, do you mean design, or use an existing one? I see that openmw supports lz4 compressed bsas, but I'm not aware of any good cli-friendly tools to create them (or even uncompressed BSAs for that matter). Plus, does openmw support plugins inside of archives? With both of those things, it would be pretty easy to have portmod install each package as a single compressed BSA.
In terms of other archive formats, it would certainly be easy to create zip archives, but I'm not actually aware of any archive formats, save for the lz4-compressed bsas, that use per-file lz4 encoding. You might be stuck with something like tar.lz4, where you'd have to uncompress the whole thing to access any files, and I don't imagine that's helpful, particularly for large archives.
With all the talk of single-archive mods and supporting the configuration options many mods offer, It seems to me like two different formats are needed, one which includes installation, and one which is the installed format. For simple mods without options they could be the same, but if you want arbitrary configuration (the complex examples I usually look at being omwllf generating its plugin and project atlas generating textures) there needs to be an intermediate stage. "Context aware activation" can only go so far.
That being said, I think openmw's plugin format could go a lot further in terms of context aware activation. Admittedly I'm mostly thinking about KSP's programmable plugins here, but even with a more restricted format it might be possible to have plugins which can change their behaviour depending on which other plugins are loaded (and maybe there could be some way of linking other assets to the plugins such that the plugin can tell the engine to ignore them or not). Basically, instead of the current method of installation, where you have a bunch of different versions, or optional subdirectories, you could have that be a single plugin, and a single set of assets, which change how they are loaded based on a settings file (for purely optional options) and their environment (i.e. other plugins and their settings). Between this simple type of configuration, and mods which don't need configuration, I think it would be feasible to support a data format which could be installed without modification for virtually all mods (again, this wouldn't help for mods which generate content, but those are in the extreme minority).
Of course there's a trade-off here between the current complex installation and making loading mods more complex. There's going to be complexity somewhere, and there's certainly an argument towards doing as little as possible at runtime so that openmw loads quickly, since you'll hopefully launch openmw many more times than you'll install mods. I think this could be restricted though so that it has a limited impact on performance: e.g. if all it supports are conditional records, then everything could still be loaded in a single linear pass (unfortunately it's at least a little more complicated than that, as there would need to be some way of having records in a plugin override plugins loaded later, but a mechanism for that could even eventually remove the need for a pre-defined load order (which would also be complicated)).