Jump to content

Important! -- Re: Merging and patching


prideslayer

Recommended Posts

EDITED to reflect posts from more knowledgable patch/merge users.

 

Something in another thread reminded me of a glaring issue that I haven't mentioned before now. I will be updating the NX and Sexout threads with the information, but I'm posting here first to try and attain greater exposure.

 

If you use FNVEdit or another utility to merge several mods into one to reduce your mod count, you probably already know that you should avoid doing so with Sexout, or any Sexout mods that don't explicitly say it's safe to do so. However, it has just dawned on me that if you make such a patch *after* you've played for a while, without a clean save, you run the risk of severely upsetting the NVSE Extender.

 

NX stores form IDs set with the SetEVFo function in its savefiles. On game load, these are read up and automatically renumbered if the load order changed. The engine does this as well with savegames. If you have a mod that anything using NX has set a variable on, and you merge that mod, those variables will all be lost. Likewise if you merge a mod that NX used as a SetEVFo value, that variable will also be lost.

 

I will use the willow companion as an example of both scenarios.

 

Situation 1:

1. SexoutLust sets an NX variable on Willow to track her lust level.

2. Save and exit.

3. Merge the willow mod into your other modlist and disable the willow esp.

4. Load the save from step 2.

5. The value set in step 1 is now lost.

 

Situation 2:

1. Some marriage mod sets an NX variable on the player indicating Willow is his spouse.

2. Same as situation 1 steps 2-5.

 

This makes it very dangerous to merge anything that gets an NX EVFo variable set on it, or that has references used by other mods that maintain their EVFo values elsewhere. The only way to avoid this is to make a clean save without Sexout or any other mods using SetEVFo in NVSE Extender loaded before making the merge, or before recreating a merge.

 

The worst case scenario is one where you make a save in a working game where you already have a merge active, and you recreate the merge with different mods. In this case, NX cannot detect that the merge 'mod' has drastically changed. The EVFo values will not be discared, but may be invalid, and their subsequent use may result in any kind of odd behavior upto and including a CTD.

 

Just FYI.

 

EDIT: Updated to reflect this applies to merging mods, not to making bashed patches. See the entire thread for more details.

Link to comment

I'm not certain.

 

If the result of the work is that you disable the mods you merged in, then the warning applies.

 

One way to resolve conflicts is to make an ESP that modifies records in a bunch of ESMs, but you leave the ESMs active and just put the merge file last in your load order. This is safe to do.

 

What I'm warning against are the mod merges people do to keep all the mods they have active while reducing their mod count so they don't run into their particular mod limit. If you take a bunch of ESMs or ESPs and merge them together into a single file, and then only have that file active (and not the others), you are likely going to have problems.

Link to comment

In my experience merging should be kept to simple mods like extra clothing, weapons etc rather than complicated & resource mods and mission mods that use heavy NVSE scripting. Merging too much stuff is like loading your plate up at a buffet then dropping it all in a blender before consuming and wondering why it tastes like it's been through your digestive system.

Link to comment

I've extensively used bashed patches and sexout over the years. The bashed patch only "swallows" mods that override each other like customization mods or optional patches. The FNVEdit merged patch is such an override for example, which can be included in the bashed patch.

 

The other main function is to combine records that are not compatibility patches which would otherwise conflict with each other, to allow for compatibility. For instance: FNV Redesigned and basically every other mod that touches NPCs. Since Sexout doesn't change other mods (or vanilla records that are usually covered) it has "natural immunity" against the bashed patch. 

 

As for the example, the willow mod doesn't change/override anything significant for the bashed patch in vanilla or other mods either, so it shouldn't even be an option to merge it in. Any possible willow customization mod might however. 

 

Unfortunately, Wrye Bash for FNV never had the same support like it has for Oblivion or Skyrim. Some functions are somewhat crippled or underdeveloped. The main attraction for me always was to see instantly colorcoded what mods are missing masters, load order problems and the possibility to see mod dependencies of save games. It has some other nifty features as well, that never made their way to FOMM or NMM.

Link to comment

There seems to be a lot of misunderstanding as to how the bashed patch works. The only time an .esp will be integrated into a bashed patch is if it only contains FormIDs that are overriding pre-existing ones. If there is even just one new FormID, it will not be integrated. I would need to check, but I'm almost certain that an .esm will never be integrated under any circumstances.

 

Examples:

 

  1. SomeMod.esp contains only changes to vanilla records - This may be integrated into a bashed patch.
  2. SomeOtherMod.esp changes some vanilla records and adds some new items or scripts - This will never be integrated into a bashed patch.
  3. SomeSexoutMod.esp places some of the items found in SCR into pre-existing locations in the world - This may be integrated into a bashed patch.
  4. SomeOtherSexoutMod.esp uses some resources found in both vanilla and SCR, and adds some new items/scripts - This will never be integrated into a bashed patch.
  5. OneMoreSexoutMod.esp uses only vanilla and scr items, but instead of creating new scripts overrides existing ones and uses NX_Vars - This may be integrated into a bashed patch, but it will likely break things if you do.

