Mator Smash (by Mator)

[mentaltyranny]

Mator, I'm sorry if you took it as rude, but please look back and consider that I didn't use bloated language for anything.  I am actually a big fan of your tool, and I do hope it is included in STEP as a replacement for Wyre Bash.  I did read the main forum topic for Mator over the last several months, if you look back at it I posted several times (I actually meant to post there, see below).  

 

I am sorry if I did come off as rude, but please under that I am spending hours trying to restore my mod setup to what it was prior.  That can be frustrating considering the lack of written guides on Mator Smash.  I don't like videos because I am physically disabled and I can't keep up with them.  I move very slowly (I am typing this now with an onscreen keyboard), and very deliberately.  I am sorry if I used your program wrong, but I have not been very satisfied with the default "smash.all" settings like many here on the STEP forums.  Please don't take this as un-constructive criticism, but I think one of the powerful aspects of Wyre Bash (especially during the Morrowind and Oblivion days) was the fact that you can assign different settings "tags" to different mods.  From my understanding Wyre Bash only ripped the settings associated with that tag out of each tagged mod (obeying Rule of One if there was overlap), and combined those settings with the winning records for each load order.  Your tool clearly has the power to this again, but I feel like your settings lead to results similar to if you applied every tag to every mod in Morrowind or Oblivion.  In fact, I think the patch I built this "wrong" way looks significantly better in xEdit compared to smash.all.  I know you disagree, but again I ask why didn't Wyre Bash apply every tag to every mod?  There was some rational for not doing so...

 

That said, I had some real bugs that I think you missed when you first read my earlier post.  Granted I am not an expert by any means, but I am no novice either.  This my 5 Bethesda game I modded, and I am modding Skyrim for the 3rd time.  So please don't think I installed Skyrim in a system Program folder or can't tell to check antivirus logs or quarantines.  Here they are again in more detail:

• Have ".BAK" files in every mod - keep in mind only 60 of my 143 plugins have tags and associated settings; the rest I have no tags and set to skip (a part of my trial to build a better patch)
• USLEEP plugin missing - so far this is the only one missing, I am half through scanning the mods folder in MO to see if anything else is missing; again, Skyrim is installed on a non-system drive and there is nothing in my antivirus logs
• Official High Resolution Packs in Overwrite and missing for vanilla data folder - again, strange because they had no tags or settings, and I applied neither to them
• Modern Brawl Bug Fix - size mismatch between the .esp and .bak file, again this is weird because I had it skipped and had no tags on it

Finally, yes I am aware of the nexus site.  But that is generally there for support... I am smart enough to know how to fix this myself; that is not what I am looking for.  Instead, I was looking for a development forum so I could report the event for future development.  Since there is no official website or community for this tool that I could find, I thought this might be the best place to report this without it getting drowned in requests of people unable to figure out the quick patch button.  But it looks like I made a mistake, I meant to post it on the much larger official thread.  Somehow I lost the original forum when I transferred my reply to my cell to finish at work... Sorry I was wrong...

 

Again, please understand that I am not expecting you to do anything with your freely provided tool.  I appreciate the work you do for free; it is not lost on me!

Edited June 20, 2018 by mentaltyranny

[Mator]

I am sorry if I used your program wrong, but I have not been very satisfied with the default "smash.all" settings like many here on the STEP forums. Please don't take this as un-constructive criticism, but I think one of the powerful aspects of Wyre Bash (especially during the Morrowind and Oblivion days) was the fact that you can assign different settings "tags" to different mods. From my understanding Wyre Bash only ripped the settings associated with that tag out of each tagged mod (obeying Rule of One if there was overlap), and combined those settings with the winning records for each load order. Your tool clearly has the power to this again, but I feel like your settings lead to results similar to if you applied every tag to every mod in Morrowind or Oblivion. In fact, I think the patch I built this "wrong" way looks significantly better in xEdit compared to smash.all. I know you disagree, but again I ask why didn't Wyre Bash apply every tag to every mod? There was some rational for not doing so...

Because there is absolutely no reason to do conflict resolution in that way. It simply doesn't make sense. If you look at records and consider how conflicts should be resolved it doesn't make sense to overwrite changes with unchanged values in 99.9% of situations. In the 0.1% of exceptions it is usually a case of needing to link subrecords together (e.g. NPC face related subrecords). In every other situation it's simply wrong. I don't know what metric you are juging the Bash tag approach as performing better conflict resolution, but without an actual example to respond to all I can say is I strongly disagree. The methodology of Bash tags was deeply flawed in that it:

 

