Mator

I haven't done any testing with Fallout 3 because I don't have it, so I can't provide any guarantees for functionality. You may have to adjust record/subrecord exclusion settings (probably not, but maybe).

Cool! Looking forward to hearing from you on how that goes! Yep, fireundubh told me to use it, so I'm using it. :) Smash kind of went to the back burner so I could work on Merge Plugins v1.8, but that's basically done now so Smash is now the center of my attention again!

Mator Smash VIDEO TUTORIAL - For v0.0.7 GamerPoets Video - For v0.4.1 Mator Smash is now available on Nexus Mods. Nexus Mods Mod Page As of v1.0.0, Mator Smash has a "Quick Patch" button As of v0.5.1, Mator Smash will copy records with "errors" in them (such as unresolved/unexpected references) As of v0.5.0, Mator Smash has new algorithm features and is more stable. As of v0.4.1, Mator Smash merges redundant plugins properly. As of v0.4, Mator Smash now produces complete record prototypes As of v0.3, Mator Smash supports Fallout 4 and Skyrim SE As of v0.2.2, Mator Smash allows you to modify tags on plugins from within the program. As of v0.2.1, Mator Smash has Smash Settings for Skyrim for every Bash Tag Wrye Bash offered for Oblivion. Changelog: Purpose Mator Smash is an application built on the xEdit framework developed to replace the primary functionality of Wyre Bash - the creation of patch files to combine (or merge) conflicting overrides to overcome Bethesda's "Rule of One". Wyre Bash used to provide this functionality in the days of Oblivion through the usage of bash tags, keywords that would be put in the description of the mod that would then tell Wyre Bash what types of records it should try patching. However, the current status is that Wyre Bash only provides this for a handful of record types for Skyrim, and this has been the case for quite a while now. There are several users (most notably Sharlikran) who have been working to update Wyre Bash's codebase to work with Skyrim, but it's been an uphill battle. As of now, it's not certain whether Wyre Bash will ever offer the same functionality it did in the days of Oblivion for Skyrim mods. That's where Mator Smash comes in. Why is this necessary? As per Skyrim's "Rule of One", any two mods that modify the same record but in different ways will conflict with each other in a way that can't be resolved asides from the creation of a compatibility patch. Because the number of Skyrim mods exceeds 40,000, there is no conceivable way to manually build enough compatibility patches to make every possible load order (or even a small fraction of them) work with each mod operating as intended. Mator Smash automates the most important part of the task of compatibility patch creation - the combining of conflicting edits. This is something that we've been needing for a very, very long time. How does it work? Warning: technical jargon ahead. Where Wyre Bash has separate procedures for the patching of individual record types, Mator Smash has a few generic procedures for the patching of ALL record types. This means that Mator Smash has, with very little development effort, achieved the capacity to patch more records than Wyre Bash has ever been capable of patching. This is achieved through a recursive traversal method which traverses override record structure, comparing subrecords between a master record, a source override record, and a destination override record. Upon the basis of this comparison, certain subrecords are written to the destination record while others are skipped and others are deleted from it. Development Status I began development of Mator Smash as a standalone application built on top of the xEdit API 10/18/2015. Here's the GitHub repository. Check out the design folder in the repository for various files relating to my design process. I'll be live streaming most of my development on livecoding.tv. I'll be streaming mainly on weekends 9:00AM-9:00PM PST. Because of major code reuse from merge plugins standalone, smash will be entering public beta very soon. Mator Smash is currently available as a proof of concept script (which is slow and lacking in features/a clean user experience). You can download v0.9.4 of that script here. This script can currently correctly patch a massive number of different types of records. FAR MORE than Wyre Bash or any other currently available solution, and more than any solution that has ever existed for Skyrim or any other game. Implemented Features Dynamic, flexible settings: Smash settings are comprised of a tree which has information on how records/subrecords should be handled. This will allow users to control how a patch is created on a per-subrecord basis. This will make smash relevant regardless of the nature of the mods being patched, or the game the mods come from. Each node (record/subrecord) will have the following data associated with it-Process: Whether or not smash should process this node and perform conflict resolution for it if a conflict is found.Preserve Deletions: If a mod deletes an element inside of this node, that deletion will be preserved in the generated patch.Treat as single entity: If a mod overrides any subrecord in this node, the entire node will be replaced with that mod's version of it.Chaining: Linking allows you to copy multiple side-by-side elements when any one of those elements changes.Override Deletions: Allows a plugin to restore deleted elements.Force Value: Forces values from a particular plugin to be used, and only allows plugins which require this plugin to perform further conflict resolution on affected records.Tags: As of v0.2.1, all Bash tags that were offered with Wrye Bash for Oblivion are now available for Skyrim. Smash will automatically detect tags and apply smash settings to the plugins that have them, assuming you have smash settings that correspond to the tags.Managed smashed patches: Patches you build will be tracked in the program, so you can quickly and easily rebuild them when your load order changes. You can also have multiple patches for your load order, if you feel that is desirable.Multi-language support: I built a really clean, extensible, and easy to use language system when I developed Merge Plugins Standalone. Smash will use the same language system to support multiple languages out-of-the-box. As a translator, all you have to do is make a text file to create a translation and have users install it in their lang folder. The rest is handled by the program.Fast and easy setting creation: Select some plugins to build a setting to specifically handle the conflicts they are capable of creating in a load order. Toggle or set flags for multiple nodes at once. Select similar nodes in a setting tree. Conflict resolution has never been quite so powerful, flexible, and easy. Planned Features Smash is now pretty much feature complete. Further development energy will be spent on porting it to a zEdit application mode, zSmash, which will include a new, streamlined workflow.

