Requiem Patches Update

[ProbablyManuel]

Groups in their current form are too unflexible to do what Requiem patches and addons really want. Thus I have now decided to go back to good old load after rules. All things considered they just work better.

The most popular Requiem patches and addons have the necessary rules to keep the order Bugsmasher < DLC patches < WAFR + CCF patches < Sound mod and other low priority patches < the remaining Requiem patches. The main advantage of load after rules compared to groups is that unrecognized plugins and non-Requiem mods that should load after Requiem are no longer forced between Requiem.esp and the Bugmasher plugin. Instead they usually end up somewhere lower which is where they belong.

[Ortham]

Groups in their current form are too unflexible to do what Requiem patches and addons really want.

Could you expand on this? In this case, would you say that groups are lacking, or is it more that they're not the right tool for the job?

Also, I can't find our previous discussion on an "immediate load after" metadata type, can you remember where that was?

[ProbablyManuel]

#190

I think it's more that groups are not the right tool for the job. Loading a plugin directly after another is metadata that is specific to a plugin not a group. You could theoretically use groups for that purpose if the mod has its own group (in that referenced issue I actually suggested to do that), but it seems a bit misguided to me now.

"load directly after" functionality has use cases beyond just Requiem. One example of plugins that should be loaded directly after its master are USLEEP/USSEP patches. There is no reason to ever load a plugin between a mod and its USLEEP/USSEP patch. The same applies to patches for DLCs and mods that load very early because they should lose conflicts such as Weapons Armor Clothing and Clutter Fixes or Even Better Quest Objectives. What good can happen if some mod loads in the first third of the load order and its EBQO patch ends up in the bottom third? This rationale also applies to addons for overhauls. Why should an independent plugin ever be loaded between Ordinator and an addon for it?

My prefered solution would be something like the following. Plugins get an directly_after field. A plugin with this metadata must be loaded directly after the specified plugin. If multiple plugins request to be loaded after the same plugin, the normal after field decides which plugin is loaded first.
I never looked at LOOT's source code, but I believe this can be implemented in a quite simple manner: Plugins that request to be loaded directly after another plugin are excluded from the sorting algorithm because their position is directly infered from their "master". Only after the load order has already been sorted will they be inserted into the load order. Any more complex scenarios are considered errors because there is no use case for them anyway. These are all edge cases I can think of:

• A plugin requests to be loaded directly after two different plugins. This metadata makes no sense (but I may make sense to have two entries in the masterlist, e.g. if a mod comes in two versions).
• Plugin A requests to be loaded directly after plugin B, but A has a master below B in the load order. Why would you ever want to use the directly_after field in such a case? Alternatively you could pass down the load after metadata of A to B, but I wonder if there is any benefit in doing so.
• A requests to be loaded directly after B and B requests to be loaded directly after C. Why would A ever have B in its directly_after field in such a case? Just load it directly after C and add A after B as a normal after.

[MacSplody]

One group before with a set order using afters should work.

Group changes

  - name: &morrowlootGroup Morrowloot
    after: [ *stepGroup ]

  - name: &preRequiemGroup Pre Requiem (Patches/Add-ons)

  - name: &requiemGroup Requiem
    after:
      - *preRequiemGroup
      - *morrowlootGroup

  - name: &ocsGroup Open Cities Skyrim
    after: [ *requiemGroup ]

  - name: 'Requiem - Bugsmasher Edition.esp'
    group: *preRequiemGroup

  - name: 'Requiem - Legendary Bugsmasher Edition.esp'
    group: *preRequiemGroup

  - name: 'Requiem - Hearthfire.esp'
    group: *preRequiemGroup
    after:
      - 'Requiem - Bugsmasher Edition.esp'
      - 'Requiem - Legendary Bugsmasher Edition.esp'

  - name: 'NRM_Dragonborn_Reqtified.esp'
    group: *preRequiemGroup
    after:
      - 'Requiem - Bugsmasher Edition.esp'
      - 'Requiem - Legendary Bugsmasher Edition.esp'
      - 'Requiem - Hearthfire.esp'
    inc:
      - 'Fozars_Dragonborn_-_Requiem_Patch.esp'

  - name: 'Fozars_Dragonborn_-_Requiem_Patch.esp'
    group: *preRequiemGroup
    after:
      - 'Requiem - Bugsmasher Edition.esp'
      - 'Requiem - Legendary Bugsmasher Edition.esp'
      - 'Requiem - Hearthfire.esp'

  - name: 'Requiem - Vanilla Dragonborn DLC.esp'
    group: *preRequiemGroup
    after:
      - 'Requiem - Bugsmasher Edition.esp'
      - 'Requiem - Legendary Bugsmasher Edition.esp'
      - 'Requiem - Hearthfire.esp'
    req:
      - 'Requiem.esp'

  - name: 'KFR-Kryptopyr''sFixesReqtified.esp'
    group: *preRequiemGroup
    after:
      - 'Requiem - Bugsmasher Edition.esp'
      - 'Requiem - Legendary Bugsmasher Edition.esp'
      - 'Requiem - Hearthfire.esp'
      - 'Requiem - Vanilla Dragonborn DLC.esp'
      - 'Fozars_Dragonborn_-_Requiem_Patch.esp'
      - 'NRM_Dragonborn_Reqtified.esp'

  - name: 'KFR-(?!Kryptopyr''sFixesReqtified).+\.esp'
    req:
      - 'KFR-Kryptopyr''sFixesReqtified.esp'

  - name: 'COR-CraftingOverhaulReqtified.esp'
    group: *preRequiemGroup
    after:
      - 'Requiem - Bugsmasher Edition.esp'
      - 'Requiem - Legendary Bugsmasher Edition.esp'
      - 'Requiem - Hearthfire.esp'
      - 'Requiem - Vanilla Dragonborn DLC.esp'
      - 'Fozars_Dragonborn_-_Requiem_Patch.esp'
      - 'NRM_Dragonborn_Reqtified.esp'
      - 'KFR-Kryptopyr''sFixesReqtified.esp'

  - name: 'COR-(?!CraftingOverhaulReqtified).+\.esp'
    req:
      - 'COR-CraftingOverhaulReqtified.esp'