1. Would forward unchanged values in situations when they shouldn't be forwarded.

2. Did not scale well and required hardcoding algorithms into the application for handling different subrecords, an unmaintainable task.

3. Put a heavy workload on mod users/authors to properly "tag" mods when the tags were at best poorly documented. In trying to replicate them I found little-no information on how they actually worked internally, and Wrye Bash's codebase is a total mess so I wasn't about to try to dig through it to find out.

4. Polluted plugin descriptions with esoteric "tags". It was a decent way to do things if a distributed rule system (a la loot) was out of the question, but it's ineffective unless a majority of authors are tagging their mods properly. This assumes that authors know how to tag their mods (which is made more difficult by the complexity of bash tags) and that they know that they should tag them. In a game like Skyrim neither of these are the case because Wrye Bash was never updated to support more tags than a few basic ones.

 

You've made a lot of strong claims against my program, but you have yet to provide any actionable evidence that I can work with. This puts me in a situation where all I can do is accept what you're saying on face value and ask for more information (which you should have provided in the first place) or disagree with you and tell you that you're incorrect. To have a more productive conversation where we both get what we want you absolutely need to provide specific, actionable information.

 

That said, I had some real bugs that I think you missed when you first read my earlier post. Granted I am not an expert by any means, but I am no novice either. This my 5 Bethesda game I modded, and I am modding Skyrim for the 3rd time. So please don't think I installed Skyrim in a system Program folder or can't tell to check antivirus logs or quarantines. Here they are again in more detail:

• Have ".BAK" files in every mod - keep in mind only 60 of my 143 plugins have tags and associated settings; the rest I have no tags and set to skip (a part of my trial to build a better patch)
• USLEEP plugin missing - so far this is the only one missing, I am half through scanning the mods folder in MO to see if anything else is missing; again, Skyrim is installed on a non-system drive and there is nothing in my antivirus logs
• Official High Resolution Packs in Overwrite and missing for vanilla data folder - again, strange because they had no tags or settings, and I applied neither to them
• Modern Brawl Bug Fix - size mismatch between the .esp and .bak file, again this is weird because I had it skipped and had no tags on it

• Smash does not save plugin files (which includes creating bak files) unless you change them. You clearly misunderstood how an option in Smash works. If you were to provide me with a full and accurate description of what you did to create this result I could respond in more detail. As a quick test I tried to use the manage tags modal to apply tags to a single plugin and closed Mator Smash and it did exactly what is expected: it renamed to the .bak extension and saved a new version of it. I can't address a problem unless it is properly reported, and the correct place to report issues is the GitHub issue tracker, per the Nexus Mods page.
• Don't know what to tell you. There isn't any code in Mator Smash which explicitly deletes a plugin file. If a plugin file dissappears it pretty much can't be anything but user (or system) error. If you redownload the plugin file and can recreate the issue with step-by-step instructions for repeating it I'll look into it, but I'm very doubtful. At the very least the .bak file should be present.
• As I mentioned in my first note, I tested using manage tags to apply tags to a single plugin file and it didn't save/mutate any other plugins.
• You can restore the originally installed plugin, mark it as modified in xEdit, and then save it. It's hypothetically possible for there to be unused data in the plugin file which xEdit strips. Mator Smash does not contain any code which actually saves plugin files - that is handled entirely by the xEdit framework which Smash has statically linked within the executable.

Finally, yes I am aware of the nexus site. But that is generally there for support... I am smart enough to know how to fix this myself; that is not what I am looking for. Instead, I was looking for a development forum so I could report the event for future development.

That's what the GitHub issue tracker is for. Also, the Nexus mods mod page is for all discussion relating to Mator Smash. It makes my life a little easier if all discussion takes place in one place, though I greatly prefer GitHub's issue tracking functionality of the one on Nexus Mods so I use it instead. Regardless of what your reason for posting is, saying that you are dissappointed in a tool and feel it should have stayed in beta is very unproductive. At best you will insult someone, and at worst they won't help you at all. Don't do that if you want me to help you. I generally don't give a **** and like to help people, but I will draw a line when people are explicitly rude/nasty.

 

