[Jessie]

When rebuilding the patch, wasn't there a save option (in v284) in case you changed a bunch of options, but then wanted to go back and check something before building the patch? In v285, If I choose "Cancel" all your changes are lost. :unsure:

[Sunnii Bebiieh]

When rebuilding the patch, wasn't there a save option (in v284) in case you changed a bunch of options, but then wanted to go back and check something before building the patch? In v285, If I choose "Cancel" all your changes are lost. :unsure:

Don't nelive that was until 286, you could grab the SVN

[Marcus Jordan]

Yep, those two tags are bugged in 285 (and some preceding versions maybe?). It's fixed in 286

286?

The latest version i could find when i started playing Oblivion again was 285? Where did you find that one, i can not seem to find that version on TES nexus or on Wryes own site.(Which seems to be outdated much. )

[Kira! :)))]

286 is not yet released.

[Siobhan Thompson]

Ah that would explain a few things, thanks Waruddar.

[kasia]

Having some issues with 285. Worked just fine a week ago (last rebuild), but out of institutional paranoia I decided to rebuild my patch for good measure (and while I was at it, remove the rational names option as I keep getting the French names for poisons [e.g. X en Wounding]). Instead, I'm getting this:

Traceback (most recent call last):  File "C:\Games\Oblivion\Mopy\basher.py", line 4921, in Execute    raise  File "C:\Games\Oblivion\Mopy\basher.py", line 4880, in Execute    patchFile.initData(SubProgress(progress,0,0.1)) #try to speed this up!  File "C:\Games\Oblivion\Mopy\bosh.py", line 14262, in initData    patcher.initData(SubProgress(progress,index))  File "C:\Games\Oblivion\Mopy\bosh.py", line 14858, in initData    masterFile.load(True)  File "C:\Games\Oblivion\Mopy\bosh.py", line 4980, in load    self.tops[label].load(ins,unpack and (topClass != MobBase))  File "C:\Games\Oblivion\Mopy\bosh.py", line 4001, in load    self.loadData(ins, ins.tell()+self.size-20)  File "C:\Games\Oblivion\Mopy\bosh.py", line 4852, in loadData    worldBlock = MobWorld(header,selfLoadFactory,world,ins,True)  File "C:\Games\Oblivion\Mopy\bosh.py", line 4644, in __init__    MobCells.__init__(self,header,loadFactory,ins,unpack)  File "C:\Games\Oblivion\Mopy\bosh.py", line 4468, in __init__    MobBase.__init__(self,header,loadFactory,ins,unpack)  File "C:\Games\Oblivion\Mopy\bosh.py", line 3991, in __init__    if ins: self.load(ins,unpack)  File "C:\Games\Oblivion\Mopy\bosh.py", line 4001, in load    self.loadData(ins, ins.tell()+self.size-20)  File "C:\Games\Oblivion\Mopy\bosh.py", line 4667, in loadData    header = insRecHeader()  File "C:\Games\Oblivion\Mopy\bosh.py", line 482, in unpackRecHeader    raise ModError(self.inName,_('Bad header type: ')+type)bosh.ModError: Oblivion.esm: Bad header type: 

[No Name]

That's saying that your Oblivion.esm is corrupt.

If you have the latest english version of Oblivion.esm, you can check against the following to see if Oblivion.esm has changed:

Size : 277504985CRC32: 2FF840C5MD5  : 1D276C84CBEFB66CB420150801F49F3DSHA1 : 33D7C64E685E0175D567FD149B8C829ED07A441D

If it has changed, you'll need to get a new version of Oblivion.esm (likely by reinstalling / patching). Unless you've tried editing it and something went really wrong, I'm not sure how it happened. Might be a problem with your filesystem or hard drive...

[Aaron Clark]

Thanks for the quick reply Waruddar, fixed it by reinstalling SI to replace the .esm. Which leaves me worried about the latter possible causes...*sigh*

[Bad News Rogers]

Yeah, things aren't much fun when you have to worry about data integrity. It tends to bring on a sudden burst of backing up...while tedious, it's never a waste of time.

[Robert DeLarosa]

Thanks for a great program.

After a long hiatus from Oblivion, I reinstalled. Since I manually did something similar to BAIN, I decided to install everything with that.

One thing that I think would improve BAIN, is an option that only show the esp/m's in the currently selected Sub-Package. Some packages can have many esp/m's so this would speedup the installation process.

[Laura Hicks]

Thanks for a great program.

After a long hiatus from Oblivion, I reinstalled. Since I manually did something similar to BAIN, I decided to install everything with that.