Testing load order.

  0  0     Skyrim.esm
  1  1     Update.esm
  2  2     Dawnguard.esm
  3  3     HearthFires.esm
  4  4     Dragonborn.esm
  5  5     Unofficial Skyrim Legendary Edition Patch.esp
  6  6     HighResTexturePack01.esp
  7  7     HighResTexturePack02.esp
  8  8     HighResTexturePack03.esp
  9  9     AOS.esp
 10  a     Requiem.esp
 11  b     Requiem - No Messages.esp
 12  c     Requiem - Legendary Bugsmasher Edition.esp
 13  d     Requiem - Vanilla Dragonborn DLC.esp
 14  e     Requiem - Audio Overhaul for Skyrim.esp
 15  f     Alternate Start - Live Another Life.esp
 16 10     Requiem - Live Another Life.esp

[ProbablyManuel]

I'm pretty sure I tried this already and it didn't work. There is no rule that says preRequiemGroup must load before default and hence all the other Requiem patches/addons (that are in the default group) can still end up anywhere below the plugins in preRequiemGroup. And loading preRequiemGroup before default leads to sorting errors.

[MacSplody]

Requiem patches/addons (that are in the default group) can still end up anywhere below the plugins in preRequiemGroup

Yeah, you're right, it's still going to need additional afters,
Requiem - Audio Overhaul for Skyrim.esp can be manually moved and it will keep its position after sorting regardless of the preRequiemGroup.

[ProbablyManuel]

It would be a good idea to ask other authors of compatibility patches what they think of a "load directly after" functionality or if they think it's necessary at all. They might have different expectations or use cases than me.
One person that comes to my mind is Qwinn from QUASIPC. This article already touches subject. He recommends to always load compatibility patches immediately after the second mod that they are patching. The definition of directly_after has to be slightly adjusted to match this: A plugin with this metadata must be loaded directly after the last plugin in the list. This would work for both him and me.

Either way this discussion doesn't really affect the PR, as the PR improves the situation in the current environment with no way of expressing "load directly after". Can you merge this PR (or do you have objections to the changes?) and we move the discussion to a separate issue?

[MacSplody]

@Kaenguru-Knobel-Kette Personally I think sorting with groups works better with most modules in default. So I think the changes you made are fine.

But as to the directly loads after, well it seems more like the desired result would be to treat the Legendary Bugsmasher as being the main Requiem plug-in.
Aliasing was mentioned elsewhere, but I'm not sure that would cover patches treating Bugsmasher as being the Requiem.esp.

[MacSplody]

Issue on Aliasing loot/libloot#46

[ProbablyManuel]

But as to the directly loads after, well it seems more like the desired result would be to treat the Legendary Bugsmasher as being the main Requiem plug-in.

Yes, that's another way to express the desired result (and arguably a more intuitive one). But the referenced issue doesn't allow to treat the Bugsmasher as being the Requiem plugin, it allows copying metadata from the Requiem plugin to the Bugsmasher. That's a useful feature for merging, but doesn't help with compatibility patches and addons.

[Ortham]

Merged, and I've opened an issue for directly_after to continue discussion there.