Preserve deletions doesn't work?

matortheeternal / smash

An application that provides a means of performing automatic conflict resolution between multiple Bethesda Plugin Files for TES and Fallout games.

Other

129 stars 20 forks source link

Preserve deletions doesn't work? #213

Closed cmeeren closed 5 years ago

cmeeren commented 5 years ago

I have the following mods all modifying the Archmage's Robes. Here showing conflicting records:

For this patch, I set plugins 19 (the main Circlets or Masks with all Robes and Hoods plugin) and 2E (a custom USSEP compatibility patch for this mod) to a copy of Smash.All with "preserve deletions" on ARMO/BOD2. Since the smashed patch contains the "Circlet" flag, this has either not worked, or I have misunderstood what "preserve deletions" does. (In general, I can't find any documentation on the various toggles in Mator Smash - this would be nice to have.)

I also tried removing the "Treat as single entity" in ARMO/BOD2, but the result is the same.

If I have misunderstood, then how can I ensure that the "Circlet" flag is not included in the smashed patch?

matortheeternal commented 5 years ago

Smash treats flag elements as "value" elements, and if the circlet flag was actually treated as an element you would need to set preserve deletions on First Person Flags, not BOD2.

There isn't a way for you to tell smash not to include the Circlet flag asides from telling Smash to ignore BOD2 changes from the USSEP altogether, or disabling "treat as single entity" on it for the smash setting used by USSEP.

cmeeren commented 5 years ago

Would disabling "treat as single entity" have other consequences I should know about in this case?

matortheeternal commented 5 years ago

The main effect it will have is with how mods which make different conflicting changes in the BOD2 element would be resolved. E.g. if one mod changed Armor Type and another changed First Person Flags, when treat as single entity is checked you will not get both changes. "Treat as single entity" basically means "don't merge changes from different plugins inside of this element". In the case of the Body Template element that actually might not make sense - it was an automatically assigned attribute because BOD2 is a struct subrecord (and a majority of struct values shouldn't be merged)

cmeeren commented 5 years ago

So are you recommending that I toggle it off for BOD2 in Smash.All and use that for all plugins?

Also, what is the behavior when some plugins have "Treat as single entity" on while others do not?

matortheeternal commented 5 years ago

So are you recommending that I toggle it off for BOD2 in Smash.All and use that for all plugins?

I think it should be fairly safe and is worth trying. If you see a result which is not desirable after doing so let me know.

So your full changes will be:

Disable "Treat as single entity" for the ARMO\BOD2 element in Smash.All.
Create a custom setting based off of Smash.All for USSEP with "First Person Flags" unchecked, then apply it to the USSEP.

cmeeren commented 5 years ago

I don't really want to do step 2, because USSEP might have edits for First Person Flags that should be forwarded (even if the one I mentioned shouldn't). Is it necessary for this to work? If so, I'll probably just patch the Smashed Patch manually in xEdit after creating (I already have a bucket list of such edits I have to go through each time I rebuild the patch).

matortheeternal commented 5 years ago

In that case yeah, you're going to have to do a manual patch. There isn't a way to tell Smash to prefer an ITM value over a change without telling it to not process the field in the plugin where the change occurs. That's effectively an "exception" to standard conflict resolution, and requires either a plugin that knowingly resets it (via a master dependency, possible to fix via #216 if implemented), or a custom "user patch".