Add metadata to force a plugin to load immediately after another

[Ortham]

Discussed in loot/skyrim#190 and loot/skyrim#245, the idea is to have something like

- name: B.esp
  directly_after: A.esp

which has the effect that LOOT will sort B.esp after A.esp with no other plugins between them.

Open Questions

• Should directly_after be invalid for regex entries? It only makes sense for one match to use the value, but the regex entry may be for a set of exclusive plugins anyway.
• How would this interact with the plugin aliasing feature proposed in Feature Request: plugin aliasing. #46?
• How to handle merging metadata entries that specify different directly_after values?
• How to handle the case where plugin masters and 'hard' metadata like after and req entries form a cycle with directly_after?
• How to implement this - should it be part of the graph sort, or done as a post-topological sort "override" step?

@Kaenguru-Knobel-Kette has noted that it would be good idea to get the opinions of other compatibility patch authors on this, to see if their expectations or use cases differ.

[pStyl3]

• How to handle merging metadata entries that specify different directly_after values?

Say we have:

- name: B.esp
  directly_after: A.esp

- name: C.esp
  directly_after: A.esp

This would indicate that both B.esp as well as C.esp should load directly after A.esp - which isn't possible, as only one can load directly after the target A.esp.

Since I would interpret directly_after as another hard rule that must be followed (ignoring or not following through with it would contradict the purpose of direclty_after) .. I'd say that if LOOT detects while sorting, that there are 2 or more plugins that should load directly_after some target plugin (e.g. A.esp) - that the sorting should fail and we display an error message then.

---

• How to handle the case where plugin masters and 'hard' metadata like after and req entries form a cycle with directly_after?

Simply let the cyclic interaction happen and thus, letting sorting fail if there's a contradiction between the existing hard rules and directly_after?

---

• Should directly_after be invalid for regex entries? It only makes sense for one match to use the value, but the regex entry may be for a set of exclusive plugins anyway.

I'd say that directly_after should be invalid for regex entries, indeed.

- name: (A|B)\.esp
  directly_after: C.esp

- name: F.esp
  directly_after: (D|E)\.esp

Example 1 would mean, that both A.esp and B.esp should load directly after C.esp, which isn't possible as only one can be directly after C.esp.

Example 2 would mean, that F.esp should load simultaneously directly after both D.esp and E.esp, which also doesn't make sense.

I'm not seeing, how regex entries should make sense for directly_after.

[pStyl3]

On the other hand, if we had

- name: (A|B)\.esp
  directly_after: C.esp

.. that could work, as long as only one plugin (so either A.esp or B.esp) would be installed and thus found by LOOT - if in addition to that C.esp would also be installed & found. If both plugins are found and this regex would be used, than sorting should fail once again.

The same would go for Example 2 from above, if both D.esp and E.esp are installed and found by LOOT, than sorting should fail. If only one is installed & found by LOOT than F.esp could load directly after one or the other.

[MacSplody]

Could another approach be to have the file act like it has a lower priority than all other files with overlapping records?

A file could be marked to always sort before any other files (in the same group) with overlapping records.
Any files marked would have normal sorting behaviour against other marked files.
Users could also turn this behaviour off for a file.

It wouldn't be as rigid as the directly after approach, having a fixed position for a file doesn't seem that important, to me at least. But changing sorting behaviour would be useful for some files, unofficial patches for example. I could have used this behaviour for Frost in Fallout 4 masterlist. One of the patches FrostNukaWorld.esp is small and tends to sort after any overlapping files, when the opposite is required.

Just a thought anyhow as I've no idea what kind of overhead that would add to sorting.