Cobl and wrye bash

[jaime74]

Hi myrmaad,

 

first of all, thanks alot for putting this all together!

I think that the most interesting question relates to this:

 

Read the documentation to decide which options you prefer here. When you select an option, any possibilities for inclusion are listed on the right pane:

I am selective of most the options but I always select all on the merge patches option, unless there's some specific odd reason I don't want a mod's changes included included.

Honestly speaking, it's exactly this part which I find so hard to understand, and where the documentation (if you mean the "official" readme) appears a little "cryptic" to me. Creating a Bashed Patch - more or less intuitively - is not the problem. The problem starts when I try to "click through" exactly this options menu that offers me hundreds of possibilities, but many of them make my game crash, without knowing why.

 

The other problem is that the general logic is *not* that the last mod always wins, as you said. My understanding of Wrye Bash is exactly the opposite. It was invented to allow to "break" or "workaround" this strict "last wins" rule by merging, importing etc..

 

But as stated, I have more or less managed to get things running until now just by trying a lot. I'd only like to understand better what exactly all these option do, and why so many of them cause conflicts when you try to apply them without understanding.

 

But I have already found some more wisdom by reading (RTFM). I am still hopeful... :) Hope to be able to contribute something soon...

[jaime74]

Dear bben46,

 

Try to read and understand one section at a time instead of the whole thing at once.

 

http://sites.google.com/site/oblivionpoinfo/

 

Stick with us, we will make you into a geek before you know it. :thumbsup:

 

Thanks alot! Once again: Thanks alot, and even more alot! ;-) I think that's exactly what I was searching for. Especially the page related to Bashed Pathes (http://sites.google.com/site/oblivionpoinfo/finishinstall/bashedpatch) may be what I needed at last.

 

So I will shut up and RTFM now! ;-)

[Tomlong54210]

Hi myrmaad,

 

first of all, thanks alot for putting this all together!

I think that the most interesting question relates to this:

 

Read the documentation to decide which options you prefer here. When you select an option, any possibilities for inclusion are listed on the right pane:

I am selective of most the options but I always select all on the merge patches option, unless there's some specific odd reason I don't want a mod's changes included included.

Honestly speaking, it's exactly this part which I find so hard to understand, and where the documentation (if you mean the "official" readme) appears a little "cryptic" to me. Creating a Bashed Patch - more or less intuitively - is not the problem. The problem starts when I try to "click through" exactly this options menu that offers me hundreds of possibilities, but many of them make my game crash, without knowing why.

 

The other problem is that the general logic is *not* that the last mod always wins, as you said. My understanding of Wrye Bash is exactly the opposite. It was invented to allow to "break" or "workaround" this strict "last wins" rule by merging, importing etc..

 

But as stated, I have more or less managed to get things running until now just by trying a lot. I'd only like to understand better what exactly all these option do, and why so many of them cause conflicts when you try to apply them without understanding.

 

But I have already found some more wisdom by reading (RTFM). I am still hopeful... :) Hope to be able to contribute something soon...

Imports and merges obey load order. What the Bashed Patch is basically facilitated merging. You could do the same thing by manually merging a bunch of plugin's changes together in a very logical format via TES4Edit. That would be a major pain, so it is nice that we have a program to take care of all of that logic for us. The Bashed Patch is not magical at all. Imported and merged plugins just have (at least part of) their changes merged into the patch.

[jaime74]

Imports and merges obey load order. What the Bashed Patch is basically facilitated merging. You could do the same thing by manually merging a bunch of plugin's changes together in a very logical format via TES4Edit. That would be a major pain, so it is nice that we have a program to take care of all of that logic for us. The Bashed Patch is not magical at all. Imported and merged plugins just have (at least part of) their changes merged into the patch.

Yes, I'm sure your're right. I am still wondering how Wrye Bash manages to this all so easily!

 

Talking about importing: What about factions? I read from the UESP articles, that there'd be no way to import of merge factions (though probably just misunderstood that?), and at the same time the options menu when building the patch offers me to "import factions".

 

Just an example:

I have created a mod that adds certain factions to certain vanilla(!) NPCs. Now I want to ensure that this doesn't break neither the vanilla game, nor any other mods' faction assignments. How would I have to use Wrye Bash now to ensure that my changes are only merged into everything else instead of overwriting anything?

Maybe this is a beginner's question. But I haven't found an answer to this yet.

[Tomlong54210]

Say you have mods A and B that both add new ranks to the same faction (as is the case with certain quest mods.) Normally, whichever one loads later would be the one whose changes are visible in the game. Pre-Wrye Bash, the only way to get around this was to merge the changes. You could do this with TESCS, but you really only want that one record to have both changes. Thinking along those lines, you want to provide a patch. Okay, in that case there are a few options, the best option being TES4Edit. TES4Edit allows you to modify records within plugins. Using TES4Edit you could create a patch that depends on both A and B that add both of their ranks to the same faction.

 

