Mator

Hi, could you maybe join the Modding Tools discord? I provide most of my support there these days and it will make certain I can address your problems in a timely fashion. If I reply here I may not remember to check for a week so, yeah. https://discordapp.com/invite/GUfRdpT

That's not what he meant. He means if a plugin is added/removed, things will break. Similarly, if you update a mod with tree records/models in it, the LOD models may no longer match.

I've heard there's a version of MO1 and a version of NMM which can use the new API.

Sounds to me like you installed a module incorrectly in zEdit's modules folder. What folders are in that folder? If any of those folders doesn't contain a module.json file at the top level, the module is installed incorrectly. E.g. correct module installation: <zedit folder>\modules\unifiedPatchingFramework\module.json

It sounds to me like your issue has almost nothing to do with Smash, and everything to do with how you're managing your load order. Understand the following: - Every plugin you load into Mator Smash will be a master of the smashed patch. - If MO2 reports masters missing it means a plugin is not installed. - It is not possible for the smashed patch to have a plugin as a master which is NOT loaded at the time the patch is built. - It is not possible for the smashed patch to have a plugin as a master that ISN'T installed The key detail here is that you have two smashed patches in MO2. You can't do that if you're using the green quick patch button, as smash will just replace the existing plugin file in your MO2 mods folder. Delete or backup your smashed patches (so they are no longer in your MO2 mods folder OR are named differently) and make a fresh one. Your problem should disappear.

Yes, still under development and being maintained. Code page issues should be fixed in v0.5.4, which is available on GitHub.

Merges are stored on disk in a JSON file in the application directory. The only way for the merges to no longer be present is for this file to be deleted or corrupted. There's most likely no way to recover your merges if you did something that caused the file to be overwritten or lost.

Mod Picker entry approved, added image as well. I haven't tried this yet but I've heard nothing but good things.

DLLs are entirely different from papyrus scripts. There is no need to do anything with DLLs unless you have a mod with a DLL, and in that case you need the C++ source code for the DLL to recompile the DLL with visual studio. Messing with Visual Studio is not something I'd recommend for a novice programmer. You either already know how to do this or you have no business doing it.

First issue- you probably have a loadorder.txt file in %localappdata%\Skyrim Special Edition. Second issue- MO2 must be in portable mode to use the Mod Organizer integration in Merge Plugins.

PapyrusCompiler.exe is what will ultimately be compiling your scripts in most situations. Notepad++ is a good option, but those other options are probably decent as well. MO doesn't have any impact on script authoring. If you want to access scripts/sources as if they're in your data folder you will of course have to run your script editor/compiler through MO, but that's just standard for any program that you want to have accessing mod files managed by MO.

Some relevant discussions: https://www.reddit.com/r/skyrimmods/comments/5xh5b6/guide_manual_cleaning_master_esms_for_skyrim_and/ https://www.reddit.com/r/skyrimmods/comments/5xre7n/is_cleaning_master_files_useless_should_we_remove/

Renamed one to Advanced Recon Merged - 1.bsa and another to Advanced Recon Merged - 2.bsa

The "text descriptors" are generally the EditorID (which is unique) and FULL Name (which is not unique) of the record being referenced. And it depends on the context of what you're looking at. If you merged plugins then the values from the winning override in the plugins merged are what are used by definition. The fact that they don't line up in xEdit if you load the merged plugin and the plugins merged is only tells you that the referenced record was local to one of the plugins merged and was thus copied to the merged plugin (putting it at a different FormID) so the merged plugin can be used without having the plugins you merged active in your load order, per my previous post. You don't need to check the records in a merged plugin against the plugins you merged, unless there was a failure every record will be using the winning override for the plugins you merged. When building a conflict patch, which is different from a merged plugin in that it requires the referenced plugins as masters, you can and should refer to what xEdit calls conflicts.

There's nothing wrong here. The face parts that are being referenced were added in one of the plugins you merged. Merge Plugins copies records and renumbers conflicting FormIDs when merging plugins, these fields now reference identical face part records in the merged plugin (which is still a different "value" for the field, so xEdit detects it as a conflict). You would actually have cause to be concerned if everything lined up, as it would mean the merged plugin would have had one or more of the plugins you merged as a master.

I generally recommend against renaming plugins after you've merged them. There are assets which are at file-specific paths which you'd need to manually fix if you ever renamed a plugin file. So a revised approach would be: merge them, run relinker, don't rename. Bonus question: SEQ files are to boot up start-game enabled quests. I don't know if the game will load them if a plugin with a corresponding filename isn't active (probably not).

That is correct. There is no special handling for template fields in Smash.

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. 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. 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). 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. 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: --- 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. 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.

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. 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. 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. 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.

