Open DavidJCobb opened 5 years ago
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.
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:
General