Jump to content
  • 0

How do I get Merged Plugins to carry the values I want?


TheOnceler

Question

Hi, I'm having a hard time getting a merged plugin to pull in the values I want and I'm not sure if I'm missing something. I'm trying to merge several NPC retexture mods into one esp. I'm using Divine People of Skyrim, Migal's Housecarls, Improved Bards, Ordinary Women, Men of Winter, and the Bijin series. I prioritized them roughly in that order, as well. I created a Smash Patch which looked really good and had most of the values I wanted carried forward. I then created a small conflict resolution patch in xEdit to grab a few of the changed or missing values I wanted (mostly from patches like ICOW).

 

Then I ran merged plugins and all my fine tuning seems to go out the window. Instead of using the values for the last three eps in my order - Bijin, Smash Patch, and Conflict Resolution patch (all of which are in agreement) my merge plugin is pulling in values that don't even appear in any of the relevant esps.

 

As just one example, I want the Bijin head parts for Maven Black-Briar. The last three esps in my load (Bijin, Smash, and CR) all point to those values. The only other eps affecting that NPC record are Ordinary Women and Skyrim.esm. But when I create my merge, I don't get any of those values. Merged Plugins creates a whole new set of values. I know they must come from somewhere, but I can't see them and I can't figure out how to get Merged Plugins to end up with the values I want. I can't even forward a record into the merged esp or an external CR patch, because that turns the merged esps into masters and doesn't work.

 

I included a screenshot of the Maven record in xEdit to illustrate the issue. But it's also happening in most of the other NPCs as well. Can someone please explain why Merged Plugins isn't pulling in those last loaded values, where those other values str coming from, and is there a way to accomplish what I'm trying to do? Thanks!

post-12941-0-32574100-1531329398_thumb.png

Link to comment
Share on other sites

9 answers to this question

Recommended Posts

  • 0

Out of curiosity - are the desired changes seen in game? Leave the patch aside for a moment, and look at results first - looking at your provided pic, I'm not sure that there is a problem. I explain:

 

Take a look at how the lines for the three ESPs you have after Ordinary Women have thier changes on new lines - by the logic you appear to be using, these would not be overwritten by Bijin and so forth... but looking at the names in those lines, I think it's fairly obvious that they must. Otherwise, you'd have two sets of eyes competing, as an example. If this, then, is the case (and keep in mind, I'm guessing here, as this isn't my strength at all), then the merge putting those on a new set of lines shouldn't be an issue - because they'd still overwrite the files before it. Another way to see it is that the values are being overwritten with a "blank" value, and replaced by a value in a different line - note they all still have the PNAM - Head Part header.

 

So, again, I'm just curious if the changes that you intended to happen in the game actually happened or not - if they did happen, then there would not appear to be a problem. If they didn't, then more investigation is obviously called for.

Link to comment
Share on other sites

  • 0

Out of curiosity - are the desired changes seen in game? Leave the patch aside for a moment, and look at results first - looking at your provided pic, I'm not sure that there is a problem. I explain:

That's a good point, Shadriss. Honestly, I'm not completely sure yet. I'll have to do some research and compare. You can't see it in the screenshot, but if you expand the columns, the ID numbers for each head part number is completely different. Would Merged Plugins create entirely new ID numbers like that? I assumed they were different, but I'll open up xEdit and check the underlying values of those IDs and see if they're the same. Thanks for the response! I'll let you know what I discover.

Link to comment
Share on other sites

  • 0
post-12941-0-36961500-1531500536_thumb.png

Have the FormIDs for these head parts been renumbered in the merged patch?

Yes, the merge creates entirely new formIDs for those headparts. I searched in xEdit and the only place the new formIDs exist is in the merge. I'll try to test Shadriss' query later today if I get a chance.

Edited by TheOnceler
Link to comment
Share on other sites

  • 0

Looking at the pic again, I find myself curious. The first two Alphanums of each reference are 1C (mod 28 in your load list) in the three patch files, then 24 (mod 36) in the patch. What mods are in those slots? Note that the rest of the refs are all the same after that point... so I'm THINKING (and here, my inexperiance with xEdit shows...) that the pull is happening from the same place, just referencing a different mod. If that mod has the correct textures or faceparts, it may be just fine... or not. *shrug* I'm shooting in the dark here.

Edited by Shadriss
Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

OK, thank you. It's hard to tell because some of the faces in-game look pretty close to the pictures but others don't. So the bottom line is that if the text descriptors are exactly the same I shouldn't worry about the different formIDs and whether or not xEdit calls them conflicts? That would be helpful to know when building future conflict patches. Thanks again!

Link to comment
Share on other sites

  • 0

OK, thank you. It's hard to tell because some of the faces in-game look pretty close to the pictures but others don't. So the bottom line is that if the text descriptors are exactly the same I shouldn't worry about the different formIDs and whether or not xEdit calls them conflicts? That would be helpful to know when building future conflict patches. Thanks again!

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.

Link to comment
Share on other sites

  • Recently Browsing   0 members

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

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.