There is absolutely no good reason to use that script when using Mator Smash, use Bash.All instead. Bash tags are a thing of the past and make no sense with the algorithm Mator Smash uses. Support is only present to ease people's transition to the program and provide clarity in the differences. Using the detect bash tags script is pointless if you're using Mator Smash, using Bash.All will yield identical or superior results in a fraction of the time. If there's an issue with the logic in a Smash Setting that is provided with the program you should report it on GitHub. Currently I am the only person who builds/maintains smash settings that are available publicly, and I am also very busy actually programming, so my time is limited. The Bash.* smash settings are for legacy support/fallback if Smash.All doesn't work properly, and are a secondary concern. The tagging functionality in Mator Smash uses tags based on the group name. If the plugin description has {{BASH:TAGS,HERE}} then Smash will use tags from the Bash group. Cloning the settings will cause you to do even more work. This is why you should just use the program per the tutorial on the Nexus Mods mod page instead of carving out your own, entirely unnecessarily complicated workflow. Because your edits are in different Smash Settings that don't correspond to the tags in your plugin descriptions. The tag manager is also only present for legacy reasons and isn't intended to for heavy usage. You're going to get some weird results if you don't understand how Smash deals with tags, which you clearly don't. "For some unknown reason" - no, it is completely known. When Mator Smash is saving plugin files it does the following: 1. It renames the existing plugin file(s) to .esp.bak so you have backups in case it does something wrong/that you don't like. 2. It saves plugin files at the original filenames. If you have an antivirus/filesystem permission issue then the second step can fail. Also note that with MO the newly created plugin files may be put into the overwrite folder. Mator Smash uses the xEdit framework internally. The file size will change if you change the description of the plugins, which is exactly what happens when you apply tags through the Tag Manager. As I said before, you clearly have no understanding of how Mator Smash settings or tags work and need to go back and read the supplied information and watch tutorial videos. Tags are not Smash Settings. Tags are strings put into plugin descriptions which advise Wrye Bash/Mator Smash on how to perform conflict resolution. In Wrye Bash tags map directly to hardcoded logic, where in Mator Smash tags are mapped to Smash Settings based on the setting's name. However, using tags is absolutely unnecessary in Mator Smash and is not the recommended workflow put forth in every guide/video on how to use the program. Mator Smash can track the "settings" assigned to plugins internally within its own settings file (a JSON file which is saved in the program's installation folder). "Combined settings" are automatically assigned for plugins which have multiple tags in their description and have not been manually overriddedn to a particular Smash Setting by the user (as stored in the settings json file). "Combined settings" are pseudo-settings which are created at runtime by merging multiple other settings together, that's why they have a hash in their name. It is highly recommended to not use combined settings or tags in Mator Smash because this system was built for Wrye Bash which forwards subrecords/fields purely based on what tag is present. Mator Smash, on the other hand, only forwards fields that are detected to be changed based on load order and master dependencies. This means that applying the "Autodetect Bash Tags" script is exactly the same as just combining all of the Bash tags into a single smash setting (which is what Bash.All is, in case you were wondering) and using that. You are using it wrong. You just have no idea how to use the tool and you're applying old workflows to a new tool without actually understanding the power present. What you have said here is frankly insulting. You've basically said "this tool is **** and should have stayed in beta" in so many words. I am dissappointed in your absolute lack of interest in understanding how the tool works and jumping to your own conclusions based on poorly researched information. I don't know if anyone has been as rude to me in asking for support as you have been here in this post. Did you read the OP at all? Did you really do a google search for "Mator Smash"? The first two results on google are the Nexus Mods mod page and the old WIP Nexus Mods topic. Both places would be better than here, as this forum thread is specifically about discussing Smash's inclusion in the STEP guide. The OP in this topic ALSO links to the Nexus Mods page and to the old WIP STEP topic. I'm not sure how you decided this was the best place to post your rude complaint, but it was the absolute worst place you could have chosen.

I'll look into this Kneph, thanks for the report. For now you can just ignore the failures/forward things manually (you can use your own plugin asides from the smashed patch so you don't have to repeat the edits every time you regenerate the smashed patch). I've deleted your post on the other thread (try not to create duplication like that please!). - Mator

Merged patch != merged plugin. Merge Plugins Standalone does not allow you to merge merged plugins because it's an unnecessary layer of complexity. If all of the plugins can be contiguous in your load order then just put them all into one merge from the start. There's no good reason to have three merges as an intermediate step.

I don't really agree on it not making things easier or it requiring a lot of extra effort seeing as you have several other users you can tap as resources, per my previous post, but I can see why you might think that. Ultimately it's your decision, so do whatever you feel is best.

As I said before, some manual tweaking after generating the smashed patch is almost always required. The Smashed Patch isn't intended to be "click one button and done" unless you don't care about how it resolved conflicts (aka very lazy users). There are a large number of users who have been using the Smashed patch with the UP (successfully limiting what is forwarded from the UP) who I think you could consider reaching out to. It may be that you just need to make a single custom smash setting for the UP, or a custom patch which you include prior to/after running Smash which resolves the conflict(s) as desired. Off-hand, I'd recommend reaching out to Alt3rnity, Deorder, and DarkladyLexy.

Have you read the FAQ on the mod page? I believe it talks about load order and using the bashed patch. In short, this is the order you will generate things (and should be reflected in load order as well) Bashed Patch (active when generating the Smashed Patch) Smashed Patch Additive patches (DynDOLOD, ASIS, etc. with Smashed Patch and Bashed Patch enabled)