[WIP] Mator Smash - Beta Testing

[Mator]

Description:

Mator Smash is a TES5Edit script which generates patch files that handles conflict resolution between multiple ESP/ESM files.  Think Bashed Patch, but handling all record types, sort of like how bashed patches worked in the TES4 Oblivion days. 

 

Say, for instance, you have an ESP which modifies the way weapons sound, and another which modifies their visual models.  Because of how Skyrim handles override records, the mod that is lower in your load order will override the changes of the one the precedes it, leading to some changes (either the new sounds or new visual models) to be lost.  This can be handled by creating a "compatibility patch", which is an ESP file which combines the edits of multiple overrides into a single record, thus preserving all changes.

 

Mator Smash is a solution that will make compatibility patches for you.  Simply load some mods into TES5Edit and run the script, and a compatibility patch will be generated for the loaded mods.

 

 

Installation and usage:

Download the latest version of mteFunctions.pas and the latest version of Mator Smash (v0.7).  Install both of these into TES5Edit's Edit Scripts folder.  Run TES5Edit and load some mods (preferably not your entire load order, if you want things to go quickly).  Right click on any file and click Apply Script.  Choose Mator Smash from the dropdown menu and click OK.  When prompted, enter the name you want to use for the generated patch file.  The process may take awhile (and will take considerably longer if the debug booleans are enabled).  Please report any errors/issues in this thread or the one on Nexus Mods.

 

 

Technical:

There are some constants that you can adjust to alter how the script runs.  In the script's source code you should see near the top a "const" section.  You can change the values of variables here to adjust how the script runs. 

• There are three debug booleans that will cause the script to print more messages to TES5Edit's message log if set to true.
• signaturesToSkip is a list of record signatures that the script will skip.  You can add record signatures to this if a particular record type is causing problems  (e.g. CELL).
• subrecordsToSkip is a list of subrecord paths that the script will skip.  You can add subrecord paths to this if a particular subrecord is causing problems (e.g. NPC_ \ ACBS - Configuration)

This script is a work in progress.  I can't guarantee the accuracy or correctness of patches it generates, or that they will even work with your Skyrim load order.  The script will eventually be expanded to work with other games (e.g. FNV, FO3, TES4), but is currently only tailored to work with Skyrim.

 

 

Resources:

Nexus Mods testing thread

GitHub repo

puu.sh download (v0.7 beta-2)

[Hana]

Sweet! Thanks for coming to our little corner of the internet with this. I rarely read Nexus Forums but this did catch my eye.

 

Had a couple of questions;

 

1. If I understand this correctly this could be used to create a "bashed patch like" patch that'll merge records for multiple (all) mods that touch the same record types? And/or to create a compatibility patch between two mods? Depending what you load up in TES5Edit?

 

2. I just recently made a mod that touches Race records, which I know will not work well with any other mod that touches Race records. This is the magic cure? I could make my mod compatible with, for example, the USKP, without making it a master?

[Mator]

1. If I understand this correctly this could be used to create a "bashed patch like" patch that'll merge records for multiple (all) mods that touch the same record types? And/or to create a compatibility patch between two mods? Depending what you load up in TES5Edit?

Yes, that is correct.

2. I just recently made a mod that touches Race records, which I know will not work well with any other mod that touches Race records. This is the magic cure? I could make my mod compatible with, for example, the USKP, without making it a master?

Yes, exactly! It's still very beta, so you should check to make sure it's doing what you expected it to do. I'm still taking in bug reports and other such things to tweak how it works to make sure the patching is happening the way we all expect and want it to.

[Arthmoor]

Is there any advantage to using this vs the built in "Merged Patch" function? Had there been any consideration for improving the built in code, or was that more of a pain than it would be worth?

 

Does your script read Bash tags from the mod's description if they exist? My main beef with the "merged patch" feature is that you can't get it to selectively forward things the way Bash tags would let you do it. Tag support would really go a long way toward getting the desired results since that's what made Bash shine in the previous games.

 

And following on from that, any chance you might take a look at the script that does Bash tag detection?

[Mator]

Is there any advantage to using this vs the built in "Merged Patch" function? Had there been any consideration for improving the built in code, or was that more of a pain than it would be worth?

 