Sounds like an early exit, to me.

This is pretty cool. Keep up the good work! EDIT: Also, in response to "Improved conflict detection through the magic of mteFunctions", all I did in regards to conflicts is condense four already existing TES5Edit functions down to two and made the return type a string so comparisons, lists, and log messages are easier to work with. The real magic is in the handiwork of zilav. EDIT 2: Also, you should provide a link to download mteFunctions.pas for those people who don't have it (what blasphemy!).

I noticed the *.nxm registry keys on one of my passes through the registry. Thanks for the elaboration though. I think this could work if I still want to pursue this. Hi Grant, thanks for the reply. It is partly related to that post, but I was pursuing it prior to that post. I do actually provide the user with a file/folder selection dialog which retains the result for later executions, which the user can use to point to the desired folder. In addition to this I do have a "detect" button, which currently attempts to find Mod Organizer at some common installation directories. I just like to take the approach of doing as much for my users as I can. If there is a way I can find Mod Organizer's directory for them I'd like to, so as to avoid the possibility of them misunderstanding the way the script works and entering things incorrectly. Based on the current posts, however, I think it's best just to search a few more common directories (e.g. Skyrim folder) for ModOrganizer.exe, and leave it at that. If the user doesn't have Mod Organizer installed in any of the common locations they'll just have to use the DirectorySelect dialog to tell the script where it is. Cheers, -Mator

Hello, this is a programming related question. I'm looking to finding a way to automatically detect Mod Organizer's installation directory. Normally applications will create registry keys that note where they have been installed, but for my searching in my registry using RegEdit I wasn't able to find any keys that could be consistently used to determine Mod Organizer's directory. To be clear, I'm looking for a way to determine Mod Organizer's installation directory from within an xEdit script. My current approach is just a brute force approach of searching for ModOrganizer.exe in all subfolders in Program Files and Program Files (x86) on all valid hard disks. I would like to have a better way of finding it, but I'm not sure exactly how to do so. I know that Mod Organizer enhances the data directory using it's virtual directory structure. Is there any way to determine that this has occurred from within xEdit, and then determine Mod Organizer's installation directory? I'm working in Delphi and have the power to search directories, read registry keys, open files/folders, etc. I want a better solution than my current solution, but I also don't want to search entire hard drives (because that will take forever). Does anyone (e.g. Tanin) know of a way that I can go about achieving this? Regards, -Mator

Cooooooool. If you want some help with your script, Sheson, just let me know. I'd be happy to help optimize things/make things a little bit cleaner. Also, I give you permission to distribute the most up-to-date version of mteFunctions.pas with DynDOLOD, if you so wish. You can find that here: https://github.com/matortheeternal/TES5EditScripts/blob/master/trunk/Edit%20Scripts/mteFunctions.pas

version 1.4 released! It's better. A lot better.

This is pretty well established in the testing thread. https://forums.nexusmods.com/index.php?showtopic=1033740

You have a good point. If people read the generous amount of information I have provided, however, they should not suffer too greatly from its magical merging powers.

Oh I don't deserve a badge. I'll wait until I've released a few more useful things, then I'll feel like I oughta have one. ;} -Mator

Cool, thanks for posting this. :) I'll be working on merge functionality more in the future, with some help from the TES5Edit team, to hopefully make merging more mods possible. I think it'd be really cool to be able to merge your entire load order down into "category" ESPs for the types of mods you're running. It'd make things really clean. ofc, the problem with this approach is updating mods would be a ***** (want to update something? make a new merge file!) and if you want to remove a single mod you have to make a whole new merge file, but I still would totally do it if it was possible. EDIT: Oh and, if you guys haven't seen it, I've started a pretty handy testing thread for merge testing. https://forums.nexusmods.com/index.php?showtopic=1033740