Feature Request: plugin aliasing. about libloot HOT 3 OPEN

This seems like a good idea. People face a similar problem when merging plugins, and I think the two problems can be solved with a more general form of aliasing. Here's what I think that could look like:

Add an alias key to the plugin metadata structure that takes a list of plugin names that are alias targets, e.g.

  - name: Y.esp
    group: Y
    req: [A.esp]

  - name: Z.esp
    group: Z
    req: [B.esp]

  - name: X.esp
    group: X
    alias: [Y.esp, Z.esp]
    req: [C.esp]
    # Other metadata for X.esp

This means that when getting the metadata for X.esp, LOOT will see that it is an alias of Y.esp and Z.esp. It will first look up the metadata for Y.esp, then for Z.esp, and merge Z.esp's metadata on top of Y.esp's metadata, so the metadata is

- name: Z.esp
  group: Z
  req: [A.esp, B.esp]

it then merges the metadata for X.esp on top of this, so the metadata becomes

- name: X.esp
  group: X
  req: [A.esp, B.esp, C.esp]

LOOT uses the normal process for getting metadata for aliases, so it will match regex entries. I.e. don't use a regex plugin metadata entry's name string as an alias, use a plugin name that matches that regex entry.

The alias targets don't need to match any metadata entries. If an alias target doesn't have any metadata, merging has no effect.

The order of alias targets matters, it is the order in which metadata are merged.

It's an error to target an aliased plugin, e.g.

  - name: X.esp
    alias: [Y.esp]

  - name: Y.esp
    alias: [Z.esp]

This is because allowing nested aliasing introduces the potential for cycles, and dealing with that adds complexity. Errors due to cycles can also occur unexpectedly due to the potential distance in the alias chain between the plugin the user is editing metadata for and the plugin that already targets it. I don't think the flexibility of nested aliasing is worth the costs.

To guard against nested aliasing, when setting metadata for a plugin that includes an alias, LOOT will need to check that the alias targets are not aliased, and also check that the current plugin is not an alias target of any other metadata.

from libloot.

The current proposal only works in one direction. SkyUI_SE.esl will treat itself as identical to SkyUI_SE.esp, but other masterlist entries that reference SkyUI_SE.esp won't be aware of SkyUI_SE.esl. In this particular example &reqSkyUI will still be displayed.

type: warn
    content: 'SkyUI_SE.esp is not active in your load order. [SkyUI SE](https://www.nexusmods.com/skyrimspecialedition/mods/12604) is required for this mod to be fully functional.'
    condition: 'not active("SkyUI_SE.esp")'

has to be changed to

type: warn
    content: 'SkyUI_SE.esp is not active in your load order. [SkyUI SE](https://www.nexusmods.com/skyrimspecialedition/mods/12604) is required for this mod to be fully functional.'
    condition: 'not active("SkyUI_SE.esp") and not active("SkyUI_SE.esl")'

which is not as simple as just merging some metadata. Actually for full compliance the content should be updated too, i.e. something like "SkyUI_SE.esp (that is an alias target for SkyUI_SE.esl) is not active in your load order. [...]".

after, req and inc entries have the same problem. For example A must be loaded after B and B is merged into merge M. M can inherit metadata from B, but A isn't aware of M. It's now possible that A can load before M even though it musn't.

from libloot.

I think that's out of scope for this feature, two-way aliasing is way more complicated, and as you've pointed out, solves different problems.

from libloot.