Sort plugins closer to their masters

[Qwinn1]

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:

1. During pass 1, build an expanded master list, where if Mod A has a master B, and master B itself has masters C and D, then C and D are also counted as masters of Mod A for the purpose of determining which pass it should be inserted in.
2. Probably easier, if the current pass is attempting to insert a plugin whose master hasn't itself been inserted yet, simply skip Mod A in that current pass. Eventually master B will be inserted, and any mod A that was skipped can then be inserted in a later pass.

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.