Since there is no official website or community for this tool that I could find,

I haven't heard of a single tool in the skyrim modding community that has an official website or community. It happens for larger projects like Beyond Skyrim which require large-scale coordination with a big team, but that's not the case for most modding tools. There is, however, an official discord for modding tools in general which I run. It has a channel for Mator Smash. It may not work for you given your unique circumstances but it's an option.

[mentaltyranny]

Okay, I think I know what caused this... in order to apply my new graphics tag and to reduce clicks (right clicking is difficult for me), I highlighted every plugin after the official plugins (unfortunately I highlighted the official high resolution pack as well, as LoS & USLEEP come before them in my load order, per STEP) and right clicked into "tags" then "manage tags".  For any mod that the detect bash tags detected bash.graphics, I replaced it my lash.graphics tag, making sure that my "Apply combined setting" checkbox was ticked.  Your program started with the first mod highlighted LoS, then automatically moved to USLEEP, ect., saving me tons of right clicks.  For any mod without a bash.graphics tag (or no tags at all), I clicked "cancel" which moved me on to the next highlighted mod.  I thought "awesome!," as it saved me hundreds of right clicks for my non-Bethesda mods of 138 plugins (135 if you exclude High Resolution Pack).

 

When I was done, I rebuilt my patch with the new settings, everything looked great... until I got back to MO, and had missing .esms/.esps errors, bloated data file with .BAKs, and the high resolution patches were in overwrite (which, again, is weird because I clearly did nothing to them tag-wise; I clicked "cancel" for all three).  Keep in mind that I have a high-end rig, a STEP setup to the "Based Patch" with a handfull of mods from Kelmych's Magic Pack Ideas, and I no better than to do newbie mistakes.

 

Finally I came here a little more frustrated than I should have...  I am sorry if my comment regarding beta insulted you, that was not my intent.  Rather, I generally feel programs should be in beta that have bugs with unforeseeable consequences, such as these.  Your comment saying that I am not using the program correctly and I was using dated, "legacy" functions only reinforces this idea in my mind.  I am wrong about version conventions, I am sorry.  But just because I feel that MS should be in beta, does not mean I would not use it... I use lots of beta mods and tools... Nevertheless I take extra precautions with beta software, and I wish I had done so here.  It took me hours to get my mod installation correct again and verify all plugins.  Tried replicating the problem at a smaller scale, but it didn't appear.  I don't want to do it at a large scale because of how long it took me to fix.

 

Again, please don't think I am insulting you, being a non-expert, non-newbie, I would have serious concerns with the community at large using your program.  There is apparently a lot that can go wrong if they "explore" the program, and I am not very happy with smash.all, albeit it is better than Wyre Bash alone.  I actually really like the edits from the last patch I built with automatic tag detection (I used recent fireundubh version) and making a handful of adjustments, but it is still quite limited scope.  I would love to see the settings you quoted from Deorder, as I have a logical mind (I am an attorney) and they sound better than what I am doing.  I am surprised that there is not more sharing of these settings, because save for an error or two (like missing BODT - Body Template data I reported to the main forum), the quick patch behaves correctly.  In my opinion, it's just stripping out these legacy settings and the logic in the settings that need work. 

 

Nevertheless, the program is amazing, i just don't know enough enough about the differences between preserving and overriding deletions, and what force values mean (I can figure out what treat as single entity is).  I also wish I understood how master plugins affect MS logic.  In other words, what is the difference in MS application of conflicts and overrides in the same subrecord in these situations:

• Game loads esm A, then esp B, and then esp C, and the subrecord has different values for each, will smashed patch have this record, and if so, which subrecord one does use?
• What if B as A as master, but C has the same value as A?
• What if C as A as master, but C has the same value as A?

Yes, this is all well, well beyond the scope of the topic.  But I can't find documentation anywhere... maybe I just can't find it.  But I really don't want to watch hours of video either, so maybe it is me.

[Mator]

Okay, I think I know what caused this... in order to apply my new graphics tag and to reduce clicks (right clicking is difficult for me), I highlighted every plugin after the official plugins (unfortunately I highlighted the official high resolution pack as well, as LoS & USLEEP come before them in my load order, per STEP) and right clicked into "tags" then "manage tags". For any mod that the detect bash tags detected bash.graphics, I replaced it my lash.graphics tag, making sure that my "Apply combined setting" checkbox was ticked. Your program started with the first mod highlighted LoS, then automatically moved to USLEEP, ect., saving me tons of right clicks. For any mod without a bash.graphics tag (or no tags at all), I clicked "cancel" which moved me on to the next highlighted mod. I thought "awesome!," as it saved me hundreds of right clicks for my non-Bethesda mods of 138 plugins (135 if you exclude High Resolution Pack).

