Psymon-Prime
commented
1 year ago Hey great suggestion :)
so um if you want an esp to test the above potential of a problem with masters that have masters that don't agree. Well the only mod I know of that has this issue where no matter how you sort the masters they will be out of order according to how they were saved by the master is a mod called the Town of Weye.
It is like one of those consolidation mods like Mhahn123 makes and has as it's masters these mods: Region Revive Lake Rumare (I used the updated version linked). AFK_Weye MTCExpandedVillages (all required mods are linked on the town of weye nexus page the only difference is I use the updated region revive).
It's actual parent plugins are expected to be in this order: Oblivion.esm Cobl.esm Region Revive - Lake Rumare.esp MTCExpandedVillages.esp AFKWeye.esp Rumare-AFK_Weye Patch.esp AFKWeye_MTC_RRLRumarePatch.esp
Loot currently sorts all the esp masters except AFKWeye out of order as expected by the order the town of weye was saved in. Now the plugin AFKWeye_MTC_RRLRumarePatch.esp expects it's parents to be in this order: MTCExpandedVillages.esp Region Revive - Lake Rumare.esp
So if I hand sort by this plugin then it puts the plugins in a contradictory order from what Town of Weye expects. I imagine then that the overlap rules would be as good as any for which gets priority unless specific reasons come up. I sorted them based on what town of weye wants.
I'm old school. I don't care what testing people have done with plugins being sorted in and out of order. To me it is ideal to have as many if not ALL plugins sorted in wrye bash so that it is all green. That is what mod authors, whom I'm more likely to go to for problems not related to wrye bash. And it is highly annoying for both them and me to try and explain ... 'well some people I don't know did some tests and they determined it doesn't matter, so that is why they aren't in the order you recommend mr/ms mod author.' You guys may not hear the resentment that can generate, but I have. They get touchy and understandably so when a tool meant to sort plugins is fundamentally changing their recommended load orders etc.
The good news is this is the ONLY mod I've found with this issue. Not saying there aren't others, but since returning to Oblivion 3-4 months ago and have been testing and mapping 100s of mods. that is the only one that I've found with that kind of issue.
I may re-edit this post if my links aren't thorough.
(This is a separate issue from #47 despite the similar title, hence the rename.)
This was requested by @Psymon-Prime in a PM. Plugins have a list of masters in the
MASTsubrecord of theTES4header record that is used by the game to map form IDs to the master that they're from. The order of these masters has no impact on gameplay, but it does indicate what order they were in when the plugin was created in the CK/CS/GECK, or in third-party programs like xEdit. This doesn't tell us anything useful for mods that only have vanilla masters as masters (other than that the author might've had them in the wrong order) or that only have vanilla masters & another mod, but it could be useful for mods that have multiple other mods as masters. For instance, the author of a patch between two mods might expect the two mods to be sorted in a specific order to allow one mod to win conflicts that aren't covered in the patch. Not all patches are built in a manner agnostic to load order (i.e., such that all conflicts are resolved within the patch itself), so this list of masters could be used to inform how we sort mods patched in this way. We often do this when manually reviewing patches, but I imagine that it could also be done automatically.For the implementation, I think we should make this a soft rule with less priority than group rules but more priority than overlap rules. If two plugins are being patched, it should be safe to assume that the patch's author has used their judgement to sufficiently maximize the impact of the patched plugins & that we should defer to their judgement (or our own via hard or group rules if absolutely necessary) rather than LOOT's algorithm for overlap rules.
One problem I can see with this mechanism is the possibility for the same plugins to appear in the master lists of multiple other plugins but in different orders relative to each other. In such a case, if these rules aren't already overridden by higher priority ones, we should probably either fall back to overlap & then tiebreak rules or prioritize the master list of the later-loading plugin. The latter would obviously complicate sorting as we'd need to know where those plugins with the master lists that we're looking at are sorted relative to each other in the middle of a sort operation, so the former should be sufficient.