One thing that I think would improve BAIN, is an option that only show the esp/m's in the currently selected Sub-Package. Some packages can have many esp/m's so this would speedup the installation process.

I want to be able to see all of the plugins that are going to be installed. That would be kind of bad if I could only see a single sub-package's plugins. That would provide for users to make many mistakes, thinking that they only have a certain set of plugins checked because they cannot see that other things are checked. I think having all plugins unchecked by default would be helpful in those cases, however. Even selecting one subpackage in MMM can take a minute to sort out because I do not use most of the available add-ons. I uncheck ten and leave one...


Edit: I'd rather just check the one...

[pinar]

I want to be able to see all of the plugins that are going to be installed. That would be kind of bad if I could only see a single sub-package's plugins. That would provide for users to make many mistakes, thinking that they only have a certain set of plugins checked because they cannot see that other things are checked. I think having all plugins unchecked by default would be helpful in those cases, however. Even selecting one subpackage in MMM can take a minute to sort out because I do not use most of the available add-ons. I uncheck ten and leave one...


Edit: I'd rather just check the one...

That was why I suggested an option to do it. Because I agree that if the choice is between showing all and only showing one sub-package, it is better to show all. But an option to only show a sub-package, will be helpful.

[LADONA]

I have WB v285, and while building the Bashed Patch and checking mods, I get the following:

NoMerge Tagged ModsFollowing mods are tagged NoMerge and should be deactivate and imported into the bashed patch but are currently active. ?  Younger Hotter NPC's v1.0.esp 

