Cobl and wrye bash

[myrmaad]

I don't think you understood that I was speaking in general of load logic. We do leave the bashed patch near the end of the load, so it's unlikely that very few, if any mods would change the things that the bash patch changes.

 

As for your filter bash patch, I would handle it separately, drag another blank out of the extras folder and rename it, and then bash it for only the factions.

 

I do think that it's an intriguing plan to bring what sounds like working gilds to Tamriel. As far as using it for distribution, you'll have to rely on someone else's expertise, I think there should be another way but many people do use Wrye so it could be an optional file perhaps. I don't know.

[Tomlong54210]

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!! ;-);-)

That sounds really complicated. The point of the tags would be to get around making a patch that could be merged. The tags would tell Bash to import that faction injection from your ESP. It sounds like you do not need filter at all. You are not making a patch dependent upon multiple plugins. You just need the faction data injection for various NPC records to be imported.

[jaime74]

The tags would tell Bash to import that faction injection from your ESP. It sounds like you do not need filter at all. You are not making a patch dependent upon multiple plugins. You just need the faction data injection for various NPC records to be imported.

Well, yes. I think "faction injection" is a good term for what I am trying to achieve.

Maybe I was thinking in far too complicated ways. All I really need is a "patch" (or whatever we may call it) that injects certain faction memberships into certain NPCs' faction list - without killing any other mods' faction assignments.

 

Now I suppose that my solution could also be as simple as this (I am still optimistic):

 

1. remove the custom faction assignments from my main esp (the one called MyQuest.esp above)

2. redefine the faction assignments in another esp (MyQuestFactions.esp)

3. just MERGE MyQuestFactions.esp into the Bashed Patch (i.e. without any tagging, importing etc.), and deactivate it.

 

Could it be that easy? Or am I completely confused now?

 

If someone would't want to use Wrye Bash to play my mod, he or she could still place MyQuestFactions.esp as a regular esp in the load order (ensuring that it loads after MyQuest.esp). This would mean no full garantuee that there won't be conflicts, but I guess that without Wrye Bash such a user would face similar problems with other mods, too, so I probably would't need to worry.

[jaime74]

Hi myrmaad,

I don't think you understood that I was speaking in general of load logic. We do leave the bashed patch near the end of the load, so it's unlikely that very few, if any mods would change the things that the bash patch changes.

You're right. I guess I misread that.

When I was talking about using Wrye Bash to "break"/"work around" the regular load ordering, I was thinking of "importing" only, which I understand to be a means to explicitely extract certain records from a mod and place it into the Bashed Patch and thus at the very end of the load order. But as I understand now, hopefully (after lots of reading), importing is only a very special aspect of the Bashed Patch mechanism.

 

I do think that it's an intriguing plan to bring what sounds like working gilds to Tamriel. As far as using it for distribution, you'll have to rely on someone else's expertise, I think there should be another way but many people do use Wrye so it could be an optional file perhaps. I don't know.

My problem is that I don't need to create such "working guilds" in terms of gameplay: They won't have any visible appearance (like guild houses, dialogues, quests or whatever). It's just a technical solution for being able to detect whether the player is talking to a "smith" or to a "book vendor", so that I don't need to define multiple conditions, checking for a long list of specific NPC names.

I'd be very glad if there was an easier solution. But as I don't know a better one so far, I have to understand Wrye Bash, which is very fascinating as well ! ;-)

[Tomlong54210]

The tags would tell Bash to import that faction injection from your ESP. It sounds like you do not need filter at all. You are not making a patch dependent upon multiple plugins. You just need the faction data injection for various NPC records to be imported.

Well, yes. I think "faction injection" is a good term for what I am trying to achieve.

Maybe I was thinking in far too complicated ways. All I really need is a "patch" (or whatever we may call it) that injects certain faction memberships into certain NPCs' faction list - without killing any other mods' faction assignments.

 

Now I suppose that my solution could also be as simple as this (I am still optimistic):

 