The only one you have to watch out for when making a standard bashed patch is 5.

 

Of course, none of that takes into account the fact that very few mod authors tag their mods (and fewer still tag them correctly), so even if you only bash non-sexout mods it may not be giving you exactly what you would expect in the bashed patch. The only way to ensure that you are getting what you want is to learn how to use FNVEdit.

 

Which brings us to the main issue at hand. If you use something like FNVEdit to combine two or more mods in order to reduce the number of mods being loaded (usually to help stay under the mod limit), then you must not combine any mod that uses NX_Vars or is referenced by any other mod that uses IsModLoaded, or things will break.

 

Now I'm not going to say that it is 100% guaranteed that including a specific sexout mod when making a bashed patch will work flawlessly, as I have not tried it with every single one, but making a bashed patch, in and of itself, is highly unlikely to be the cause of any problems that are occurring. The only exception to this that I have found is when multiple mods add and subtract from the same form list / levelled list. In this instance, bash may not always get it right, and you should check the results with FNVEdit.

 

 

tl;dr

 

If you bash your non-sexout mods first and then add sexout mods, you should be fine. Most sexout mods should work fine even if you do include them when making a bashed patch. Just don't combine any mod that uses NX_Vars or is referred to by another mod using IsModLoaded with anything else in order to reduce the number of mods being loaded or you will break things.

Link to comment

Poly, thank you for the details, I wasn't aware that wrye was only bashing things with no new records.

 

It is incorrect in which scenarios are 'safe' though, which has nothing to do with the NX aspect. You covered this in the tldr, but users are not going to *know* if a mod is using IsModLoaded without digging. Some mods use it simply to alter their own behavior, without using buildref. For example in scenario 3, if a mod to add items to some container is missing, another mod may add them itself, resulting in duplicates.

 

The FNVEdit merge process is much more dangerous in light of your post.

Link to comment
Guest luthienanarion

Merging plugins is dangerous, period. If you don't know what you're doing--and if you have any questions at all about merging plugins, you don't--merging plugins using FNVPlugin or even FNVEdit will often result in broken mods.

 

Merging an ESM into another file will break any dependant ESPs that require it as a master. As noted above, it also breaks scripting checks for other mods via IsModLoaded. Merging files will also break MCM menus 100% of the time. Part of this is because of renamed plugin files, but it occurs also because the MCM guidelines--followed by the overwhelming majority of mods that utilize MCM--outline a method of mod isolation that does not allow for multiple separate menus in a single plugin. You'll have to understand GECK scripting enough to fix scripts that break after the merging process.

 

Another problem that can occur with the process of merging plugins is the renumbering of FormIDs to avoid duplicates, which breaks every call to BuildRef from another plugin.

 

 

 

TL;DR: Don't even consider the idea that plugins can be merged together unless you are a wizard. Just get rid of useless mods if you need to shorten your load order.

Link to comment

Right waffles, thanks.

 

To all concerned, I've updated the subject line and OP to reflect all this. Not bing a wrye user myself except for once a year or so ago, I was not aware that the patches it makes were so restrictive. There should be no (new) problems using them with NX. It's the merging that's a big problem for it.

Link to comment

Right waffles, thanks.

 

To all concerned, I've updated the subject line and OP to reflect all this. Not bing a wrye user myself except for once a year or so ago, I was not aware that the patches it makes were so restrictive. There should be no (new) problems using them with NX. It's the merging that's a big problem for it.

 

Don't be so categorical :)

 

I was an intensive user of Wrye Bash in Oblivion with very very few problem.

 

So It has been evident for me to use Wrye Flash when I began to play Fallout. Has some minor problems but didn't think it was the cause.

 

I definitely abandoned it a few month ago when I began the dev of Slavers's life (so before SexoutSlavers) when I remarked that by using it only to modify some global paramaters like respawn duration or number max of follower, without any other use like merge mods or list I had some problems with the mod I was on dev without having then without the bashed patch.

 

For me the tool is unfinished and create side effects. Now I only use FNVedit to solve conflicts.

Link to comment
  • 1 year later...

I'm not certain.

 

If the result of the work is that you disable the mods you merged in, then the warning applies.

 

One way to resolve conflicts is to make an ESP that modifies records in a bunch of ESMs, but you leave the ESMs active and just put the merge file last in your load order. This is safe to do. s.

I had a problem where merge file caused pregnancy armor to no longer spawn. This was with a male main, and female pregnant companions. Uninstalling the merged esp fixed that problem. So I am not so sure it is 100 percent safe. I did make the merged file after playing the toon for some time. Also, the reason I made the merged file esp, was to try and fix a problem I was having with the dialog for sex from sexout, disappearing. When it disappears, I could go back and load previous saves until I found one where it was working. the merged file fixed this so it was not disappearing. I do have SI installed also, but I set the load order and I am using Prideslayers wsex.esp as the last file loaded. The SI dialog never disappears, and whether the sexout dialog is there or not the animations work from the SI dialog.

Link to comment

