-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use plugins' masters to inform sorting #92
Comments
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: It's actual parent plugins are expected to be in this order: Loot currently sorts all the esp masters except AFKWeye out of order as expected by the order the town of weye was saved in. 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. |
Um further thought on what could decide is if there is more than one plugin that expects plugins to be in a certain order that the majority of them win, so if more than two have masters in a certain order then the best 2 out of 3 wins. Very doubtful this would occur more than a handful of times. Or the later loading plugin(s) win{s) as having the order of it's parents be the determinant. Either of those ... if doable ... would be a great improvement. thanks for hearing me out on this and considering this |
(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
MAST
subrecord of theTES4
header 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.
The text was updated successfully, but these errors were encountered: