Base Object Swapper (by powerofthree)

[TechAngel85]

Discussion topic:
Base Object Swapper by powerofthree
Wiki Link

---

I am not advocating for this mod to be in Step, however, I consider it important to log the use of the mod for users that do install mods requiring Base Object Swapper. The main information to be aware of is the added layer to conflict management.

Conflict Management with Base Object Swapper

• Configs (INIs) are parsed alphabetically. Regardless of mod name or order, the INI name is what matters.
• Any mods swapping the same object (conflicts), the first config (alphabetical) will win. The remainder of the conflicts will be treated as errors and logged. Check the log for these conflicts when multiple mods are installed that require Base Object Swapper.
• More Informative Console is useful for checking what actually got swapped

Due to the way the mod works objects that are "swapped" will have no conflict data within common tools such as xEdit and a manager's conflict lists. This can lead to increased difficulty in troubleshooting because the "records" will be saying modA is providing the asset, but in reality they're being swapped out when the game is ran by ModX; not listed anywhere within normal conflict management systems.
 

Large References

• Do not use this utility on large references
• Do not use any mods requiring Base Object Swapper that have been used on large references

Large reference changes require updating the RNAM data for the cells altered in order for changes to display correctly in the LOD. This is because SE uses "super-meshes" for large references. That is, anything that is a large reference is merged into one large mesh for each exterior game cell. If the RNAM data is not update to tell the game of changes, then the result is pop-in of some nature and usually missing LOD.

Since Base Object Swapper is changing references at runtime, there is no way to update RNAM data to account for changes to large references from using this utility. Therefore, do not use Base Object Swapper on or for any large references!

 

We urge caution in migrating to or installing mods that are using this utility. Users should know what they're doing!
Stay aware some conflicts will not be shown or listed anywhere, and conflicts between mods using this utility are listed within the utility's log.
Avoid using with large references or pop-in will result.

[z929669]

I can see how this would allow one to increase variety when applied to references or to circumvent patching for a given conflict. Seems very powerful, but I agree that it adds a significant layer of complexity to keeping track of things, but that wouldn't seem to be an issue if configured for a specific build (i.e., guide level) ... user customizations to a build would likely be at least as tricky to manage as plugin conflicts/dependencies.

I wonder if it affects load times or if there are other drawbacks when hundreds (or more) of swaps exist in the setup.

[TechAngel85]

It's most definitely interesting. I just don't see the reason for it when you can do the same with plugins. It's main purpose seems to simply be for circumventing the game's asset management, which I don't stand behind for "normal" use in everyday mods. I kind of echo your thoughts. This seems better suited for a mod-build/guide-level tool to replace some patches or provide custom setups between mods (e.g., install two or three different farmhouse mods and assign them by region). However, really the only reason to use this over plugins would be to reduce plugin count and a bit of work. 

It would be limited by the script engine and disk read speeds, which the script engine is very fast for AE and the same as it's always been for SE.

 

[z929669]

Yeah, increasing variety as the farmhouses example or by swapping several references with alternates for a single tree if that's possible seems interesting ... but as you mention, this can also be accomplished via plugin. ESL sort of takes care of plugin limits too.

EDIT: I'll bet Arthmoor et al really hate this mod and the potential support headaches it will cause them ...

[gamingsrc]

I always prefer "manual" changes in the game, than scripted changes. When you have something manual edited by a plugin you know how to fix it. However if a change was made by a Dll mod, it difficult to deal with the change if you loose trace of the mod that introduced it.

[VeryAngryCathedral]

3 hours ago, TechAngel85 said:

It would be limited by the script engine and disk read speeds, which the script engine is very fast for AE and the same as it's always been for SE.

The Base Object swapper mod doesn't have any Papyrus scripts, so the speed of the game's script engine isn't relevant. It's an SKSE plugin only.

[Mousetick]

It's basically the same idea as SPID: patch dynamically at runtime rather than statically in xEdit. This eliminates the need to redo a patch when you add or remove affecting or affected mods.

While the idea for this mod framework is good in theory, I don't think it can fly in practice. Unlike SPID which distributes items to NPCs, this replaces objects. If you have 2 mods MA and MB that each have SPID lists (_DISTR.ini files) for the same actors, their effect is additive: an actor would receive the items from MA and MB. Conversely an object can only be replaced by a single other object at a time. So if you have 2 mods MA and MB that each have SWAP lists (_SWAP.ini) for the same object, they conflict with each other and only one of them will be effective. This essentially moves the conflict resolution goalpost elsewhere, but it's still there, and resolving the conflict is now even more complicated due to the information being spread out in various _SWAP.ini in different mods. Whereas it's trivial to see all conflicting mods at once for a given record in xEdit, and decide which one should win.

7 hours ago, gamingsrc said:

However if a change was made by a Dll mod, it difficult to deal with the change if you loose trace of the mod that introduced it.

Are you Arthmoor disguised as another user? Please don't mind me, I'm just kidding 

[z929669]

9 hours ago, Mousetick said:

It's basically the same idea as SPID: patch dynamically at runtime rather than statically in xEdit. This eliminates the need to redo a patch when you add or remove affecting or affected mods.