If I try to click on the mod (Younger Hotter NPC's v1.0.esp) in the Mods tab (to make it imported with a + or bullet icon instead of a check mark, thus reducing an esp in my total 255 count), it deselects the Bashed Patch itself. In essence, it does not allow me to deselct the said mod even though imported.

I've seen the BOSS log messages for other mods that have similar issues (Sensual Walks patches for some mods), that don't get imported. Maybe this is something similar? Maybe a fix can be included in WB v286?

[Darlene DIllow]

i just received the below error in wryebash v285 when attempting to rebuild the bashedpatch. it appears to interrupt the rebuild process, so i don't think the bashedpatch has rebuilt properly. i have no BOSS log errors with my current load, which is FCOM.
i think i read on the wryebash page somehwere that it's advisable to clean or wipe/reset the bashedpatch before rebuillding it, but i didn't see any option to do this when right-clicking the bashed patch.

i don't have checks in any boxes for esps that are have red boxes, green text, or italicized text. i wonder if it is related to my settings in the alias mod names, merge patches, import x y z, globals, tweak, Cobl, etc. wryebash seems to have rememberd them from the last time i rebuild the bashedpatch, so they are probably the same.


ps- i did get wrye bash to succesfully rebuild my patch earlier. since then, i added the blood&mud.esp and activated the fcomblood&mud.esp, and installed the OMOD version of darn's darkUId. and therefore wanted to rebuild my bashedpatch.

wxPython: stdout/stderr

Traceback (most recent call last):
File "C:\Games\Bethesda Softworks\Oblivion\Mopy\basher.py", line 4921, in Execute
raise
File "C:\Games\Bethesda Softworks\Oblivion\Mopy\basher.py", line 4881, in Execute
patchFile.initFactories(SubProgress(progress,0.1,0.2)) #no speeding needed/really possible (less than 1/4 second even with large LO)
File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 14280, in initFactories
updateClasses(readClasses, patcher.getReadClasses())
File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 19136, in getReadClasses
classTuples = [tweak.getReadClasses() for tweak in self.enabledTweaks]
File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 18664, in getReadClasses
return (MreRecord.type_class[self.key],)
KeyError: ('BL Leather Boots', '%s ')

[Dan Scott]

I have WB v285, and while building the Bashed Patch and checking mods, I get the following:

NoMerge Tagged ModsFollowing mods are tagged NoMerge and should be deactivate and imported into the bashed patch but are currently active. ?  Younger Hotter NPC's v1.0.esp 

If I try to click on the mod (Younger Hotter NPC's v1.0.esp) in the Mods tab (to make it imported with a + or bullet icon instead of a check mark, thus reducing an esp in my total 255 count), it deselects the Bashed Patch itself. In essence, it does not allow me to deselct the said mod even though imported.

I've seen the BOSS log messages for other mods that have similar issues (Sensual Walks patches for some mods), that don't get imported. Maybe this is something similar? Maybe a fix can be included in WB v286?

If the Bashed Patch is deactivated after using import, that usually indicates that the plugin cannot be import-only, right...?


Edit: It depends on what is imported, I guess. I do not use those plugins, so I do not know what the contents entail.

[Daniel Holgate]

I agree that if the choice is between showing all and only showing one sub-package, it is better to show all. But an option to only show a sub-package, will be helpful.

I actually find it quite confusing when selecting a sub-package that adds a bunch of esps to the list because the list is sorted alphabetically and the new esps get mixed in. I think it would be nice if the esps were sorted first by sub-package, and then alphabetically. That way, the esps added by a sub-package are still grouped together.

[lucile]

I have WB v285, and while building the Bashed Patch and checking mods, I get the following:

NoMerge Tagged ModsFollowing mods are tagged NoMerge and should be deactivate and imported into the bashed patch but are currently active. ?  Younger Hotter NPC's v1.0.esp 

If I try to click on the mod (Younger Hotter NPC's v1.0.esp) in the Mods tab (to make it imported with a + or bullet icon instead of a check mark, thus reducing an esp in my total 255 count), it deselects the Bashed Patch itself. In essence, it does not allow me to deselct the said mod even though imported.

I've seen the BOSS log messages for other mods that have similar issues (Sensual Walks patches for some mods), that don't get imported. Maybe this is something similar? Maybe a fix can be included in WB v286?

Are you ticking the import options for the mod before you build the bashed patch?

Initially when you introduce a mod to your load order, have it ticked, uncheck bashed patch and right click Rebuild bashed patch, when the build options comes up individually select all the options on the left of that dialogue, in the right hand pane you will get a list of import options for mods that need it, go through all of these and find the ones where Younger hotter NPCs is not checked, then hit the Build patch button.

After that completes (and the import options from that mod are now part of the bashed patch) you can go back up the load order in the mods list and de-select Younger Hotteter NPC and it should on first click turn to either a dot or + (I dont use the mod so not familiar with its import options.

[BRIANNA]

go through all of these and find the ones where Younger hotter NPCs is not checked, then hit the Build patch button.

The above snip should read

.. go through all of these and find the ones where Younger hotter NPCs is not checked, check them, then hit the Build patch button.

For some reason I cant edit my last post.

[Floor Punch]

hey,

just a bump for my wryebash error message i posted yesterday, a few messages up.



ps- i hope this is not too soon to be bumping. apologies if so.

[Stacy Hope]

hey,

just a bump for my wryebash error message i posted yesterday, a few messages up.

Did you change your Bashed Patch configuration when you rebuilt it (i.e., checking B&M in the Races section)?

[Racheal Robertson]

It's a known bug in 285 that's been mentioned on practically every page in the thread. Sometimes it's even mentioned twice in the same page.

It's long been fixed for 286. We're trying to wrap things up and get that version released.

[vanuza]

We're trying to wrap things up and get that version released.

Take all the time you need! Quality can not be rushed. :trophy: We can wait patiently. It is free, after all. :icecream:

[Nina Mccormick]

It's a known bug in 285 that's been mentioned on practically every page in the thread. Sometimes it's even mentioned twice in the same page.

It's long been fixed for 286. We're trying to wrap things up and get that version released.

peppergomez is still new to the forums. The whole catching up on a thread before posting a problem has not yet been ingrained yet.

peppergomez, in the future, please do read the thread before posting. Bash is updated regularly, so it pays to try to stay up-to-date with it, especially for users of mods that really take advantage of Bash (i.e., FCOM.) You still have newbie credits, no worries.

[Jesus Duran]

okay, will do tomlong. thanks for the tip. based on warruddar's reply, i re-read the earlier pages and saw other's bug posts on the subject of this type of wryebash error when rebuilding the bashedpatch.

EDIT- answered my own question by locating the exact same wryebash error earlier in this thread.

i can't find the link now (i'm at work), but i thought i read somewhere on tesivpositive.com that it was advisable to clean/wipe the bashed patch before rebuilding it, but i didn't see any instructions on doing this on the wryebash page and right-clicking on the bashed patch in wryebash doesn't offer an option for this (least not that i noticed). basically, the advice seemed to indicate that an older version of the bashedpatch could interfere with the rebuilidng of a new bashedpatch if not cleaned properly. it's possible i misunderstood this advice, though. based on not finding this advice anywhere in my current search, i'm thinking i did misunderstand and that this isn't a required step.

[Jade Payton]

The bug was in the Tweak Names patcher, specifically the Armor and Clothes tweaks. So if you disable those two tweaks, you should be able to rebuild the patch.

If you've read somewhere that you should "clean/wipe" the bashed patch before rebuilding, that's bad advice. The bashed patch is created from scratch every time you build the patch. So messing with the bashed patch before rebuilding it won't hurt anything but it certainly won't help anything either and is a waste of time.