Investigate compatibility with other mods

[DavidJCobb]

Specific mods

We are currently incompatible with All Geared Up and Dual Sheath Redux, because both mods rely on Armors to show your gear on your person. All Geared Up uses a small collection of Armors and changes their armor-addon meshes to match your gear. Dual Sheath Redux is much more intensive, relying on a patcher to generate a new Armor (and ArmorAddon and NIF file) for every conceivable weapon or shield you may want to equip.

EDIT: Another user has requested compatibility with Wearable Lanterns, but AFAIK this is a conventional armor (i.e. the user equips it themselves). This would fall under the realm of new features, not compatibility -- allowing a user to flag an outfit body slot as "unchanged," rather than leaving it empty or overriding it -- but that's still blocked by compatibility work (see next comment). /EDIT

Options for compatibility:

• Hardcode the ESP filenames into the DLL, and check the load order for them on load. Allow armors from those load order indices to be visually applied even when an outfit is active. (For DSR, make sure we check for "Dual Sheath Redux Patch.esp", the patcher-generated file.) This approach should work as long as the mods aren't merged into a larger patch.

General

• A user reports that we are incompatible with NSFW mods, which may automatically strip the player of their armor as part of their scenes; when this occurs, the player continues to appear clothed if an outfit is active. This user has requested that we add an option to disable the outfit system when the player has no armor equipped.

[DavidJCobb]

There's one major concern that arises here, and that's the case of body slot conflicts. If an "exception" equipment is allowed to show, but occupies one or more body slots in common with outfit items, then what happens?

Testing during development establishes that our current hook doesn't allow overlapping/conflicting ArmorAddons to display on the player. This is not an engine limitation -- testing at the R&D stage showed that disabling certain function calls in the engine did allow conflicting ArmorAddons to stack on the player's model -- but it's a limitation of where and how we hook the equipment handling code. This means that if equipment and the outfit both try to apply an ArmorAddon to the same body slot, then only the most recent of them will "win."

For the case of a single-slot conflict -- one equipment armor, one outfit armor, one slot -- this is fine; we could just track which body slots are used by "exception" equipment, and refrain from applying any outfit armors that use that slot. What happens, however, when multiple slots are involved? What happens if an equipment armor uses the "head" slot and conflicts with an outfit armor that uses both the "head" and "body" slots?

In all likelihood, it will only be safe to work on this sort of compatibility system if we redesign our hook entirely. We currently rely on a function that I have defined as

RE::TESObjectARMO::ApplyArmorAddon(TESRace*` race, void** actorWeightModelData, bool isFemale)

We shim a call to it, and make calls to it ourselves. However, I suspect a more accurate definition would be

RE::TESObjectARMO::ApplyTo(TESRace*, void** targetData, bool isFemale)

To be clear: we don't know exactly where the game removes ArmorAddons that should no longer apply to the player and applies ArmorAddons from newly-equipped/still-equipped armors. If we find that specific process and hook it, then we'll be able to support conflicting ArmorAddons -- which, in turn, will make it more feasible to add compatibility with mods whose ArmorAddons aren't actually armor. Any such update would be slow to port, however; I'd effectively be rebuilding most of the mod's engine hooks, and aers would have to do the same.

EDIT: Patching downstream should also preempt pretty much every gameplay-related bug we've been seeing, without the need for individual patches. (Apparently, ActorWeightData isn't the most accurate name for the struct in question...) That'd give us less to maintain and minimize the potential for bugs.