OK, so there's a slight bug with clicking Cancel in the tag manager still marked the plugin as modified. That can and will be fixed in the next version.

 

Finally I came here a little more frustrated than I should have... I am sorry if my comment regarding beta insulted you, that was not my intent. Rather, I generally feel programs should be in beta that have bugs with unforeseeable consequences, such as these.

All programs, regardless of whether they're labelled as "Alpha", "Beta", "Final", or not labelled at all will have bugs. It's the simple reality of software development. Smash was in alpha/beta for over two and a half years. Rather than having a perpetual "Beta" application without a Nexus Mods page (which would not have allowed me to get enough feedback to fix problems) I chose to release it publicly and create a Nexus Mods page. Without people using the program I can't find out what's broken. So suggesting that it should have remained in Beta is both unconstructive and unrealistic. It shows a massive lack of understanding of Smash's history or my motivations for the public release. When you also consider the huge number of users who have been using Smash to great success and absolutely love the functionality (including high level power users such as yourself and old-time modders who used Wrye Bash heavily, e.g. Alt3rnity), suggesting it should have remained in beta is even more rude, showing a degree of self-centered and self-righteousness which doesn't take into account the big picture beyond your own personal experience.

 

Don't get me wrong, I absolutely understand how the tool doing something you didn't expect which caused you to have to do a lot of manual work is frustrating. I just think that taking out that frustration on me/other users of the tool is unproductive. You were using a functionality which is not a part of the standard workflow using the tool, and using it in a unique fashion (multi-selection). Because of these unique circumstances you encountered functionality that was unexpected to you which the greater majority of users have never and will never encounter.

 

gain, please don't think I am insulting you, being a non-expert, non-newbie, I would have serious concerns with the community at large using your program. There is apparently a lot that can go wrong if they "explore" the program, and I am not very happy with smash.all, albeit it is better than Wyre Bash alone.

You say that there is "apparently a lot that can go wrong if they explore the program", but so far we've only identified a single problem which happens in a very specific use case which the majority of users will never encounter. Unless you provide other examples of issues, that is simply a massive exaggeration with no basis in reality.

 

The community at large has been using Mator smash, and they have been using Smash.All and they have been very happy with it. Your experience is not at all indicative of the average experience of users of Mator Smash. I strongly encourage you to go and read the comment section on Nexus Mods to see what percentage of users are happy with the result as well as how effectively and respectfully I've been responding to issues. If you really want to make large claims about the software you should do your research and back them up with data drawn from a sample size larger than one (viz., your own experierence).

 

I actually really like the edits from the last patch I built with automatic tag detection (I used recent fireundubh version) and making a handful of adjustments, but it is still quite limited scope.

It is important to understand the following:

 

1. Smash removes ITPO (identical to previous override) records from the smashed patch because they are redundant, so it will almost always have fewer records than a comparative Bashed Patch (when using Wrye Bash for a game where all tags are supported and all mods are tagged).

2. Bash.All only resolves conflicts that correspond to Wrye Bash rules. Any conflicts outside of these rules are not handled. That's what Smash.All is for. If you want more conflicts to be resolved you should use Smash.All.

3. Using the Autodetect bash tags script from Fireundubh is identical to using Bash.All in Mator Smash. Your workflow simply doesn't make sense.

 

I would love to see the settings you quoted from Deorder, as I have a logical mind (I am an attorney) and they sound better than what I am doing.

You can contact him directly if you want him to send them to you/chat with him about using Smash settings, but here is what he has said about them:

 

So I removed all my handmade / combined settings and only started using Smash.All, actually by cloning it and calling it Custom.All + some extra modifications ("Leveled Lists" to use "Override Deletes", remove the "CELL" node so changes from only selected plugins are forwarded). This seems to do the best job. Better than using Smash.All + Bash settings. I then only had to create several versions of Custom.All. For USSEP (to forward some NPC_ cleanup scripts, CELL water directions etc.), CRF (some small things), Luminosity (to forward CELL light and lightingtemplate) and Immersive College of Winterhold (to forward CELL flags, owner and music). Everything else seemed perfect. I think I could not have done it any better by hand.

 

