Merging Plugins

[smr1957]

WARNING! Merging plugins requires experience - a LOT of it! If you are unsure of something - DON'T DO IT. And if you lack experience, then keep things small.

Thanks to cfs111 for his post regarding this, as well!

Recently, I have noticed a large number of people asking abouty merging mods. I had put this together in answer to a previous question in another thread, and think it worth posting on its own.

Merging mods is just about the last step in the learning process of handling mods and requires advanced planning of exactly how you are going to be constructing your build. The reason for this is that one of the prime requirements for merging mods is that you have a completely stable, nonconflicting game. Every mod that you are going to merge together should be known to work with not only the mods you are merging with it, but also with every other mod in your load order. In addition, your load order should be finalized to the point that you will not be removing mods from it - every mod in your load order should be pretty much set before you begin merging mods. You may want to add more in, but you should not be taking any out (and any that you may add, should be tested on a clean, test save to ensure that they will work with all the others).

Another thing (at least for myself), mods should be edited for compatibility - especially ones that you wish to merge - prior to the merging process, and this is pretty much the most advanced thing you can do with TES5Edit (in fact, I don't recommend it at all for anyone who is not totally experienced and comfortable using TES5Edit).

The safest mods to merge are patches that effect one mod so that it can work well with others - and these are usually the most numerous mods in an individual's load.

Finally, when merging plugins, it is important to note that all the plugins need to be adjacent in the load order, so after you have edited for compatibility, moved the mods together so that they are all adjacent, and rechecked for compatibility - if due to a compatibility issue, some mods come before a particular non-merge mod and others after that particular non-merge mod, that would be a case of making two merged plugins - one to be placed before that particular mod, and one after.

As to where the final merged plugin goes in your load order, it depends upon what files have been merged together - if the files are all from an early part of the order, the merged patch should be placed early (in a place that corresponds as closely as possible to the location of the original files); if files were towards the bottom, than the bottom (again in a location closely corresponding to position of the parent files).

To put it all together:
1. Ensure that your load order and all the mods are stable and do not cause any problems.
2. Finalize your load to the point that you will not be removing any mods.
3. Ensure that everything is compatible and all or any patches necessary are present in your load.
4. Test the game. If it runs with no problems, make a hard (manual) save and keep it as a backup, just in case you have to roll back.
5. Select the mods you wish to merge - and keep it simple. IMPORTANT NOTE! If any of those mods have .BSA files, the BSAs MUST be unpacked - you can only merge loose files.
6. Merge - and once merged, reload merged file in xEdit and check for any errors.
7. Install and place the Merged file in the proper place in your load order.
8. Test to ensure that everything functions as it should with the merged file installed.
9. Play and enjoy

To help with things, I found these vids
https://youtu.be/2F19Do8HAl4
https://youtu.be/0S6cpCwTezE
https://youtu.be/PCB0oJG9yQQ

Also see:
Merging Plugins by cfs111
https://steamcommunity.com/app/489830/discussions/0/2264691750486479016/?tscn=1588290920#c2264691750486479354

FAQ:

"When I start condensing, and fixing conflicts, in xEdit, couple questions:
Best practice, use WryeBash first to let it combine what it can in a bashed patch, then go to xEdit to get comfortably under the 255 limit?"

If you are merging mods, only use Wrye Bash to merge Leveled Lists - do NOT use it for the purpose of merging plugins - that should only be done using xEdit or the standalone Merge Plugins tool. However, should you find yourself merging with Wrye Bash, do it first and also be aware there is a major caveat: make sure that the mods that get merged into the Bashed Patch do not undo any changes another mod makes due to Bashed Patch being placed last. Perfect example is Tiwa Minidresses. They can be merged into the Bashed patch, but if you are using Modest Elderly, doing so will undo the changes that Modest elderly makes.


"If I have multiple texture mods, each one modifying a different item, I should merge those together since there won't be conflicts, and it reduces the mod load?"

A) The first thing you should merge are multiple patches for a mod (e.g.- a mod has 5 patches to make it compatible with others, merge those 5 patches)
B) merge all the little tiny bug fixes or small stuff whose position in the load order is irrelevant (as determined by no conflicts in xEdit), and which is unlikely to be updated.
C) despite what people say, it is totally irrelevant what mods you place together when merging (though some should not be merged - Arthmoor warns against merging his town mods, so don't)
D) Although any mods may be merged, I do tend to merge mods which are alike - but strictly for personal housekeeping purpose and to make it easier to locate particular individual mods.

