search

Nexus-Mods / Vortex

Vortex Development
GNU General Public License v3.0
905 stars 131 forks source link

Enhance Vortex's submodule instruction to support multi-component/mod archives #7436

Open IDCs opened 4 years ago

IDCs commented 4 years ago

Currently Vortex cannot support archives containing multiple components/mods unless a singular custom installer is able to distinguish between all components/mods and correctly install these without requiring separate folders/mod entries for each component/mod. So for example games like Blade and Sorcery which use a prefix based load ordering system require a separate mod entry for each component in order for Vortex to be able to assign the prefix correctly whilst also ensuring the game manages to load the mods.

In order to achieve this, the submodule installer instruction could be enhanced to automatically create new mod entries for each submodule (if applicable) whilst also maintaining a bond between the submodules and original mod so that any action made to the original mod is also applied to the submodules (remove/update/etc)

Alternatively, we could simply wait until our mod pack system is released which would allow active mod authors to modify their mod packages and have them work that way - but unfortunately any existing mod archives which act as mod packs where the mod author is no longer active in the community will remain unsupported.

agc93 commented 4 years ago

As part of this, any chance that the submodule instruction will get some documentation? I'm almost certain that at least one of my extensions could work better using submodule rather than just plain copy but I can't find any docs/tsdoc/examples/samples of using it correctly.

IDCs commented 4 years ago

Sure thing - we will make sure to fully document the submodule instruction once we've enhanced it.

TanninOne commented 4 years ago

Right now the instruction would look like this: { type: 'submodule', key: mod id for the submodule, submoduleType: mod type for the submodule, path: path of the sub-archive, }

where submoduleType is optional.

What this does is it just opens the archive specified in filePath and runs the installer on that, however with a few limitations which is what this issue is about: a) The submodule is installed to the same directory as the parent module b) No pre- or postprocessing is done on the submodule, so it can't have modid/fileid for example that would then set meta information on it or dependency resolution or anything.

submodule as it currently stands is intended for one mod that contains multiple components, not for a bundle containing multiple mods.