Asset Groups
This is part of an idea that I'd posted about on the forums about a month ago. There is also hope to do something similar with plugin records, however that is somewhat more complex and at the least should be left until this has been implemented.
Premise
The idea is that we create a tree structure that contains every mesh/texture used by multiple mods (primarily the vanilla morrowind ones, but we could include others if necessary). The user can then choose which mods to use for each asset group, in a manner that is as specific (even for a single mesh/texture) or as general as they want.
E.g. For the base Morrowind assets, we break them up into groups such as:
- meshes (same structure for textures)
- morrowind
- terrain
- sky
- creatures
- flora
- trees
- npcs
- equipment
- weapons
- swords
- clothes
- weapons
- morrowind
Obviously this is incomplete, but the idea stands. In each of the leaf (lowest-level) categories, we put the corresponding assets, and each asset is considered to be part of the groups of all of its parents.
Then, when the user chooses which mod they want for a certain group, all corresponding assets are removed from all installed mods other than the one they have chosen. Note that priority should be given to more specific groups, so changing the mod you selected for equipment textures will not affect the mod used for sword textures etc. (unless you deselect the more specific group).
A major benefit of this is that it could completely remove the need for data directory sorting. Each asset, if everything is properly configured, will only be installed once.
It's also worth noting that we could use the existing install order mechanisms to provide defaults. That is, rather than requiring complete manual configuration to use this feature, we could enable it by default, and when a mod is installed it configures itself based on its tier and data overrides and the configurations from mods already installed.
This could also allow asset dependencies. That is, rather than declaring that, for example, a mesh mod is dependent on a certain mod that provides textures, we could just use the texture groups it depends on, allowing any mod that provides those textures to satisfy it. Of course, many meshes require specific textures, and there could be many vastly different versions of textures with the same name, however this would give a more general way of defining dependencies on a group of textures.
Issues
How Does the user configure their assets?
Initially, I had though of using an eselect-like interface. That is, you can say omwselect meshes/morrowind/equipment list
and it will list all the mods that provide equipment meshes. Then you can use omwselect meshes/morrowind/equipment set assets/equipment-foo
to select the mod you want. The issue with this however is that there will be a very large number of categories and most mods are fairly specific in what they implement.
It would be better to have a tree-like way of viewing possible mods, with some sort of indication that, for example, while there is no mod that completely provides meshes/morrowind/equipment
, there are a number of mods that provide some of its child groups. Unfortunately this probably means a GUI of some sort (that being said, a GUI could eventually also provide visual comparisons, which could be very useful to help the user decide).
How do we handle installation?
There are two ways we can handle tracking which groups are used by mods. Basically the ideal choice is some combination of the two, however some details need to be worked out.
At Installation
When a mod is installed, we could automatically detect which groups it contains, making note of this so that the mod shows up in the configuration tool.
A major issue here is that configuration changes could break this, so we can't guarantee that a mod will continue to provide a certain group if a use flag is changed, or a mod is updated. Additionally, the user can't install a mod specifically because it satisfies a group. You would only be able to select between installed mods.
In Pybuilds
Alternatively, we could store the group info inside each pybuild. A tool could be created to generate this information, though it will likely need manual configuration for use flags etc (could use a use-reduce-able string to store the groups provided).
This is time-consuming, however for mods that don't include asset groups we could fall back to detecting the groups at install time. In fact, it would be beneficial to also detect groups at install time to ensure that the groups listed in the pybuild are actually correct.
Notably, this would allow two different ways of configuring the installed groups. An offline way, which would only show groups provided by installed mods, and an online way, that would allow a user to see all mods in the repo that provide a particular group.