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.