1. remove the custom faction assignments from my main esp (the one called MyQuest.esp above)

2. redefine the faction assignments in another esp (MyQuestFactions.esp)

3. just MERGE MyQuestFactions.esp into the Bashed Patch (i.e. without any tagging, importing etc.), and deactivate it.

 

Could it be that easy? Or am I completely confused now?

 

If someone would't want to use Wrye Bash to play my mod, he or she could still place MyQuestFactions.esp as a regular esp in the load order (ensuring that it loads after MyQuest.esp). This would mean no full garantuee that there won't be conflicts, but I guess that without Wrye Bash such a user would face similar problems with other mods, too, so I probably would't need to worry.

You do not need to make a separate patch. You just need to use tags to have the injections imported into the Bashed Patch. Think of imports as super partial merges, only merging changes to individual records. All you should have to do is add the tag {{BASH:Factions}} to your plugin.

 

Bash ReadMe - http://wryemusings.com/Wrye%20Bash.html#ImportFactions <-- The ReadMe is a number of version outdated, but the Import Factions tag is not new.

[jaime74]

You do not need to make a separate patch. You just need to use tags to have the injections imported into the Bashed Patch. Think of imports as super partial merges, only merging changes to individual records. All you should have to do is add the tag {{BASH:Factions}} to your plugin.

Bash ReadMe - http://wryemusings.com/Wrye%20Bash.html#ImportFactions <-- The ReadMe is a number of version outdated, but the Import Factions tag is not new.

 

At first, thanks once again! I really appreciate the help! I've already learned a lot, despite all confusion! And I hope it's getting better... ;-)

 

Funny enough, in the meantime I have tried to do exactly as you say - just using {{BASH:Factions}} and importing factions from my esp into the patch... according to the readme.

I tried two different scenarios, with partial success (see below).

My conclusion in short terms: This solution only seems to works when I place my own mod very early in the load order, i.e. before any other mod that also assigns factions to the same NPCs.

 

My "experiment" (which is reproducible) runs as follows:

 

1. I created a new "TestFactions.esp" that just defines 1 new faction ("Test Faction") and assigns it to 1 vanilla NPC ("Baurus"). Let's treat it like some other guy's mod. My goal is to ensure that these 3rd party faction assignments are not broken by my mod.

2. I activated TestFactions.esp

3. I then tagged my own mod, which assigns "My Faction" to Baurus, with {{BASH:Factions}} and placed/activated it after TestFactions.esp in the load order

4. I created the Bashed Patch, importing factions from my mod

