It's a known problem that occurs with some people and not others, so I added a lot of debug information whenever that error occurs...there should have been more to the error message than that. Namely, it should have printed out the formID that it was trying to lookup along with your load order.
I haven't been able to reproduce it.
Sorry for dpost but if I uncheck cobl catalog I get this problem instead
Again, there should have been more to the error message. The patch is unable to find either the default blue eye or argonian eye, causing it to fail. The patch isn't saved, so when Bash tries to rename the non-existent file, it fails.
Another one of those bugs that affect some people and not others that I nor PM have been able to reproduce.
Ahhh, I think I figured it out - something relating to merging and importing has changed - when I forced OOO not to merge into the bashed patch the old behaviour came back. Do things that are merged into the bashed patch overwrite imports?
They are supposed to yes, if they actually change the relevant fields. See a more detailed explanation below.
Silly question... but with the new Quiet Feet option in WB 291, do I still need the Quiet Feet MAX mod? Not sure if it's like with MAO that I still need the mod and WB helps apply it to NPCs added by mods or if it's a complete replacement.
I don't know the difference between Quiet Feet and Quiet Feet Max, so I can't tell you for certain. It looks like it replaces the sound files with an empty dummy; WB doesn't do this. Instead WB edits every creature so that it doesn't even look for the sound file.
Really a short answer like "Yes, check" or "No, don't" would be quite enough already, thank you... :blush:
No, don't.
The replacers swap all uses of one item for another. If you don't have the mod that contains the item that you're swapping the original for, it's pointless. It's also a rather slow patcher (adds 20-40 minutes without CBash, adds 3-4 minutes with CBash, depending on load order). Unless you know you need it, or a mod instructs you to use it, ignore it.
I asked PM to change the load order of Quiet Feet in BOSS and he did that and also said he would replace Quiet Feet with a WB tweak, so I believe it only replaces Quiet Feet and not Quiet Feet Max. I was only concerned about the footfalls for four legged creatures and not NPC's, so I was using Quiet Feet at the time. Hopefully PM or Waruddar will jump in and confirm the extent of the tweak, but I know it replaces Quiet Feet for sure. Not sure about Quiet Feet Max...
It only works on creatures, but you can specify which category of creature to silence.
There's something up with either the import patcher or some kind of interplay with tweaks and/or merged patches - see here:
Can someone explain how bash is supposed to handle conflicts with import mods and merged patches? Say I have two things flagged as import that change graphics on the same item - I assume the last one in the order wins. What happens if there's a merge patch later that adjusts something on the same item but includes vanilla graphics records?
Thanks for the screenshots, I'll look into it.
Import mods and merged patches should work almost exactly the same way as normal mods with the load order determining the winner (assuming they're all tagged the same).
When WB looks at a record, it looks at what has changed from the original record. If mod A changes an item's model path, mod B changes the model path and value, and mod C changes the item's name, the final record should have the model path from mod B (because it occurred later in the load order than mod A), the value from mod B (because it's the only one that changed it), and the name from mod C.
One difference between merged/normal mods and imported mods is that (for technical reasons) imported mods don't look at the history of the record. Instead, everything about the record is kept.
Using the same example as above, but placing import mod Z before all the other mods will result in the final record having all the values from mod Z except for the model path, value, and name (just like above).
Placing import mod Z at the end of the load order will result in the final record having all the values from mod Z (overriding the values form mod A,B,C).
Placing import mod Z after mod B and before mod C will result in the final record having all the values from mod Z except for the name from mod C.
Not that I'll be using the install OBSE plugin features, but was just testing a few...
I keep my OBSE plugins neatly organized in a project folder.
But anyway, BAIN didn't install OBSE_Elys_Pluggy.dlx
.dlx
This made Oblivion fail to start.
Thanks for the report.
That all looks like the same problem I reported with 3111390: http://oi52.tinypic.com/2vxj3io.jpg
So it's apparently not limited to the CELL patcher then and is a more general bug relating to multiple patchers because it's ignoring the last mod that needs to be imported if it's also the last mod in the load order to edit the record.
Looks like it.