And, the most important for last. Make sure that the entire load order is compatible BEFORE merging! This cannot be emphasized enough! If you are not that familiar with a mod and are unsure of it, don't merge it. Also, if it is likely that a mod will be updated, again, don't merge it (unless you don't care what the update does).


"Can I merge .esl plugins with regular plugins?"

No, you can only merge plugins that are the same type. If you mix in lite plugins (those that are flagged as an esl, even if the extension says .esp) with non-lite plugins, the merge will fail.


SOME THOUGHTS

A note about the Bashed Patch and an xEdit Merged:
While WB does a fairly decent job of handling leveled lists, it does make mistakes and leave things out that should be carried forward into the patch (an example of this is the meat pie - used to wonder why it was never in the game - Bashed Patch always left it out). So, even once you have made a Bashed Patch, you'll still want to check in xEdit to make should that your leveled list are being completely carried forward - if they are not, just drag the items over to the Bashed Patch or use copy record and copy it into the Bashed Patch.

As to an xEdit Merged file. If you are already editing records in xEdit yourself, I would strongly advise not use this. When I made one just out of curiosity as to what it would do (this was on my small mod load - the 760+ one), the xEdit merged file carried over all the things I did not want. xEdit merged should be used if you are not editing records yourself - technically it does a good job, but like all programs, it cannot think.

And one final, BIG caveat: All these things require experience. If you are unsure of something - DON'T DO IT. And if you lack experience, then keep things small.

HOW TO MERGE
This is taken from page for Merge Plugins xEdit Script by matortheeternal - http://www.nexusmods.com/skyrim/mods/37981/? , which is what I use (there is a newer merge mod out that replaces this one: Merge Plugins by Mator - http://www.nexusmods.com/skyrim/mods/69905/? )

Begin quote:

Merging Plugins with Mod Organizer:
1. Set up the plugins you plan on merging so they're all in adjacent load order slots. Test to
make sure the plugins create the desired behavior in the game before merging.
2. Run xEdit through Mod Organizer and load the mods you want to merge.
3. Use "Check For errors" on files to be merged and fix any errors xEdit finds. See the FAQ
for more information on errors and how to fix them.
4. Hold control and click on each of the mods you want to merge so they're highlighted.
5. Right-click on one of the mods and click "Apply Script".
6. Choose "Merge Plugins v1.9" from the drop-down menu and click OK.
7. If it's your first time running Merge Plugins v1.9 you will be taken to the Advanced Options window.
When here, check the "I'm using Mod Organizer" checkbox and set Mod Organizer's directory (you can use the Detect button to have the script try to find it for you). Check "Copy General Assets", and
set the Asset destination directory to Mod Organizer's overwrite folder, then click "Save".
8. Verify the mods you want to merge are checked, and that no other mods are checked, then click OK.
9. Choose -- CREATE NEW FILE -- and click OK.
10. Enter the filename you wish to use for the merged plugin.
11. Wait for merging to complete. If an error occurs (highly unlikely) the script will stop, display the
log, and alert you that an error occurred. Post this log on Nexus Mods to receive assistance.
12. Once merging is completed, close xEdit saving ONLY the new merged plugin you just created.
13. Right click on the Overwrite mod in Mod Organizer and click "Create Mod...". Name the mod,
activate it, and then deactivate the mods you merged.
14. Start the game and test to see if the merged plugin is working as intended.


Merging Plugins with Nexus Mod Manager (applies to all mod managers0:
1. Set up the plugins you plan on merging so they're all in adjacent load order slots. Test to
make sure the plugins create the desired behavior in the game before merging.
2. Run xEdit and load the mods you want to merge.
3. Use "Check For errors" on files to be merged and fix any errors xEdit finds. See the FAQ
for more information on errors and how to fix them.
4. Hold control and click on each of the mods you want to merge so they're highlighted.
5. Right-click on one of the mods and click "Apply Script".
6. Choose "Merge Plugins v1.9" from the drop-down menu and click OK.
7. If it's your first time running Merge Plugins v1.9 you will be taken to the Advanced Options window.
When here, check "Extract BSAs", and set the Asset destination directory to a folder on your desktop (or somewhere else) for the Merged Plugin you're making.
8. Verify the mods you want to merge are checked, and that no other mods are checked, then click OK.
9. Choose -- CREATE NEW FILE -- and click OK.
10. Enter the filename you wish to use for the merged plugin.
11. Wait for merging to complete. If an error occurs (highly unlikely) the script will stop, display the
log, and alert you that an error occurred. Post this log on Nexus Mods to receive assistance.
12. Once merging is completed, close xEdit saving ONLY the new merged plugin you just created.
13. Open your Skyrim data directory and move the Merged Plugin ESP file from it to the folder on
your desktop. Add the folder on your desktop to a .zip, .rar, or .7z archive, then install it
as you would any other mod. Activate it and deactivate the plugins of the mods you merged from your
load order.
14. Start the game and test to see if the merged plugin is working as intended.


Verifying your Merged ESP:
You should also re-open the merged ESP in xEdit after merging and use Check For Errors to make
sure everything is functional.


Removing Plugins from a Merged Plugin:
As of v1.7, you can remove plugins from a merged plugin. This will only work on plugins made with
Merge Plugins v1.7 or newer. Note: this is an experimental feature and results may vary.

1. Load your merged plugin in TES5Edit.
2. Right click on the merged plugin, and click "Apply Script".
3. Choose "Merged Plugin Manager v1.2" from the drop-down menu and click OK.
4. Check the plugins you want to remove, then click "Remove".
5. Close the Merged Plugin Manager and then exit TES5Edit, saving the merged plugin.

End quote.

[smr1957]

Merging Plugins by cfs111

So what happens when we merge plugins? First we should look at the record structure of the mods. I will be using my mod Player Home Quickexit as an example as I released it as a seperate mod for each vanilla or as a single plugin with all the homes, I used mergeplugins to create the all in one so it is a good example. I will be referencing records by form id so if you want to download the mods and follow along in xedit here is the link... https://www.nexusmods.com/skyrimspecialedition/mods/14795

So, when you run mergeplugins to merge plugins it takes the mods apart record by record. Then reassembles them into a single mod. If in xedit we expand the Quickexit - Breezehome.esp > Cell > Block 0 > Sub-Block 6 > 0001658a > Persistant header we will see a record xx005905 which places a trap door inside of breezehome. Expand to the same record in Quickexit - Merged.esp and mergeplugins has redone the form id to be xx00aa91. This is to insure that it will have a unique id. Merge plugins will do this for all records within the mods being merged. Another way of looking at it is mergeplugins does change any conflicting records, it only melds all records together into a single esp. Mods being merged in this way can not have conflicting records within the mods being merged.

Before we look deeper into what this type of merge includes a quick explanation of references within the records may be helpful. When the game reads aa record that record may have references to other records. For example, the iron sword record will reference the record for the sound when you draw the sword. If this reference is not a vanilla reference but comes from one of the mods being merged then the game will have an invalid reference and will ctd (this is why undeleting and disabling references is so important when cleaning mods). So another mergeplugins does for us is to look for these references and make sure they point to the correct reference by changing the reference id to the new form id created during the merge. So to see this in action pull up record Quickexit - Breezehome.esp > Worldspace > 0000003c > Block 0,-1 > Sub-Block 0,-1 > 0000961a > Temporary > xx005905 then in right pane under the FormID header you will see
[REFR:05005905] (places TreePineShrub01 [TREE:0009DAA3] in GRUP Cell Temporary Children of WhiterunExterior02 [CELL:0000961A] (in Tamriel "Skyrim" [WRLD:0000003C] at 5,-3)).
Now if you expand the same record in Quickexit - Merged.esp you will the FormID header has change to
[REFR:0900AA8D] (places TreePineShrub01 [TREE:0009DAA3] in GRUP Cell Temporary Children of WhiterunExterior02 [CELL:0000961A] (in Tamriel "Skyrim" [WRLD:0000003C] at 5,-3))
So we see the reference have been changed to match the new form id of the reference in question.

There are other things that get adjusted during the merge, but beyond changing references from within a record, mergeplugins does not change any records themselves for conflict resolution, that is Wrye Smash or your job. So, to recap, mergeplugins takes the mods you tell to and makes a new esp out of the multiple ones changing any information that needs changing to insure the records can find the other records they need. For the average mod user mergeplugins is really not needed, it is really for when you begin to reach the plugin limit or you have a lot of small mods that it may be easier to handle them if they were a single mod. As well it can be useful for merging patches into a single mod, only downside to this is if one of the mods or patches updates the merge will need to be redone. In my opinion, leave this form of merging alone unless you are reaching the 255 limit.

More to follow eventually, maybe later tonight or tomorrow. I think tackling the bash patch next may be best. I am trying to do this in the order of use, i.e. mergeplugins then wrye bash then wrye smash then manually built patch.



So now let's move on to Wrye Bash and see how it handles records. The bashed patch does two kinds of merging, the first is the same as what merge plugins does,the second is conflict resolution of the leveled list. Wrye Bash can also make tweaks to game variables, i.e. arrow speed, I will not cover that here as it is pretty self explanatory.

When WB merges mods into itself it simply adds the records from the mods into itself in whole, renumbering form ids as needed and repointing any non-vanilla references to the correct record. This one is pretty simple. Usually there are no issues merging mods into the patch, but there are instances where merging the mod in can break parts of it, this is fairly rare and can be bypassed by not allowing WB to merge the mod in question.

Now on to the most important part of what WB does -- merging leveled lists. Mator Smash also does this. I see a lot of folks ask "What is a leveled list?" In the CK there are a full set of objects called dummy markers. There are ones for potions, weapons, armor, etc. When these dummy markers are placed in game an actual item must be attached to them, LItemPotionRestoreHMS, which when you enter the area the game will check your level and choose the item to give you from the leveled lists of that item type. So, why is a bash patch needed, well thanks to the game's Rule of One the last mod to change a leveled list will win and show up in game.

To this rule of one further, When the game loads it first loads all the records that Skyrim.esm has, then the game loads update.esm, any records that are also in skyrim.esm will be overwritten. The game will now move on down the load order adding new records and overwriting any records already loaded. So, only the last loaded record record will "win" and have only it's changes to that record show up in game.

Wrye Bash fixes this by looking at your mods that change the leveled list and will merge the lists together ending up with a single leveld list record containing the changes made by all mods. Now, we have moved from simple merging to conflict resolution (I will cover this in more detail on the mator smash explanation).

If anything needs further explanation, or ya'll would like me to expand on anything just ask. Next we will cover the type of conflict resolution that mator smash and manual patching takes care of. Again, may be awhile before it ready to post.



Last section, we are finally to the most important type of merging, conflict resolution. When a single record is altered by multiple mods the rule of one kicks in and last mod loaded wins. Mator Smash attempts to take all mods that alter the record and merge thier changes
into a single record. We will look at a single record to see what happens, if you wish to follow along the mods are;

USSEP Nexus id 266
Cutting Room Floor 276
ELFX (main file and enhancer) 2424
Open Cities Skyrim 281
Smashed patch
and my Master patch

The record we will look at is 00071ffe. First mod in the load order is USSEP, it actually makes no changes to the record from vanilla. Since this is a top cell record USSEP must change something on a subrecord of this one, in skyrim when you design a cell the cell is empty and it's record contains things like lighting, ambient sounds, etc. When you place, say the ground in the ck in this cell the record for the ground you used will be a subrecord of the main cell. If a mod changes something in the ground subrecord then the mod will also have a copy of the main cell record which will be identical to original record. Even this record is identical to the master it is considered an ITM for cleaning. An ITM for cleaning would be single record with no changes and no subrecords, for most mods this ITM is a mistake and can cause issues later when a mod that does have the same record with a change and the other mod changes it back to vanilla.

Now, back to the record we are looking at... Cutting Room Floor changes afew things within this record, DATA - Flags, XLCN - Location and Ownership. Next mod ELFX, changes nothing and is identical to master (but not an ITM). Next ELFX - Enhancer changes the XCLL - Lighting, but undoes the changes added by CRF, which was already overwritten by ELFX anyway. Next, Open Cities is an itm and undoes ELFX - Enhancer. So, without a smash patch CRF and ELFX changes will not be in game, for ELFX it is not a big deal just no lighting effects for that cell. CRF on the other hand has some keywords removed which could cause issues later.

So we run smash patch and let it do it's conflict resolution, it has left the Data - Flags vanilla, left the lighting vanilla and moved forward CRF changes from XLCN - Location and Ownership. If we were to leave it as is CRF should work correctly (I say should because Data - Flags did not get carried forward. I manually moved the missing things smash patch did not, the Flags and Lighting.

So to recap, Merge Plugins moves plugins in whole into a single plugin creating a larger mod. Wrye Bash moves some mods in whole into itself as well as merging leveled list records. Wrye Smash merges all records as needed, but not plugins, and will need to be checked behind as it is not perfect. My advice, merge plugins only if needed. Run Wrye Bash to merge in plugins and make any tweaks (do not use it's leveled list merge). Run Mator Smash and smash all automate conflict resolution. Finally, manually check behind the smash patch and resolve any conflicts it may have missed. This can be done directly into the smashed patch or into an esp of your making.

Now, is all this necessary for a stable game...no. But, in order for all aspects of all your mods to make thier way into the game and bypass the rule of one is through patching the records by either using the tools provided or manually doing so. The tools are to the point that using them is recommended then checking behind them and adjusting as needed.

As always, if any further explanation is needed just ask. Glad to expound further on this subject or any other that I know the answer to.

[smr1957]

March 24, 2022

Added the following to the FAQ section:

"Can I merge .esl plugins with regular plugins?"

No, you can only merge plugins that are the same type. If you mix in lite plugins (those that are flagged as an esl, even if the extension says .esp) with non-lite plugins, the merge will fail.

[smr1957]

Reserved

[Vlad 254]

“‘Classic’ – a book which people praise and don’t read.” – Mark Twain

[DEAD RaNgEr 888]

is there any point in manually merging plugins anymore when its possible to eslify most or all of them?

there is also xedit scripts like rab smash splitter and zEdit UPF Plugin Loader Generator which makes zedit patchers and smashed patches be created while over the 254 plugin limit.

[smr1957]

Originally posted by DEAD RaNgEr 888:

is there any point in manually merging plugins anymore when its possible to eslify most or all of them?

there is also xedit scripts like rab smash splitter and zEdit UPF Plugin Loader Generator which makes zedit patchers and smashed patches be created while over the 254 plugin limit.

If you want to make an extremely large build the right way there is - for those who have a relatively small build, of course the other things may work to a limited extent, one that is good enough for those that don't mind some things missing from the game - and also provided a person actually knows HOW to create a stable, CTD free build in the first place. But, of course, many people usually prefer what is expedient - no matter how imperfect it may be -as opposed to doing something as it should be done (hence the many people posting in the forums with problems that could easily have been avoided if they had only read the pinned topics). This is for those few who want to do things the right way.

Anyway, this thread is not a place for discussion of the how or why or need of this. Those who need the info can find it here and ask pertinent questions, those who don't want to make use of it do not need to. This is NOT a thread for a debate about the issue. Especially since this thread will probably only be useful to less than 2% of the community - those who have the experience, knowledge, and ability to create builds of over 500 total mods.

[Quevik]

Gonna toss a note in here SMR as it took me a bit to figure this out earlier today and i didn't see it mentioned.

When merging plugins you need to make sure that none of the plugins being merged are flagged as ESL.

While you mentioned in your post that "files need to be adjacent in the load order", apparently it goes beyond that to needing "Adjacent indexes". A light file listed as FE001 that loads immediately before a file listed as 07 is still not considered "adjacent" for the purposes of merging and will result in failure.

And while merging light plugins may seem redundant, example uses include merging a dozen or so weapon mods together into a single organized plugin.

[smr1957]

Good point, that I overlooked as I thought it would be obvious that a person would not be merging an .esl with non-esl files - LOL! But, I suppose, we should not take anything for granted!


And yes, though it would not be thought to merge. esl file together - the example you give is a good one - though, to be honest, I usually just unflag .esl files before merging.

Still, this is a case where those who have the experience would in all likelihood be able to figure these things out - and if they do not have the experience, and are unsure, then there is the fallback of "just don't." though, of course, sometimes the way to learn is by trying and making mistakes - and learning from them.

Thanks again, Quevik for posting - it is much apprieciated!

[Quevik]

Originally posted by smr1957:

And yes, though it would not be thought to merge. esl file together - the example you give is a good one - though, to be honest, I usually just unflag .esl files before merging.

That's ultimately what i ended up doing, once i figured out what the problem was. Easy enough to fix. But back when i was merging plugins regularly, ESLs didn't exist, so i didn't know about this carve out. It's been a few years...lol.

To be honest, half the reason i posted this was in case i forget about it in the future.

But i figure somebody else will eventually need it too. Better to keep all merge info together.

[smr1957]

Yes, and I need to add that info to the main post, as well. Again, thanks, Quevik!

[smr1957]

Added a note to the FAQ section stating that you cannot merge regular .esp plugins with plugins flagged as lite plugins, even if the extension for the plugin is .esp - it is how the plugin is flagged that is important.

[Death Approaches]

it seems strange to me that there aren't more automating scripts to do some of this for you... I mean comparing and adjusting unique variable declaration is pretty easy to automate, and multi-conflict can be scripted once the research and known resolution is tested.

And yes, sure while it's in bad taste to modify someone else's plugins to make a package deal and redistribute it as such, especially when they've specifically forbade it, doing it [i[locally[/i] on the other hand...

You'd think as you start to fill up some of the Vortex-esque type mod managers and load-order keeper frontends, those "Defenders of the Faith" for the ignorant and the lazy, those that cannot and will not manually do a damn thing, just expect things will "do it for me" ... it seems strange that Mator Smash[github.com] and his prequel Merge Plugins and MXPF, stand almost alone even today, for a more universal framework... strange. (I mean Drigger's SMC is a freakin' AutoIT3 script, but still somewhat useful for textures merging and easy to edit for end users who don't know pascal.)

I guess it's hard with the egos of mod makers to get them to colab much when there's no money involved and rent needs paying. Something EVERYONE should have on their mind as we go further and further down the IAPs/microtransactions hitting PC gaming rabbit hole... maybe if we pay the hackers we won't have to micropay or subscribe to the developers/distributors and have to be constantly online and checksummed against server-side data what we're allowed to do? Hmm. Again, keep that in the front of your mind as 2022 rolls by since Microsoft now "owns" everything you love. :-)

@Vlad 254: “‘Classic’ – a book which people praise and don’t read.” – Mark Twain
"There is only one good, knowledge, and one evil, ignorance." - Socrates

[smr1957]

Originally posted by Death Approaches:

it seems strange to me that there aren't more automating scripts to do some of this for you... I mean comparing and adjusting unique variable declaration is pretty easy to automate, and multi-conflict can be scripted once the research and known resolution is tested.
- snip -

Actually, every automated script that I have tested, ALWAYS leaves things out, forwards the wrong record, or gets it wrong in some way. And, it is not something easy to automate - because there are so many variables that it is really not possible given the machines and tools that are available to the average individual. Plus, even if a person did have access to the computing power, it is not just a matter of record A should replace record B, and how does that interact with record C, but one of deciding, based upon what the mods do, and what should appear in the game, and how it should appear, which record is the one that is used where there are several in conflict. And that is something that only a person can decide, and which requires a tremendous amount of experience and knowledge of exactly how each and every mod in the build works. And all the records in the mods being merged need to be checked and the appropriate decisions taken, based upon that experience and knowledge, before the merge is done. Hence my warning at the very top of the post.

[Death Approaches]

I meant "easy" as in terms of coding structure, not in the research... which is how some of them are written in script language not compiled language... while lots of very easy sorting algos are quite known in 2022 (they were in 1982 as well) when your logic code is just the equivalent of nested if/elseif/else compares...
(pseudocode)

if mod1 && mod2 then
  merge 2 >1 
elseif mod1 && mod2 && mod3 then
 merge 2 >1 >3 
elseif mod1 && mod2 && mod3 && mod4 then
 merge 4 >2 >1 >3
elseif...

With the resources of something like the user base of nexusmods you'd think more would be interested, maybe it's just too advanced for the average gamer? I wouldn't think so but then again I always overestimate and think the best of people. :-)

I guess with the plethora of "ESL'ifying your mods" kind of articles out there, the more the merrier, because what one person doesn't explain well, another one might, and eventually it will "click" for someone when they see the big mod picture. (example: I really like Michael-wigontherun's approach to explaining the esk batch creator and it's parsing, as well as his pex decompiler. Whether it works well or not, he explains it well for my brain.)

Maybe it's better than only one or two persons do it, as long as he stays active he can become the entire repository of all mod consolidation knowledge, maybe even come up with guidelines for mod creators to adhere to ala .psc for papyrus when the compiler turns them into .pex... one merge syntax would be fantastic wouldn't it? You'd think Bethesda would have thought of this, but they probably just wanted some time off after every single ES project went to shipping.

Yeah I suspect if there's only ~50 people who care, it'll be an indefinite amount of time before enough data is collected to generate high-confidence merges without the need to manually double and triple check the results. Ah well, here's hoping!

Great post though, keep it rolling - sorry for the tangent.

[smr1957]

Thanks, Death!

Actually, what I was mainly referring to when stating an automatic program cannot make the necessary determinations of what records to forward is for a case (which often occurs) where, for example, let us say, 3 of the plug-ins may use different lighting, or different acoustics. Those are things where only an individual can determine which record should be forwarded and used, as it is something that only the individual editing the records can determine based upon their knowledge/experience of how things should appear, or how they would wish them to appear, in the game.

As to how many people may actually make use of this, yes, this is somewhat of a niche subject, but one which I have seen a number of people bring up in the forums, so having this available for those who may have questions is important - even if there are only ~50 people, as you say.

But thanks for posting! It is always great when people contribute constructively!