--> result: The Bashed Patch is completely empty (blank file). Baurus is only member of "My Faction" (apart from the vanilla factions that I don't mention here)

5. Then I moved my own mod to a position before TestFactions.esp and rebuilt the Bashed Patch

--> now The Bashed Patch Details contain exactly one record for Baurus. Ingame, everything is as expected: Baurus is now member of both factions

 

Any other experiments with Filtering, Merging, Deactivating etc. resulted in Baurus having none of both factions at all (as I had already expected... just mentioning it for completeness).

 

Did I do anything wrong? Or is this all correct?

In the first case (4.) I suppose that due to natural load ordering my mod just overwrites the Baurus record from the other mod, no matter whether I use import or not.

In the second case (5.), the Baurus record seems to be imported into the Patch, but without shadowing anything from the Baurus record in the other mod? It rather seems that now Baurus' faction list has somehow been merged (as I had hoped).

However, the correct load order seems to be critical!

 

Maybe this is exactly what Wrye Bash is expected to do (and what I needed to understand by doing all of this). But now I am afraid that this means a problem for me and my mod, as I'll have to tell everybody

- either to place my mod "in front of any other mod that assigns factions to vanilla NPCs" before building the patch --> I doubt whether many users are willing to analyze all of their mods

- or, if they don't use Wrye Bash, to be aware that there "might be some conflicts with any other mods that assign factions to vanilla NPCs" --> I guess that this will make many users ignore my mod, either because they don't understand, or because they just trust my mod.

 

But maybe this is how it works. Or is there another way?

Maybe I am also just trying to be too thorough a bit :(

[Tomlong54210]

Imports work like this, Bash is an efficient merge. It does not contain unnecessary data. If nothing overwrites a plugin's changes, the Bashed Patch will not contain records from that plugin. There is no need to if all of that plugin's changes are "winning." However, if that plugin is deactivated, then any changes it makes (unless the plugin defines new records) can be imported and merged.

[jaime74]

Imports work like this, Bash is an efficient merge. It does not contain unnecessary data. If nothing overwrites a plugin's changes, the Bashed Patch will not contain records from that plugin. There is no need to if all of that plugin's changes are "winning." However, if that plugin is deactivated, then any changes it makes (unless the plugin defines new records) can be imported and merged.

 

Yes, that's it!!! Surprisingly, your very last hint brought the solution after all!

What I didn't consider was that I have to deactivate my esp before building the patch and importing factions.

I tried it again, while it was inactive, and now the load order doesn't seem to count anymore! Whatever the order of the two mods is, Baurus now has both factions assigned, as long as my mod was deactivated during building the patch.

Though I still don't really understand why this is how it is and what exactly is going on during the build, it works as expected! The only problem would now still arouse when there's more than one mod to be deactivated/imported at the same time. But I think I can really neglect this now.

 

As I cannot give you more than 1 Kudos points, all I can say is: Thanks alot once again!! It's the first time that I managed to understand some of the deeper mechanisms of Wrye Bash! :)

[Tomlong54210]

Imports work like this, Bash is an efficient merge. It does not contain unnecessary data. If nothing overwrites a plugin's changes, the Bashed Patch will not contain records from that plugin. There is no need to if all of that plugin's changes are "winning." However, if that plugin is deactivated, then any changes it makes (unless the plugin defines new records) can be imported and merged.

 

Yes, that's it!!! Surprisingly, your very last hint brought the solution after all!

What I didn't consider was that I have to deactivate my esp before building the patch and importing factions.

I tried it again, while it was inactive, and now the load order doesn't seem to count anymore! Whatever the order of the two mods is, Baurus now has both factions assigned, as long as my mod was deactivated during building the patch.

Though I still don't really understand why this is how it is and what exactly is going on during the build, it works as expected! The only problem would now still arouse when there's more than one mod to be deactivated/imported at the same time. But I think I can really neglect this now.

 

As I cannot give you more than 1 Kudos points, all I can say is: Thanks alot once again!! It's the first time that I managed to understand some of the deeper mechanisms of Wrye Bash! :)

If you add a third mod to overwrite your mod's changes, then Bash should import the factions. Most mods are not import-and-deactivate mods. You should not have to deactivate your mod to have the changes imported. They just need to be overwritten by something, such that the changes do not show. In the case of a deactivated plugin, of course, the changes don't show (can't win) because the plugin is deactivated; therefore, Bash should import all of its changes (tagged for import.)

[jaime74]

If you add a third mod to overwrite your mod's changes, then Bash should import the factions. Most mods are not import-and-deactivate mods. You should not have to deactivate your mod to have the changes imported. They just need to be overwritten by something, such that the changes do not show. In the case of a deactivated plugin, of course, the changes don't show (can't win) because the plugin is deactivated; therefore, Bash should import all of its changes (tagged for import.)

Ok, once again I can see it clearer now. I try to summarize it in my own words: When a mod is tagged for "import", Wrye Bash will only import those records that are actually invisible somehow, i.e. either shadowed by some other mod in the load order, or because the whole mod is disabled.

 

This means, if I want to force Wrye Bash to import records from my tagged mod, I have two possibilities:

- place my mod before another mod that redefines the same records

- place my mod at the end, but then I need to disable it.

 

Very strange... though I think I can see the logic.