Does your script read Bash tags from the mod's description if they exist? My main beef with the "merged patch" feature is that you can't get it to selectively forward things the way Bash tags would let you do it. Tag support would really go a long way toward getting the desired results since that's what made Bash shine in the previous games.

 

And following on from that, any chance you might take a look at the script that does Bash tag detection?

Hi Arthmoor.

The Merged Patch function only handles LVLI records. This handles all records of all types.

I don't know how the Merged Patch code works, but my work on Mator Smash is currently far too beta to be incorporated as a hardcoded function into TES5Edit. I have no idea where the existing code for "Create Merged Patch" is, or how I'd even go about doing things at that level in TES5Edit. Making a userscript is the best way for this to proceed, for now.

My script will use Bash tags at some point in the future. It doesn't yet, but it will. For now the goal is just to get it to handle the version control of all records correctly. Once that's been achieved, I'll move on to stuff like Bash Tags and other more advanced features.

I'll take a look at the existing Bash Tags script. It might do some stuff that I can learn from. My approach is very different, however, to that of Bash. My approach is to handle all subrecords of all types using a recursive function that iterates through subrecords. This sort of approach means that I don't need to make functions for handling each type of subrecord (e.g. LVLI entries, NPC_ ACBS - Configuration, COBJ Items, etc.). Internally, all subrecords have only one of a certain number of types. If you can make a generalized approach to all of these definition types, you can handle all subrecords.

Essentially, I can do in a few hundred lines of code that which was previous done in thousands of lines of code.

[Arthmoor]

The main reason for tag support though is that not every mod is desirable to merge into a conflict resolution patch. Tags allow that to be done selectively. Which is likely why such things take thousands of lines of code to pull off

 

I'll certainly play around with what you have though since it appears as though it's much more thorough than the current hardcoded Merged Patch function. Which, btw, handles way more than just leveled lists. You're probably thinking of Bash in that case (though Bash does the Names and Stats tags too).

[Mator]

The main reason for tag support though is that not every mod is desirable to merge into a conflict resolution patch. Tags allow that to be done selectively. Which is likely why such things take thousands of lines of code to pull off

 

I'll certainly play around with what you have though since it appears as though it's much more thorough than the current hardcoded Merged Patch function. Which, btw, handles way more than just leveled lists. You're probably thinking of Bash in that case (though Bash does the Names and Stats tags too).

 

Here's what's currently supported and what will be supported in v0.8 (locally means on a per-file basis).

• Customizing which mods are conflict resolved: only open the mods you want to handle with a conflict resolution patch.
• Customizing what records are conflict resolved (globally): can be handled with a constant in the current beta.
• Customizing what subrecords are conflict resolved (globally): can be handled with a constant in the current beta.
• Customizing what records are conflict resolved (locally): will be done through a GUI in v0.8.
• Customizing what subrecords are conflict resolved (locally): will be done through a GUI in v0.8.

Even with all of the customization I'm planning, it's still going to be done in less than 1000 lines of code.  The current script is a mere 305 lines, currently.

 

 

When I run the "Other -> Created Merged Patch" function in TES5Edit, I only see it handling LVLI records.  Maybe the mods I was testing just didn't have the right types of records, I dunno.

[Hana]

Thanks Mator. I should have a chance to test it over the next few days.

[Arthmoor]

When I run the "Other -> Created Merged Patch" function in TES5Edit, I only see it handling LVLI records.  Maybe the mods I was testing just didn't have the right types of records, I dunno.

Could also be that that's all that conflicts for your load order. I know mine doesn't produce much with a Merged Patch either. Just leveled lists and one NPC.

[Mator]

Could also be that that's all that conflicts for your load order. I know mine doesn't produce much with a Merged Patch either. Just leveled lists and one NPC.

Here, I grabbed the source code for Create Merged Patch from the latest svn:

http://pastebin.com/YWhVA7gw

 

The important information is at the end, with the groups and subrecords it handles.  So yes, it does handle more than I thought it did.  However, Mator Smash is (hopefully) going to be an interstellar leap upon this, because it's being developed to handle everything.

[Mator]

v0.7 beta 2 is out.  MergeArrayElements should now be working correctly.

 

Edit: Found a slight issue with array elements getting copied incorrectly (you'll have a duplicate instead of a particular element) in certain very specific circumstances.  I was only able to reproduce it with NPC Tint Layers.