True, it's more dynamic, but it places the burden on the user, who will often get this wrong and claim something isn't working (more support queries). It's great for people quickly testing things before making the 'static' changes via a plugin, but still six one way and half dozen the other.

[TechAngel85]

OP updated with information regarding large references.

[Mousetick]

1 hour ago, z929669 said:

It's great for people quickly testing things before making the 'static' changes via a plugin, but still six one way and half dozen the other.

Yep. It's mostly great for mod authors who only need to create the record(s) for the replacer object(s) in a plugin, and everything else is defined in the _SWAP.ini. The framework takes care of patching replaced objects at runtime.

In case of conflicting SWAPs, what will ultimately happen is that mod users will need to merge all _SWAP.ini files from the different mods into a single file, and then perform "conflict resolution" by hand-editing the merged file. To make matters worse, the framework author decided that the first occurrence in a conflict is the one to win, which is the opposite of regular mods.

[z929669]

1 hour ago, Mousetick said:

To make matters worse, the framework author decided that the first occurrence in a conflict is the one to win, which is the opposite of regular mods.

Yes, this is definitely not aligned with the general pattern and throws an exception into the mix. The more I think about it, the more I think the idea of a plugin is to rationalize this insanity. If I were a newcomer sorting out the history and evolution of these mechanics, I would assume that the runtime method was first and was improved upon by the plugin-load method (which creates consistency for load-order prioritization of INIs, BSAs, etc). This method essentially breaks the already well-understood mechanics, subverting the expectations of mod authors. Until someone explains in detail exactly what this allows that cannot be achieved by plugin-driven changes, I will view this method as a sort of temporary "unit-testing" tool that is (arguably) useful for a mod author in plugin dev. What is the problem, and how does this mechanic allow one to circumvent it?

I'm getting twisted just thinking about it.

[Mousetick]

In a nutshell...

This is primarily middleware for mod authors. It's intended to greatly reduce or eliminate the need for traditional patches or scripts, and to improve performance in the process. I'm using the term 'patch' in its most general sense - in its simplest form, a mod plugin that overrides a few records in Skyrim.esm can be considered a patch for Skyrim. A mod plugin that voluntarily overrides a few records in another mod is a compatibility patch.

The "old-school" way of replacing objects can be seen in kryptopyr's overhaul mods for example, which have big plugins that override hundreds of vanilla records, and include dozens of scripts. These overhaul mods are a pain to use with other mods because they require compatibility patches to be integrated with those other mods, and are a drain on the engine because of all the script and plugin processing.

The "modern" way of dealing with this problem as implemented by SWAP is to define the new objects in the mod plugin, and let the framework (more or less an engine extension) do the replacement on-the-fly at runtime, based on substitution rules defined in the mod's SWAP configuration file. Patches or scripts are no longer needed to override the vanilla records and references. Compatibility patches are no longer needed to override another mod's record.

Let's say you're a mod author and your mod replaces the vanilla salmon by a rabbit (stupid example to illustrate), and another mod replaces the vanilla salmon by an enhanced salmon. With the "old-school" way, if you wanted to replace the other mod's salmon by your rabbit, you'd have to create a compatibility patch plugin, or in the best case scenario, simply change the load order of both mods. With the "modern" way, you'd simply add a substitution rule to your SWAP configuration file.

SPID has a different function, but has the same design goals as and works similarly to SWAP.

This is very smart, neat and efficient. Right now SWAP is still experimental. There are a few mods that have been converted to SWAP as proof of concept:

• https://www.nexusmods.com/skyrimspecialedition/mods/60741
• https://www.nexusmods.com/skyrimspecialedition/mods/60756 (without SWAP: patching ~1200 worldspace records / with SWAP: 0 worldspace record overrides but ~1200 substitution rules)
• https://www.nexusmods.com/skyrimspecialedition/mods/60762

The problem is that the long-term implications have seemingly not been thought through. This framework could be adopted too fast by too many MAs in too raw a state. Issues identified so far:

• Doesn't work with large references
• Unintuitive precedence rule, opposite of long-established rule
• Conflict identification and resolution process is significantly worse than plugins in xEdit

This was supposed to be brief so I'll stop here 

[z929669]

Good summary.

I predict that this functionality will cause significant waves and disruption but will probably spur ideas and wind up having a positive impact if/when it evolves ... and is 'regulated'/'constrained' properly and prioritizes conflicting rules according to long-established precedents.

[z929669]

So the first issue of BOS breaking LOD

Looks as if sheson is aware and making forthcoming changes to account for BOS

[z929669]

DynDOLOD Version 3.00 Alpha 59

• DynDOLOD.exe - unset some problematic flags on copied base records used for dynamic LOD
• DynDOLOD.exe - added dynamic flag to mesh mask rules
• DynDOLOD.exe - added principle support for base record swapping via _SWAP.INI
• DynDOLOD.exe - fixed a case of not creating an overwrite for material shader added by ESP
• DynDOLOD.exe - fixed a case of wrongly applying mesh mask rules without VWD flag and existing LOD model
• DynDOLOD Resources - updated/added meshes for better compatibility
• DynDOLOD Resources SE - updated/added meshes/textures for better compatibility