Doing that is pretty simple. People make small patches like that on the fly all of the time. However, imagine that ten plugins overlapped across ten records. Save files and the game's loading process are not the only aspects of the game that are load order dependent. Plugins' dependencies' order matters too, when the dependencies' changes overlap. It is a lot harder to maker large-scale merges that have many plugin dependencies. The Bashed Patch takes care of that, and, you'll notice, that the Bashed Patch is very dependent on your load order. That's why you are told to rebuild it after making any changes. The order of the dependencies can make a huge difference.

 

It's easiest to use a load order example. Say you have a plugin which has, as record, 01C87ACE, a hood. Your character has the hood in his inventory. Then, you decide to drop that plugin and immediately add another plugin which happens to have that same FormID, but that record is a chair. When you launch your game, your inventory then contains a chair (which probably is not visible in the inventory as a chair) and that is broken functionality. There are much more troublesome record changes that can happen. It's really, really convenient to have a tool that can automate large-scale merging with 100 dependencies.

[jaime74]

Say you have mods A and B that both add new ranks to the same faction (as is the case with certain quest mods.) Normally, whichever one loads later would be the one whose changes are visible in the game. [...]

The Bashed Patch takes care of that [...]

 

I think I should be more precise in explaining my problem: In my example, I defined a new faction and just added membership in this faction to several vanilla NPCs (by dragging the faction into the NPCs' faction list inside TES CS).

Now I am worrying whether this will cause problems if anybody uses my mod together with other mods that do the same thing for the same NPCs (and I guess the chance for that is 100%). All in all, this is probably a "standard" issue of mod conflicts, but somehow I don't find the clue.

 

What I already understand is that...

1. ... normally (in the vanilla load mechanism) the mod which loads later would force its own factions onto these NPCs, overwriting any changes of the other (earlier loading) mod --> this would be a killer argument not to use my mod!

2. ...that the safest (and at the same time hardest) way to solve such conflicts would be to create individual patches, let's say using TES4Edit. But this would require to identify any conflicting mod and creating a patch for each of them. --> this is not very realistic, or is it?

3. ... that Wrye Bash may be able to handle all of this in a more generic, elegant way. But then I need to tell my mod users what exactly to do to install my mod properly.

 

This (i.e. the third solution) is what I am hoping for. What would users need to do?

 

a.) Just include both mods in their Bashed Patch, without any tagging etc. (just relying on Wrye Bash to handle everything)?

b.) Tagging one or both of the mods mods accordingly before building the patch? And if so, with what kind of tags? The "faction" tag?

c.) Using "import factions" on one or both of the mods?

d.) or maybe b.) or c.) in combination?

 

As you may see, my main problem is to understand what "import" really does (if it makes sense in this case), and also what Wrye Bash perhaps does automatically without any importing, tagging etc.. I have several options that sound the same to me, but apparently aren't. What to do now?

[Tomlong54210]

Say you have mods A and B that both add new ranks to the same faction (as is the case with certain quest mods.) Normally, whichever one loads later would be the one whose changes are visible in the game. [...]

The Bashed Patch takes care of that [...]

 

I think I should be more precise in explaining my problem: In my example, I defined a new faction and just added membership in this faction to several vanilla NPCs (by dragging the faction into the NPCs' faction list inside TES CS).

Now I am worrying whether this will cause problems if anybody uses my mod together with other mods that do the same thing for the same NPCs (and I guess the chance for that is 100%). All in all, this is probably a "standard" issue of mod conflicts, but somehow I don't find the clue.

 

What I already understand is that...

1. ... normally (in the vanilla load mechanism) the mod which loads later would force its own factions onto these NPCs, overwriting any changes of the other (earlier loading) mod --> this would be a killer argument not to use my mod!

2. ...that the safest (and at the same time hardest) way to solve such conflicts would be to create individual patches, let's say using TES4Edit. But this would require to identify any conflicting mod and creating a patch for each of them. --> this is not very realistic, or is it?

3. ... that Wrye Bash may be able to handle all of this in a more generic, elegant way. But then I need to tell my mod users what exactly to do to install my mod properly.

 

This (i.e. the third solution) is what I am hoping for. What would users need to do?

 

a.) Just include both mods in their Bashed Patch, without any tagging etc. (just relying on Wrye Bash to handle everything)?

b.) Tagging one or both of the mods mods accordingly before building the patch? And if so, with what kind of tags? The "faction" tag?

c.) Using "import factions" on one or both of the mods?

d.) or maybe b.) or c.) in combination?

 

As you may see, my main problem is to understand what "import" really does (if it makes sense in this case), and also what Wrye Bash perhaps does automatically without any importing, tagging etc.. I have several options that sound the same to me, but apparently aren't. What to do now?

Bash does not do anything automatically. If nothing in the Bashed Patch is selected, it serves no purpose. The kind of patch you want is a filter patch. Since only factions would have to be imported, it can be an import-only patch (NoMerge,Factions,Deactivate) Filter allows users to have only one or some of the plugin's dependencies instead of all of them. Not all plugins can have filter tags (and most don't need it.) This one can.

 

After checking my Bashed Patch, I do not see mods modifying NPCs' factions and having those changes imported in the the patch. Many mods change relations and add ranks, but as for actually changing the NPCs factions, I cannot think of too many examples. Regardless, it looks like you want a filter plugin. I probably need to check my load order more, but I do not have time at the moment.

