Better handling of mod conflicts and mod merging
Posted: 01 Feb 2019, 05:49
I know this has been a bit of a contentious topic in the past, and the OpenMW generally doesn't want to be responsible for things like merging leveled lists (as this would lock users into using OpenMW's specific merging method), but I was thinking about some ways that this could be improved.
Disclaimer: I haven't modded Morrowind in quite some time, so I'm going based off of my memories of modding. It's possible that some of what I'm about to suggest may have already been implemented.
The way things currently work is that you have your .esm/.openmwgame file that determines the "default" values of all the records in the game. Then you have a mod's .esp/.openmwaddon file that modifies those default values. As long as two mods don't modify the same record, then those mods are compatible. If two mods modify the same record, however, the game can't use both, and whichever one loads last is the one that gets used.
Example: If one mod gives a merchant more gold, and another mod adds new items to their stock, they are incompatible because they both modify the merchant. Even though we, as humans, can see that there isn't actually a conflict, and the two mods could be merged together just fine, all the game sees is that the merchant has been modified twice, so it can only use one of the modifications.
So first of all, what I'd like to see is moving things down to the next layer. Yes, the merchant has been modified, but what aspects of the merchant have been modified? The merchant's gold and inventory are two separate fields, each of which can be marked separately as modified or not. Thus, when the game loads the two mods, it sees that yes, the merchant has been modified by both, but one is modifying one field and the other is modifying a different field. Thus, no conflict, and the game can run both mods at the same time.
But wait, we can go deeper. What about two different mods that add (or remove) items from a merchant's stock? Again, we as humans can understand that two different mods that both add items to a merchant should be able to get along just fine. So what can we do here? My proposal is to not only mark specific fields that are modified, but also record what that modification is.
Let's say, for example, that a merchant has a default gold of 500. You make a mod that gives him 1000. Rather than the mod just giving him 1000 gold, it actually just adds +500 to his default gold. If the .esm/.openmwgame is later changed to increase his default gold to 1000, then with your mod he now has 1500. If someone else makes a mod that increases his gold from 500 to 2000, it would register as +1500, and thus, with the modified default of 1000, plus your mod for +500, plus the other person's mod for +1500, the merchant now has 3000 gold.
Actually, let's have, say, three different types of modifications:
Absolute - Works the way it currently does. Whatever you modify this field to, it is set in stone that way, regardless of any changes to the .esm/.openmwgame or any mods that loaded before this one. Mods that load after this one can still modify this field.
Additive - How I proposed above. If you add an item to a merchant's inventory, that modification is recorded as +1 of that item, and will successfully merge with other additive mods. It will also merge with absolute mods if the additive mod loads after.
Multiplicative - A bit of an odd twist on the above. This would let you, say, double or half a value, regardless of what that value might be changed to by another mod. The order of operations would be the same as the load order: if an additive mod loads first, it will add to the default value, then get multiplied, but if the multiplicative mod loads first, then it will multiply first, then add.
Another option that just occurred to me would be to be able to tag additive (or multiplicative) mods to ignore redundancies. Meaning, if two mods add the same item to a merchant, but one is marked to ignore redundancies, then only one of that item gets added.
As for leveled lists, my understanding is that most mods for leveled lists either add something to the list or take something away. Thus, using additive (possibly with ignore redundancies) would allow leveled lists to be merged without issue. This also shifts the burden of determining how to merge a leveled list, or other mod, away from the player, and away from OpenMW, and onto the creator of the mod in question.
Another nice things about this is that this would only be possible for brand new mods created with OpenMW, and thus we don't have to worry about how it will affect any existing mods. Anything with an .esp extension can just use the old method, but new mods could specify how they wanted to merge their changes.
Thoughts?
Disclaimer: I haven't modded Morrowind in quite some time, so I'm going based off of my memories of modding. It's possible that some of what I'm about to suggest may have already been implemented.
The way things currently work is that you have your .esm/.openmwgame file that determines the "default" values of all the records in the game. Then you have a mod's .esp/.openmwaddon file that modifies those default values. As long as two mods don't modify the same record, then those mods are compatible. If two mods modify the same record, however, the game can't use both, and whichever one loads last is the one that gets used.
Example: If one mod gives a merchant more gold, and another mod adds new items to their stock, they are incompatible because they both modify the merchant. Even though we, as humans, can see that there isn't actually a conflict, and the two mods could be merged together just fine, all the game sees is that the merchant has been modified twice, so it can only use one of the modifications.
So first of all, what I'd like to see is moving things down to the next layer. Yes, the merchant has been modified, but what aspects of the merchant have been modified? The merchant's gold and inventory are two separate fields, each of which can be marked separately as modified or not. Thus, when the game loads the two mods, it sees that yes, the merchant has been modified by both, but one is modifying one field and the other is modifying a different field. Thus, no conflict, and the game can run both mods at the same time.
But wait, we can go deeper. What about two different mods that add (or remove) items from a merchant's stock? Again, we as humans can understand that two different mods that both add items to a merchant should be able to get along just fine. So what can we do here? My proposal is to not only mark specific fields that are modified, but also record what that modification is.
Let's say, for example, that a merchant has a default gold of 500. You make a mod that gives him 1000. Rather than the mod just giving him 1000 gold, it actually just adds +500 to his default gold. If the .esm/.openmwgame is later changed to increase his default gold to 1000, then with your mod he now has 1500. If someone else makes a mod that increases his gold from 500 to 2000, it would register as +1500, and thus, with the modified default of 1000, plus your mod for +500, plus the other person's mod for +1500, the merchant now has 3000 gold.
Actually, let's have, say, three different types of modifications:
Absolute - Works the way it currently does. Whatever you modify this field to, it is set in stone that way, regardless of any changes to the .esm/.openmwgame or any mods that loaded before this one. Mods that load after this one can still modify this field.
Additive - How I proposed above. If you add an item to a merchant's inventory, that modification is recorded as +1 of that item, and will successfully merge with other additive mods. It will also merge with absolute mods if the additive mod loads after.
Multiplicative - A bit of an odd twist on the above. This would let you, say, double or half a value, regardless of what that value might be changed to by another mod. The order of operations would be the same as the load order: if an additive mod loads first, it will add to the default value, then get multiplied, but if the multiplicative mod loads first, then it will multiply first, then add.
Another option that just occurred to me would be to be able to tag additive (or multiplicative) mods to ignore redundancies. Meaning, if two mods add the same item to a merchant, but one is marked to ignore redundancies, then only one of that item gets added.
As for leveled lists, my understanding is that most mods for leveled lists either add something to the list or take something away. Thus, using additive (possibly with ignore redundancies) would allow leveled lists to be merged without issue. This also shifts the burden of determining how to merge a leveled list, or other mod, away from the player, and away from OpenMW, and onto the creator of the mod in question.
Another nice things about this is that this would only be possible for brand new mods created with OpenMW, and thus we don't have to worry about how it will affect any existing mods. Anything with an .esp extension can just use the old method, but new mods could specify how they wanted to merge their changes.
Thoughts?