I've seen a lot of explanation and clarification for using Wrye Bash, but none for FNVEdit. So I'ma drop some knowledge ;)

 

Let me start by saying anyone who read the Training Manual already knows this. And if you haven't read it, or watched Gopher's tutorial videos on YouTube, you really need to. That being said, there is a major difference between merging mods and making a merge patch and all of the warnings I've seen here are for merging mods. A merge patch made with FNVEdit is, as half the name implies, a patch. You run FNVEdit and filter for conflicts, then create the patch. When the patch first generates, it reflects your load order in that the last mod to change a record wins. From that point you are supposed to manually edit the patch so that the mod you want to win's records are in the final plugin in your load order. That sounds a little convoluted, so let me clarify with an example:

 

So lets say you have Lings, Kristina's Closet (herein called KC because I'm lazy), and a mod that turns Sarah from Vault 21 into a companion. All three of these mods affect Sarah, and they all change her in different ways. Lings is an esm, KC is an esm, so let's say Sarah Companion is an esp. Lings changes Sarah's appearance, KC changes her appearance and inventory (adds JonasOpines Vault Girl outfit in place of her regular vault suit), and SarahCompanion.esp leaves her appearance and inventory vanilla but, of course, changes her npc packages to add follower behavior. SarahCompanion loads last, so it cancels out Lings and KC to add the companion stuff. With a Merge Patch, you can drag the appearance info from Lings and the inventory info from KC into your MergePatch.esp so that you get your desired changes from all three mods in your game.

 

This process makes no changes to the original mods. It also does not remove the original mods from your load order in any way. A merge patch isn't what you want to shorten your load order, it actually adds a plugin to your LO to patch all your mods to play nice together.

 

TL;DR, an FNVEdit merge patch doesn't merge files, it patches them to smooth out conflicts.

Link to comment

I've seen a lot of explanation and clarification for using Wrye Bash, but none for FNVEdit. So I'ma drop some knowledge ;)

 

Let me start by saying anyone who read the Training Manual already knows this. And if you haven't read it, or watched Gopher's tutorial videos on YouTube, you really need to. That being said, there is a major difference between merging mods and making a merge patch and all of the warnings I've seen here are for merging mods. A merge patch made with FNVEdit is, as half the name implies, a patch. You run FNVEdit and filter for conflicts, then create the patch. When the patch first generates, it reflects your load order in that the last mod to change a record wins. From that point you are supposed to manually edit the patch so that the mod you want to win's records are in the final plugin in your load order. That sounds a little convoluted, so let me clarify with an example:

 

So lets say you have Lings, Kristina's Closet (herein called KC because I'm lazy), and a mod that turns Sarah from Vault 21 into a companion. All three of these mods affect Sarah, and they all change her in different ways. Lings is an esm, KC is an esm, so let's say Sarah Companion is an esp. Lings changes Sarah's appearance, KC changes her appearance and inventory (adds JonasOpines Vault Girl outfit in place of her regular vault suit), and SarahCompanion.esp leaves her appearance and inventory vanilla but, of course, changes her npc packages to add follower behavior. SarahCompanion loads last, so it cancels out Lings and KC to add the companion stuff. With a Merge Patch, you can drag the appearance info from Lings and the inventory info from KC into your MergePatch.esp so that you get your desired changes from all three mods in your game.

 

This process makes no changes to the original mods. It also does not remove the original mods from your load order in any way. A merge patch isn't what you want to shorten your load order, it actually adds a plugin to your LO to patch all your mods to play nice together.

 

TL;DR, an FNVEdit merge patch doesn't merge files, it patches them to smooth out conflicts.

 

 

Gopher is the God of explaining things.  I watched his video again on using FNVEdit to make a merged patch.  Not merging mods!  Fixing conflicts between mods.

 

Anyway I made the patch and opened it.  There were three files in the containers that were red highlighted and had red print.  One of the three had red Highlighting and Green Print. I exited the FNVEdit, without saving.  The I used NMM to move the ESM with the green print  down in the load order past the ones that were red and red.  I then ran FNVEdit again and created a new merged patch and all of the containers were green.  The pregnacy armor was all fixed and working.

 

The other problem that I thought the merged patch was fixing, IE the sexout dialog disappering, is also fixed.  I have not idea why though as NONE of the sexout MODs are used in the merged patch.

 

Sorry about getting what was happening wrong. you may curse me a a noob.

Link to comment
  • 4 months later...

Hi guys i have a big problem whit this mod. In the quest im just reached the part when i shlould speak whit the speaker at the slave camp and the speaker just say; waht dou you want? and always saying this. I have this problem whit other mods too like L.E.A.N.E. Im think about its just some load order problem but after a lot of tweaking still not work. Anyone ? :)

Link to comment

Hi guys i have a big problem whit this mod. In the quest im just reached the part when i shlould speak whit the speaker at the slave camp and the speaker just say; waht dou you want? and always saying this. I have this problem whit other mods too like L.E.A.N.E. Im think about its just some load order problem but after a lot of tweaking still not work. Anyone ? :)

This isn't a mod
Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use