Automatic outfit merging

[focustense]

There are a wide variety of mods that edit NPC outfits: that is, the DOFT - Default Outfit or SOFT - Sleep Outfit references.

• Armor and Clothing Extension
• Wizard Hats
• Opulent Outfits

and no doubt many more.

EasyNPC does "support" outfits in the sense that they are currently part of the Default/Behavior category. Installing CRF, Opulent Outfits, and the OO-CRF patch, and referencing OO-CRF as the Default, will get the outfit, along with any face edits from other overhauls, without messing up CRF. However, our goal is to eliminate thousands of compatibility patches, and we could do a lot better here.

In a similar vein to hair mods (#6), there is likely a happy-path that most modders intend on, and that less-experienced modders probably intuit should just work:

• If an overhaul changes an NPC's outfit, then the overhaul wins.
• If an overhaul does not change an NPC's outfit, but some outfit mod does, then the outfit mod wins.
• In some cases explicitly specified by the player, outfit mods should take precedence over the overhaul mod.

The solution is therefore to detect, catalog, and allow users to override and prioritize "outfit changers", and incorporate these into the merge using logic similar to the above. This will eliminate the need for outfit compatibility patches, just like it already eliminates the need for overhaul compatibility patches.

Some open questions:

• How do we reliably identify an "outfit changer mod"?
  • One way is to try to go by record types, i.e. look for just ARMR, ARMA, and NPC_, maybe also TXST and so on. But outfits can imply a lot more records - magic effects, crafting/tempering recipes, even worldspace locations containing cheat chests for those outfits.
  • A simpler, dumber but probably more stable way is to mark any mod that changes an NPCs outfit as an outfit-changer mod. This could put out a bloated list, but maybe that's OK.
• Should the outfits be cloned into the merge, or the outfit mods be used as masters?
  • The wide variety of record types that could be used by outfit mods tend to point to the master option. Better to just add a dependency up front than to risk a half-baked implementation that copies some top-level records and still needs the master for something deep in the bowels of the mod.
  • However, this does nerf the "standalone" claim a bit.
• If body carryover (Custom body carry-over #7) is also in use, should outfit mods be assumed to be meant for the default body and therefore incompatible and ignored? Is it even possible to define a rule that will always give the correct result here?
• Should this be visually-integrated in any way, i.e. do we need outfit previews along with NPCs or in some other section?

[NairSiddharth]

@focustense Hope you don't mind me putting in my two cents here, the open questions were just intriguing and I thought maybe I could try to help answer them.

Regarding reliably identifying an "outfit changer mod", it'd be best to do as you said and just have any mod affecting the NPC outfit as a npc-changer mod. I agree that'd it be a bloated list, but its best as identifying any possible mod that makes a change, leaving it up to the user to decide what mod to be their default outfit,

The outfit mods being used as a dependency would definitely affect the standalone aspect of EasyNPC, but copying all the records would be problematic as you've stated. The only problem I can imagine with that is armor merges that people like myself use to save esp spaces, but given that that generates its own plugin that can be selected in EasyNPC, I don't think that'd pose a large problem.

Regarding the outfits and body carryover interaction, I'd actually lean to having the outfits overwrite the bodies. Bodies are typically seen as the base (as I'm sure you know) so any outfits should overwrite it in the rare case where users have outfits that don't match their NPC body type. Any risks of clipping could be expressed to the user, leaving that decision up to them.

I don't think having visual integration would be a good idea, at least on the backend portion given the amount of combinations you'd have to do to show all the choices for a user (each outfit with each face). If you were to go this route, you may want to make it a multistep process where the user first selects their face, then the visual preview changes to show that face matched with all the different possible outfits. It'd be really helpful on the enduser's side, but I am not sure if the work to implement that is feasible or something youd want to undertake.

Hopefully this is helpful!

[Cloud-and-Proud]

Hej, I hope it's okay I also add some cents, but I wanted to make the argument that outfits should be integrated into the merge, not set as masters
A lot of NPC overhaul mods change outfits as well as faces, because to an NPC overhaul creator both are visual edits that you'd make in improving the appearance of an NPC
If you then have to set those appearance overhauls as masters it's going to cause conflicts if they have loose files, and it'll also mean you're not merging them (they will take up plugin slots)

Usually NPC overhauls that change outfits don't add quests and or locations where the gear can be obtained, and outfit mods that do aren't NPC overhauls. Maybe you could distinguish between these two kinds of outfit mods? The former is merged in, the latter is set as master