[jaime74]

Hi Tomlong,

The kind of patch you want is a filter patch.

Well, thanks! I didn't think of that, so this hint helps me a lot! I will try to see if I can find out something more about this myself! As soon as I know more, I will post it here.

I probably need to check my load order more, but I do not have time at the moment.

Don't worry! You already helped me! :)

 

Just 2 additional notes:

1. I should explain why I am using custom factions: What I need to do is some "grouping" of NPC all over Cyrodiil (e.g. all "book vendors", all "blacksmiths", all "mages guild alchemists" etc.). I need to identify members of such "professional groups" in my dialogue conditions by using the "getInFaction" function. This is the reason why I created these factions and added them to vanilla NPCs. Maybe this is not the most elegant solution for my problem, but I had no better idea so far.

2. I hope that this all doesn't exceed this thread, as I am not talking about COBL at all. Maybe I should move this whole thing to another place (which is more related to Wrye Bash in general)?

[Tomlong54210]

Hi Tomlong,

The kind of patch you want is a filter patch.

Well, thanks! I didn't think of that, so this hint helps me a lot! I will try to see if I can find out something more about this myself! As soon as I know more, I will post it here.

I probably need to check my load order more, but I do not have time at the moment.

Don't worry! You already helped me! :)

 

Just 2 additional notes:

1. I should explain why I am using custom factions: What I need to do is some "grouping" of NPC all over Cyrodiil (e.g. all "book vendors", all "blacksmiths", all "mages guild alchemists" etc.). I need to identify members of such "professional groups" in my dialogue conditions by using the "getInFaction" function. This is the reason why I created these factions and added them to vanilla NPCs. Maybe this is not the most elegant solution for my problem, but I had no better idea so far.

2. I hope that this all doesn't exceed this thread, as I am not talking about COBL at all. Maybe I should move this whole thing to another place (which is more related to Wrye Bash in general)?

This thread is fine. This is not complex Wrye Bash functionality. I just need to come up with an example or two. FCOM should help, but that's at home, haha.

[jaime74]

Well now... I tried to do some homework ;-)

 

After reading and -hopefully, partially - understanding "Filtering", I can now imagine the following solution to my "custom factions" challenge.

Let's see whether the experts here consider this a good solution, or rather complete rubbish ;-)

 

What do I want to do?

- create a custom faction (let's call it "My Faction"), which I need for my quest

- add this faction to a vanilla NPC defined in Oblivion.esm (let's call him "Baurus")

 

In my vanilla way of thinking (i.e. prior to using and trying to understand Wrye Bash), I have done the following (and this is what causes the problem):

- created a new esp (let's call it "MyQuest.esp")

- implemented my whole quest stuff...

- defined "My Faction" inside that esp

. also inside the same esp, added "My Faction" to the faction list in Baurus' form editor

- saved the esp

 

Now I want to distribute the esp.

But I am afraid that it will cause trouble, because by assigning a new faction to Baurus, I have created a new Baurus record inside my mod that will shadow any other Baurus record that loads before my mod.

So, whenever someone else's mod (let's call it "YourQuest.esp") should decide to also add some faction ("Your Faction") to Baurus, both mods will collide: Depending on their load order positions, Baurus will either end up to be a member of "My Faction" or of "Your Faction", but never as a member of both factions!

 

Is this all correct so far? If yes, then I am glad that I have at least correctly understood the basic issue... ugh! :)

 

Now this is how I'd like to resolve it properly, with my "quickshot" understanding of Filtering:

1. Reopen MyQuest.esp in TES CS and remove f"My Faction" from Baurus (but I leave the faction definition itself untouched!)

2. save my MyQuest.esp

3. Just to be sure, I open MyQuest.esp in TES4Edit to remove any remaining Baurus record (which would now be only a "dirty edit"). In addition, I cross-check that the "My Faction" record is still there

4. Now I create a new MyQuestFactions.esp, opening it as "active file" in TES CS, loaded together with Oblivion.esm and MyQuest.esp as parents

6. Now I reassign Baurus to "My Faction" and save MyQuestFactions.esp

7. I open WryeBash and add the tags "Factions", "Filter" and "Deactivate" to MyQuestFactions.esp

8. I use Wrye Bash's "Copy to Description" function to persist these tags inside my esp's description

9. Activate MyQuest.esp in Wrye Bash's mod list

10. Deactivate MyQuestFactions.esp in Wrye Bash's mod list

11. rebuild my Bashed Patch, checking MyQuestFactions.esp inside the "Import Factions" category

 

That's it.

Given that this is not rubbish, then it would mean that I have to distribute MyQuestFactions.esp together with MyQuest.esp inside my omod, and I should also add a proper comment to my readme.txt, explaining how to place both esps in the load order and also how to process the steps 9 - 11 mentioned above.

The only question that remains: What about users that don't want to use Wrye Bash? Will it be sufficient just to tell them to maintain load order (MyQuestFactions.esp close to the end and after MyQuest.esp and any other mod changing faction memebership)?

Or will this solution force anybody to use Wrye Bash?

 

mmm... now I am really curious for feedback!! ;-);-)