Sort plugins closer to their masters #47
Comments
|
Additional note: IF it is decided that this idea would only generally be applied to mods with 2 or more masters - in other words, just compatibility patches - then I would suggest that the only masters that should be ignored when counting masters to determine if a plugin is a patch are the vanilla masters. Even USSEP should be counted to determine if a mod is a patch in that circumstance. It's possible that a mod might have dependency on USSEP and have another master and not be a patch, but I think those would be significantly rarer than actual patches for USSEP (I publish over a dozen myself). and I still wouldn't see the harm in applying this ordering logic to those few instances anyway. |
|
For reference this is the sorting for a large load order with the current masterlist Click to view picture--- |
|
Some initial thoughts on this: Trying to load plugins as close as possible to their masters seems like a generally good idea, it's a more specific expression of the "load plugins as early as possible" idea. There are plenty of exceptions, e.g. map mods, but LOOT already handles such cases through groups and load after metadata. I'm not sure why this idea would need to exclude ESMs or a subset of them. Could you elaborate? I'd prefer a solution that doesn't require special-casing. I don't think it's useful to try to distinguish patches from other plugins based on the number of masters they have: I've come across plenty of patches with only one non-official master (even a few with none) and plenty of non-patches with more than one non-official master. I can see some utility in treating patches differently, but I doubt the identification heuristic would be accurate enough to be worth it. As for methodology: how do you see the close-to-masters constraint fitting in with the existing constraints, i.e. which should it take priority over, which should override it, which does it sit equally with? See https://loot-api.readthedocs.io/en/latest/api/sorting.html for an overview of the current process, if that helps. That's all for now, because I have bugs to fix. |
|
Well, I don't see any point in counting the official masters, given that all mods can have all of them or just Skyrim.esm, and how many they have doesn't seem relevant to where they should be loaded. USSEP is also a mod that lots and lots of other mods can have as a dependency that doesn't seem relevant to positioning. Let's say RW2 had it as a dependency just because it used some fixed asset in it... would that mean it should load higher? I don't think so. I see USSEP as pretty much an extension of the vanilla masters for these purposes... just as I would see YUP as an extension of the official FNV masters. The idea of excluding all ESMs was in fact just a way to see if the above could be accomplished without special-casing. If there's general agreement that this should work for all other masters and there's no reason to treat patches differently, which I agree with, I don't see a point in arguing for the idea of using number of masters to identify them. As for the constraints, specific mod A must come after some other mod B rules should definitely take precedence... and late loading group is pretty important... but beyond that I can't see any other group constraint that seems more important. |
|
Actually, it just occurred to me - I may have WAY overthought the methodology. Presuming LOOT is already smart enough to not place a plugin above its master, and I believe it already is.... can't we get the entire desired behavior by just treating any plugin with a non-vanilla (and maybe non-fixpack) master as an Early Loader? |
sibir-ine
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Proposal: Any mod that has a non-ESM master should be placed as close to it's master as possible.
Reasoning: There are several advantages to this. When it comes to patches, I have detailed why proper patch placement is immediately after the last of its masters here, with an example of how not placing them that way can cause errors: https://www.nexusmods.com/skyrimspecialedition/articles/625
I initially thought to request this only for conflict resolution patches, and identify those as mods with two or more non-vanilla masters, but it occurs to me that the principle holds even for non-patch mods that have only a single non-vanilla, non USSEP master. Take a mod like Enhanced Blood Textures. If you choose all the options in the installer, you'll get a host of sub-plugins (like "no screen blood"), all of which have a main EBT plugin as a master. Currently, LOOT will litter these sub-plugins all over the list, which is terrible from an organizational perspective, makes it impossible to synchronize installation and plugin order, and leads to possible conflicts with intervening mods that change the same record being overridden by a sub-plugin of EBT but not EBT itself. With my proposal, all the EBT plugins will be grouped together nice and neatly in the plugin list, which wouldn't just prevent conflicts, it would also just look better and be easier to review and adjust their position all together as a single unit, since they really should be considered and treated as such.
Or take ACE (Armor and Clothing Extension), which has one master, WACCF (Weapons, Armor, Clothing and Clutter Fixes). The author - any author really - would certainly design these with the assumption that ACE would immediately overwrite WACCF in every shared record. An intervening mod C between the two that shared a record with them would be only partially overwritten by ACE, while possibly also partially overwriting WACCF in some other regard. This can only cause havoc. With ACE naturally placed immediately after WACCF, the combination will be either wholly overwritten by Mod C, or Mod C will wholly ovewrite WACCF+ACE, but there should generally exist no good circumstance in which any mod (other than patches for WACCF) should come between WACCF and ACE, partially overwriting one and being partially overwritten by the other. This is also a good example of why a patch for WACCF and some other Mod X should come immediately after WACCF, as placing that patch below ACE will revert ACE's intentional changes back to WACCF's values in any shared record.
Note that in my methodology below, I'm going to treat this as if it should only apply to masters without the ESM flag checked, but it may be better to just exclude the vanilla ESMs and USSEP. I'm still trying to decide if there ARE any pros or cons in regards to whether it should just be vanilla ESMs and USSEP excluded, or all ESMs excluded. For now I'll just say all ESMs since it makes the below more readable. Please treat the words "ESP master" below to mean "non-ESM flagged" masters.
Methodology:
Pass 1: Go through all plugins and count the number of ESP masters each plugin has.
Pass 2: Apply LOOT's sorting algorithm only to mods with zero ESP masters.
Pass 3: Insert into the result of Pass 2 all mods with 1 ESP master, placing them immediately after its master or as close to it as strict metadata allows.
Pass 4: Insert into the result of Pass 3 all mods with 2 ESP masters, placing them immediately after the last of its masters or as close to it as strict metadata allows.
Pass X: Insert into the result of Pass X all mods with X-1 ESP masters, placing them immediately after the last of its masters or as close to it as strict metadata allows.
Steps 3-X are really all one step, the point being to order all base mods with no masters first, then insert mods with 1 master, then insert mods and patches with 2 masters, etc. till you're done.
By "strict metadata" I mean specific "Mod X must come after Mod Y" ordering, not just "Group B must come after Group A" ordering. If this turns out not to work for all mods that have only one master, I won't mind this proposal being reduced to only applying to actual conflict patches (2 or more masters), which should always be possible. I just decided to propose this for all mods with any masters until we can find a solid reason not to and because it might actually be easier to implement this way.
Possible complications and solutions:
Problem A) What if Mod A has a master B which itself has more masters than A does. This could be handled in two ways:
Problem B) How do you order patches that would be inserted into the same position via this method?
Take mods A, B and C. There exist patches for A-B, for B-C, and for A-C. My method would result in this:
1: Mod A
2: Mod B
3: Patch A-B
4: Mod C
?: Patch A-C
?: Patch B-C
Those last two patches would be inserted in the same pass, and placed after C because that's the lower of their masters. How should they be ordered? Answer: They should be ordered by the position of their other master. Since Mod A should come before Mod B, then patch A-C should come before patch B-C.
Please throw me any questions or arguments you have against this, I've given a lot of thought to it for a year now and I plan to monitor this request. To be honest, that LOOT doesn't do this is the only reason I have not used LOOT for actual ordering until now... so far I just use it to advise me of required patches. If it did this, I would be very likely to adopt and recommend its ordering highly.
The text was updated successfully, but these errors were encountered: