[WIP] Mator Smash - The Conflict Resolution Revolution

[matortheeternal]

I don't think it's normal, but it depends on the smash settings you're using. Unfortunately the log doesn't have the debug stuff enabled so I can't tell you exactly where/when it happened.

 

The correct behavior would be:

 

1. Winning override is copied to smashed patch.

2. USLEEP FULL subrecord is processed as there being no changes, and value is not copied to the smashed patch.

3. CACO FULL subrecord value is in smashed patch.

[gabba]

Potion names come from ALCH records. In the screenshot you have settings for ACTI records showing, but if you're using the default setting I assume that 'FULL - Name' is checked under ALCH as well, meaning USLEEP will win name conflicts for ALCH, even if CACO is lower in your load order.

Good catch for the screenshot, I did expand the wrong record setting. Will show the proper one below. But I never changed any setting, just used what Mator Smash assigned when starting the program for the first time, based on USLEEP's bash tags.

 

I believe you're wrong about how Mator Smash processes records by the way, which is confirmed by what Mator says at #2 below. Say you have an .esp in your load order that modifies a bunch of ALCH records but only changes the FULL (Name) record of one of them relative to Skyrim.esm. I you use a setting with only the FULL box checked, only this one FULL entry will be forwarded. The names of all the other ALCH records will be ignored since they're identical to vanilla. So they're not considered "a change brought by this mod".

I don't think it's normal, but it depends on the smash settings you're using. Unfortunately the log doesn't have the debug stuff enabled so I can't tell you exactly where/when it happened.

 

The correct behavior would be:

 

1. Winning override is copied to smashed patch.

2. USLEEP FULL subrecord is processed as there being no changes, and value is not copied to the smashed patch.

3. CACO FULL subrecord value is in smashed patch.

Thanks for confirming, it seems I understand correctly how your algorithm works.

 

Shouldn't there be a fourth step here, assuming things were working correctly?

4. ALCH record is completely identical to conflict winner (CACO), and is removed from the patch.

 

Assuming this since I see a lot of "removing ITPO" messages in the log. No point in having a record in the patch that ends up the same as if you had no patch.

 

Anyways, I reproduced the problem with a freshly extracted Mator Smash, loading only USLEEP and CACO + masters. USLEEP has the default settings generated from the Bash Tags when you first start the program, everything else is on skip. All files are added to the JustUSLEEP patch. I've enabled all debug options.

 

Here's the whole resulting Smash folder (minus binaries) so you can look at all the logs at will. I've added screenshots of the Mator Smash setup and the resulting problem as seen in TES5Edit, and I put the resulting patch in the zip as well while I was at it.

https://dl.dropboxusercontent.com/u/22764021/Reproduced%20name%20forward%20bug.7z

[vlainstrike]

 

I believe you're wrong about how Mator Smash processes records by the way, which is confirmed by what Mator says at #2 below. Say you have a patch that modifies a bunch of ALCH records but only changes the FULL (Name) record of one of them relative to Skyrim.esm. I you use a setting with only the FULL box checked, only this one FULL entry will be forwarded. The names of all the other ALCH records will be ignored since they're identical to vanilla. So they're not considered "a change brought by this mod".

What I said doesn't contradict Mator's comment. He just worded it differently (and succinctly). I can see from my own patch results that it works the way I think it does, and I also know that the potion naming results from your original example can be fixed in one of two ways:

1) by de-selecting the 'Full - name' node from USLEEP's ALCH records OR

2) by giving CACO its own smash tag that includes ALCH: Names (which will essentially re-empower CACO to once again win the conflict by virtue of being lower in your load order)

(either will solve your immediate issue, but personally I would do both of those things because there is no reason to forward USLEEP's ALCH name info to a smash patch if you're using CACO, while there can be LOTS of reasons to forward CACO's names to your smash patch if you have a big load order)

Consider the following esp's from your example:

Skyrim.esm

USLEEP.esp

CACO.esp

JustUSLEEP.esp

Ok, so obviously there is a conflict between what USLEEP and CACO each think potions should be named. When creating a patch, Mator Smash can only see this conflict because 1) you loaded it into Mator Smash to begin with, and 2) because (I assume) you included CACO in the patch by right clicking it, and selecting 'add to patch', which is a good thing - you want Mator Smash to be able to see all the conflicts in your load order; as far as 'seeing' conflicts goes, it doesn't matter that CACO is being 'skipped' - being skipped just means that no filter is being applied to forward any of CACO's records, and therefore none of CACO's info will ever end up in the smash patch. In other words, any mod that is 'skipped' automatically forfeits its right to send any info to the smash patch whatsoever.

As I'm sure you are aware, normally, without Mator Smash, all of CACO's records would win all potion related conflicts by virtue of being loaded last, however, by giving USLEEP a smash tag with 'ALCH:FULL - Name' checked you've basically given USLEEP a 'superpower' that it didn't have before, namely to win naming conflicts that it would normally lose against mods found lower in your load order (like CACO). The result of USLEEP now winning the name conflict against CACO, is that USLEEP's naming info gets sent to your JustUSLEEP.esp, just like it did in your screenshot.

To further illustrate this point I'll give you an example of my own current ALCH solution that I asked about earlier in the thread, which is now working perfectly with results 100% in line with my expectations.

Consider the following mods, as they appear in my load order, along with my goals for each:

USLEEP goals: none, at this point

CACO goals:

1) to provide Weight and Effects for ALL ALCH products included with CACO (potions, poisons, food, ingredients, etc...)

2) to provide the Names of ALL ALCH products included with CACO, with the sole exception of Booze Names.

3) to provide a few textures/meshes not covered by other mods found lower in my load order (grenades and whatnot)

Radiant and Unique Potions and Poisons goals:

1) to provide textures/meshes for any remaining ALCH products not covered by the 3 mods listed below

Pretty Potions-Small Bottles Edition goals:

1) to provide textures/meshes for just about anything not covered by Aleanne's potion replacer (mostly DLC potions/poisons)

Unique Booze Bottles (with Alternate Names) goals:

1) to provide textures/meshes for Booze bottles only (with the exception of Holy Water and Skooma - I want Aleanne's beautiful textures for those, which is why Potions Replacer is loaded last)

2) to provide names for Booze bottles only

Potions Replacer by Aleanne goals:

1) to provide textures/meshes for ALL vanilla potions/poisons, including Holy Water and Skooma
(this mod only covers vanilla potions/poisons, thus the need for additional mods to fill in the gaps - which is actually great in terms of texture variety)

=====================================================

Problem: Every single potion texture mod in my load order also provides its own Effects data, which overwrites nearly all of CACO's potion Effects.

Solution: Use Mator Smash's tags to create a smash patch that not only forces CACO to win Weight and Effects conflicts that it would otherwise lose, but to also preserve ALL the desired graphics info from each of my 4 potion texture mods.

=====================================================

Here's how I set up my tags to perfectly accomplish ALL of my stated goals (I've abridged my tags a little bit in this post for clarity's sake):

USLEEP

======

skipped - I haven't specifically studied my USLEEP conflicts in depth yet, and it isn't messing with CACO's data, like AT ALL, since it's so high in my load order, so I don't have any reason (yet) to forward any of its info to a smash patch - this will probably change as I progress in analyzing the conflicts in each of my other mods, but it certainly won't change because of CACO

CACO:

==================

ALCH: EDID - Editor ID

ALCH: OBND - Object Bounds

ALCH: FULL - Name

ALCH: KWDA - Keywords

ALCH: Model - MODL - Model Filename

ALCH: Data - Weight

ALCH: ENIT - Effect Data

ALCH: Effects

Radiant and Unique Potions and Poisons:

================================

ALCH: OBND - Object Bounds

ALCH: Model

ALCH: Icon

Pretty Potions-Small Bottles Edition

============================

ALCH: OBND - Object Bounds

ALCH: Model

ALCH: Icon

Unique Booze Bottles (with Alternate Names)

====================================

ALCH: OBND - Object Bounds

ALCH: Model

ALCH: Icon

ALCH: FULL - Name

Potions Replacer by Aleanne

=======================

ALCH: OBND - Object Bounds

ALCH: Model

ALCH: Icon

If I was completely wrong in my assessment, all of this would fail miserably, but instead I was able to get 100% perfect results for all my ALCH records. My Lighting/Sound stuff is also doing very well; it currently sits at about 99.9% correct since I have exactly 2 nagging, incorrect records out of several hundred.

Edited September 28, 2016 by vlainstrike

[matortheeternal]

Gabba: A quick look at the log shows "<Error: No strings file for lstring ID 000020E6>" when smashing the FULL - Name subrecord of the Tamriel Worldspace. That's all I needed to know. Basically your version of Mator Smash is not loading the Strings files correctly, and as such is detecting a conflict in the FULL - Name element when no such conflict exists.

 

This has been fixed in the repository, so I can give you a "dangerous development release" which has this fixed. (Edit: Here ya go)

 

vlainstrike: You're not wrong about what you know, but there are a few more things happening behind the scenes. The key thing to note is that the winning override record is always the one copied to the smashed patch. So, if you uncheck the FULL subrecord in the smash setting on the plugin with the winning override record and no other plugin modified the value, you will still get the modified value from that plugin. This was originally done because I wanted to minimize the negative effects of any bugs with the smashing algorithm, but at this point I could probably switch to copying the master record to the smashed patch to give people more control.

[vlainstrike]

Ok, that makes sense, because I knew there was no way my settings would be effective if my understanding was completely borked, but I also recognize there are gaps in my knowledge (e.g. the correct application of the preserve deletions flag is still a complete mystery to me).

 

The key thing to note is that the winning override record is always the one copied to the smashed patch. So, if you uncheck the FULL subrecord in the smash setting on the plugin with the winning override record and no other plugin modified the value, you will still get the modified value from that plugin.

So to clarify, in Gabba's case, since USLEEP didn't modify the original FULL-name value vs. skyrim.esm, CACO should still be considered the winning override, even though CACO is 'skipped', and even though the USLEEP setting has FULL-name checked? If so, that would explain why CACO's DATA-weight value still made it to his smash patch, despite Bash.All checking DATA-weight for USLEEP, and furthermore that FULL-name should have followed suit. Is that correct? (which is what I think Gabba was trying to tell me.., in which case I was very wrong on a couple things, Gabba was totally right, and Mator, you are very gracious in your wording, lol :sweat:)

If all that is true, then CACO's DATA-weight would still make it to the patch, in this case, even if USLEEP were loaded after CACO, simply by virtue of being the only plugin to modify the original value, right?

-------------------

By the way, does anything in your last post explain why I've got 2 stray SoS acoustic records that refuse to smash? Like, is there another missing string or something, as you mentioned in Gabba's case? I feel like my question may have got lost in the shuffle here.

EDIT: I just tested my smash settings using the "dangerous development release" you just posted, and my 2 problematic acoustic records were resolved correctly. Does this mean both my issue and Gabba's were caused by the same thing?

Edited September 28, 2016 by vlainstrike

[vlainstrike]

This was originally done because I wanted to minimize the negative effects of any bugs with the smashing algorithm, but at this point I could probably switch to copying the master record to the smashed patch to give people more control.

 

That would be great, assuming you're confident enough now in the algorithm, as I just found a small example where that rule kinda conflicted with my goals:

 

As you know, I'm using Seasons of Skyrim, along with WAO, but I also have Lively Inns and Taverns installed (actually, I'm only using the LIAT - sounds.esp right now for the simulated crowd noise - I've got enough random NPC's running around from other mods). Anyway, after some testing, I decided that LIAT's crowd noise sounded more realistic when used with LIAT's acoustic spaces, which happen to be vanilla, which means MatorSmash will still pick SoS or WAO as the winning override.

 

Now, the inns and taverns only represent a tiny handful of CELL records, which are quite trivial to alter by hand, but if it was possible to automate MatorSmash to view LIAT's vanilla acoustic spaces as the winning override vs SoS and WAO in this case, it would mean one less thing to worry about.

 

This is a pretty rare circumstance, so it's not a huge deal, by any stretch, if you decide to maintain the current rules.

Edited September 29, 2016 by vlainstrike

[gabba]

Gabba: A quick look at the log shows "<Error: No strings file for lstring ID 000020E6>" when smashing the FULL - Name subrecord of the Tamriel Worldspace. That's all I needed to know. Basically your version of Mator Smash is not loading the Strings files correctly, and as such is detecting a conflict in the FULL - Name element when no such conflict exists.

 

This has been fixed in the repository, so I can give you a "dangerous development release" which has this fixed. (Edit: Here ya go)

Thanks for the quick fix! I gave it a try with the same settings and the results are promising: as expected the Cure Poison potion doesn't show up in the patch anymore, in fact my patch's size has reduced dramatically. Makes sense, since I believe that CACO carries most of USLEEP's fixes already except the most recent ones.

 

There remain a few records which IMO shouldn't be there, the last four seen in my screenshots: the BYOHHouse{1,2,3}Exterior ones already have USLEEP as a conflict winner, so I don't know why they're repeated in the patch. The WhiterunWorld entry is considered conflict-free by TES5Edit, so I'm not sure either why it ends up in the patch.

 

Here are the logs + patch again: https://dl.dropboxusercontent.com/u/22764021/MatorSmash%20-%20Logs%20for%20extraneous%20cell%20and%20world%20entries.7z

 

 

 

EDIT: Venturing a guess about what happened after looking at the log (forgive my inexact TES5Edit vocabulary): some TreeThicket01 were placed in those cells by USLEEP. Then in the cleanup phase those were all determined to be ITPO and removed from the patch, but that left their parent cell entry. I guess Mator Smash needs to check everytime it removes an ITPO from a cell whether that cell has any more children, and if it doesn't, check if it is itself an ITPO. And so on recursively going up the worldspace hierarchy: in the case of my patch all the worldspace/cell entries should be gone this way.

 

vlainstrike: You're not wrong about what you know, but there are a few more things happening behind the scenes. The key thing to note is that the winning override record is always the one copied to the smashed patch. So, if you uncheck the FULL subrecord in the smash setting on the plugin with the winning override record and no other plugin modified the value, you will still get the modified value from that plugin. This was originally done because I wanted to minimize the negative effects of any bugs with the smashing algorithm, but at this point I could probably switch to copying the master record to the smashed patch to give people more control.

Now you're getting me worried, it doesn't sound like a good change. I like the "regular Skyrim rules apply except for stuff you check in settings" behavior. Are there any convincing use cases to change how things work?

[gabba]

As you know, I'm using Seasons of Skyrim, along with WAO, but I also have Lively Inns and Taverns installed (actually, I'm only using the LIAT - sounds.esp right now for the simulated crowd noise - I've got enough random NPC's running around from other mods). Anyway, after some testing, I decided that LIAT's crowd noise sounded more realistic when used with LIAT's acoustic spaces, which happen to be vanilla, which means MatorSmash will still pick SoS or WAO as the winning override.

Now, the inns and taverns only represent a tiny handful of CELL records, which are quite trivial to alter by hand, but if it was possible to automate MatorSmash to view LIAT's vanilla acoustic spaces as the winning override vs SoS and WAO in this case, it would mean one less thing to worry about.

I was curious so I loaded the mods you mention in TES5Edit. Are you referring to the XCAS entries in each cell, as in my screenshot? If so it seems to me you can obtain the desired result simply by not checking the XCAS records on any mod in Mator Smash settings, and loading Lively Inns and Taverns after SoS/WAO and any other XCAS-changing mod in your load order. LIAT will win the conflict and restore the vanilla acoustic space.

 

 

[vlainstrike]

That might work... gonna be a pain in the rear though. Lots of rearranging the end of my load order, updating smash tags for whatever new conflicts happen to pop up, and updating a bunch of LOOT rules, but I'll give it a shot.

 

Edit: It worked, thanks for the tip! And it was just about as annoying as I expected it to be :armscrossed:, but it's done now. Hopefully I won't find any more instances where vanilla records end up being the preferred override over mods lower in my load order.

 

Now back to the fun work of smashing all the patches in my load order into obsolescence.

Edited October 4, 2016 by vlainstrike

[delgathar]

Hello,

 

I've started trying to customize mator smash rules to individual plugins. But I've run into what appears to be a snag.

 

Race/Male Head Data/Race Presets Male/RPRM - Preset NPC Isn't an option to select. The only options under "Sex" Head Data is MNAM , FNAM, and NAM0. Is this because RPRM is an unordered list?

 

Expanded Skyrim Presets ESPv1_1.esp adds a number of nice presets, but the rule of one is fisking up all all the other mods changes to the Race record. I was trying to sterilize ESPv1_1.esp.

 

Please add the RPRM - Preset NPC to the records that can be smashed. That is, if unordered lists are even doable. Thank you. I know you're deep in other projects, but I wanted to get this on the to-do list.