Sometimes it is just a matter of deciding which mod you want to have priority, especially at places where conditions are involved. Deciding which mod you want to be active for certain / most NPCs or items.

If Smash.all setting does not do what you want I find it best to clone it, call it Custom.all and remove the nodes from the setting I do not want it to forward. For example, the CELL signature / node is a good one to remove from Custom.all. I use this setting on all plugins by default. Then I create separate settings that are a combination of Custom.all + the extra elements / nodes that I want to be forwarded for certain plugins, like USSEP, CRF, NPC, Light, Weather, WeatherLight etc. Smash.all is a good base to start from, but it is even better if you modify it a bit as is required to get the best result.

---

 

I am surprised that there is not more sharing of these settings, because save for an error or two (like missing BODT - Body Template data I reported to the main forum), the quick patch behaves correctly. In my opinion, it's just stripping out these legacy settings and the logic in the settings that need work.

BODT issue is known, it's in the GitHub issue tracker. And yes, stripping out legacy settings and logic should be done to make the workflow more streamlined and discourage using the program in sub-optimal ways. I thought I had done most of that for the official release but I didn't remove the tagging stuff.

 

Nevertheless, the program is amazing, i just don't know enough enough about the differences between preserving and overriding deletions, and what force values mean (I can figure out what treat as single entity is). I also wish I understood how master plugins affect MS logic. In other words, what is the difference in MS application of conflicts and overrides in the same subrecord in these situations:

• Game loads esm A, then esp B, and then esp C, and the subrecord has different values for each, will smashed patch have this record, and if so, which subrecord one does use?
• What if B as A as master, but C has the same value as A?
• What if C as A as master, but C has the same value as A?

Yes, this is all well, well beyond the scope of the topic. But I can't find documentation anywhere... maybe I just can't find it. But I really don't want to watch hours of video either, so maybe it is me.

 

There isn't any real documentation currently.

• If Preserve ITPOs is not enabled the Smashed patch will remove the record because it will ultimately be the same as the previous override. This assumes the subrecord is not in an array and is marked as "treat as single entity" or has only one field which was changed.
• Slight problem here, both B and C should have either A or an earlier esp/esm as a master (which we could call A') in order for them to be overriding the same record (causing a conflict that smash would be resolving). If both B and C have A as a master, and B changes the value relative to A but C does not, the smashed patch will not remove the record and it will have the subrecord from B.
• The short explanation is "smash only forwards values/subrecords when a change is detected relative to the previous version of the record the plugin has knowledge of, as determined by its masters".

So if you have the following:

A.esm

B.esp (has A as master)

C.esp (has A as master)

D.esp (has A and B as master)

 

Changes for records in B.esp and C.esp will be recognized relative to the values in the master record in A.esm. Changes for records in D.esp will be recognized relative to values in the override record in B.esp if it is present, else they will be recognized relative to the values in the master record in A.esm.

 

Override deletions forces deleted elements to be restored even if the previous override does not have the element deleted. Example:

 

A.esm (has FULL)

B.esp (has A as master and deletes FULL)

C.esp (has A as master and has FULL at same value as A.esm)

D.esp (has A as master and has FULL at same value as A.esm)

 

Without override deletions, the smashed patch will have FULL deleted. With override deletions FULL will be restored when smash is processing the override in C.esp, and if the record is ITPO it will be removed. Alternatively:

 

A.esm (has FULL)

B.esp (has A as master and deletes FULL)

C.esp (has A as master and has FULL at same value as A.esm)

D.esp (has A and B as masters and has FULL at same value as A.esm)

 

In this situation, even without override deletions enabled FULL will be restored to the value in D.esp and if the record is ITPO it will be removed.

 

In general, every change (deletion, creation, value changed) is detected relative to the most recent override of the record (per load order) the plugin has knowledge of (per its masters). When a change is detected, it is forward to the smashed patch. Smash starts by copying the winning override to the smashed patch, processes changes in all overrides prior to it, and then processes changes in the winning override.

[straylight]

A great tool. Just here to say thanks! Unfortunately, I'm also in the process of ESL'ifying many mods, so Smash isn't up to snuff with those just yet. Looking forward to an update.