[Heather beauchamp]

The Vwalk plugins are black and not purple because they're not mergeable. Purple is a subset of green. If a mod is black, then it can never be purple. Yeah, users should deactivate green, purple, and italic mods. How hard is that? All the variations mean different things, and it's always useful to be able to tell what set a mod is under just by looking at its name.

[Tanya]

Vwalk plugins are tagged NoMerge. Why are the tagged NoMerge if they are not mergeable in the first place?

[Javier Borjas]

I don't know that they aren't. I just know that if they're not purple, then they're not mergeable, or Bash is being wonky :shrug: The method used to apply the indicators seems to be imperfect yet, but I'm sure it'll be refined in coming releases.

[Andres Lechuga]

I just checked the Viconia Vwalk plugin in TES4Edit. It is mergeable. The black must be due to the deactivate tag. I think of the purple text as the leftover residue.

[Luna Lovegood]

Nah, that's just Bash being wonky. The deactivate tag should just make it italic. If you run the "Mark Mergeable" command, it should color itself purple. Like I said, the method used to apply the indicators is imperfect.

[luis ortiz]

Great, so I have to remark my existing setup in order for the "proper" color patter to evidence itself. I still the think the extra color is unnecessary, but that is out of my hands...

[Ross Zombie]

All this back and forth over a silly text color. I'd hate for my far more interesting and important issue with BAIN to go unnoticed because of it

[Batricia Alele]

I remember you posted about...Oh, the whole package not showing up in the Installers tab thing, right?

Edit: Yup, post #76, two pages ago...

[Lynette Wilson]

All this back and forth over a silly text color. I'd hate for my far more interesting and important issue with BAIN to go unnoticed because of it

I did have a post in there mentioning that I was not getting the same problem. With WB open or closed, adding new packages to the Bash Installers folder worked fine and BAIN updated itself immediately.

[Laura Mclean]

Adding new packages is working for me too. I am running the Python26 setup...in case that matters.

Edit: Can a check box be added to turn off the hide prompts? I kind of remembered where archives were hidden after the first or second time...

[Jodie Bardgett]

So where is Bash keeping the data on what installers it has? I just made backups of the Oblivion Mods\Bash Installers\Bash\Installers.dat file and then deleted it along with the .bak file and then loaded Bash back up. It still knows about the current packages AND project files, and is still not updating with news stuff being dropped into the Installers folder.

Ugh. Ok, I've determined Bash is no longer pointing to the right location for the Bash Installers folder. I just told BAIN to delete a package, which it says it did, which disappeared from the list, but the FILE is still sitting there in the folder. Did the location change for some crazy reason?

[Nikki Morse]

So where is Bash keeping the data on what installers it has? I just made backups of the Oblivion Mods\Bash Installers\Bash\Installers.dat file and then deleted it along with the .bak file and then loaded Bash back up. It still knows about the current packages AND project files, and is still not updating with news stuff being dropped into the Installers folder.

Ugh. Ok, I've determined Bash is no longer pointing to the right location for the Bash Installers folder. I just told BAIN to delete a package, which it says it did, which disappeared from the list, but the FILE is still sitting there in the folder. Did the location change for some crazy reason?

Wasent that info in the "table.dat" file....located in "Bethesda Softworks\Oblivion Mods\Bash Mod Data" i could be so wrong here....but with a back-up cant hurt...

[Julia Schwalbe]

All this back and forth over a silly text color. I'd hate for my far more interesting and important issue with BAIN to go unnoticed because of it

SILLY? THIS! IS! WRYE BASH!

Also, I just put together a package, and it showed up in the Installers tab just fine :shrug:

[FABIAN RUIZ]

Well ok. For whatever reason, a fresh install of 283 absolutely will not start, not even a brief window launch. This was after blowing out the entire Bash install, including the installers folder (which I backed up first).

Went back to 282, launches fine.

If it's any help, Windows 7 Home Premium 64 bit. Something is clearly broken, and quite frankly I don't have the patience right now to go fiddling with it to find out what.

[claire ley]

I recently switched to using the .pyw launcher. Have you tried launching WB with that?

Edit: I am still on 32-bit XP.

Edit: I just noticed I have Kuertee's Horse Commands mod installed, INI files in the INI folder and all, and I do not have "has extra directories" checked. What is up with that? My setup seems to be immune to all of the major bash quirks: I missed the race importing issue, the random python errors, the INI folder problem...maybe my setup is buggy or something...

[Bonnie Clyde]

My launcher shortcut has been pointed to the .pyw file for ages. Fresh install of 282 works perfectly. Fresh install of 283 simply will not start.

[Mark]

Did you install v283 on top of v282, or did you actually do a fresh install? I usually install the releases on top of the older versions.

[Louise Dennis]

I did a fresh install of 283 because I thought that would solve the problem with BAIN not updating. I *HAD* simply put 283 in over the top of 282 and figured it was all working since nothing had been obviously broken. Until BAIN refused to see a package I put in.

Wiped and fresh installed with 282, no trouble at all.

[Cesar Gomez]

Okay I think this is going to take some time... more than 60 posts since I uploaded 283 last night... good thing I timed this for before an evening I would have a bit of time at least!
now starting to reply to the many posts:

Just tried out 283 - brilliant release. Really like the way the Deactivate tag has been implemented - seems to work perfectly. I even used BOMM to override the LoadingScreens.esp to include the Deactivate tag, re-ran BOSS and WB changed the text to Italics without having to do anything else

Btw, my bashed patch is NOT in italics.

Great!

The purple text only seems to show up by marking the mod as mergeable - so although easy to correct, I think it would be great if it detected it automatically (test done by installing a new mod via the Installers tab).

sure can do... consider it done.

Thanks so much for all the hard work you do and the fantastic responsiveness - very much appreciated.

Edit:
Here are some ESPs that are erroneously being shown in italics...

• RumpleMod.esp
  
• LostSpires-DarkForest patch.esp
  
• xulBeachesOfCyrodiilLostCoast.esp
  
• VeronaHouseBloodlines-LushWoodlands fix.esp
  
• xulRiverEthe.esp
  
• xulCheydinhalFalls.esp
  
• Colourwheels sixy Imperial Legion.esp

...can't see any pattern for these exceptions, but listed thenm in case it helps.

There were some others, but trying to mark them as mergeable seemed to remove the italics.

I'd like to be more responsive... I almost always lately don't respond as often as I want to.
I'll look into those mods (though I can't see a pattern either), thanks for all the reports and user feedback

A whole bunch of my mods were italicized at first, including ones that obviously shouldn't have been.

When I restarted, though, most of them went back to normal and the ones that were left in italics seemed to be correct.

hmm I didn't see that in my testing but I was testing other things at the same time so I could have started, tested other stuff, more changes to other stuff, restarted and then looked at the accuracy of the italics (all correct as far as I've seen)... though I don't see any reason that it would be incorrect and then go correct, if it is doing that at least it is correcting itself.

Unfortunately, that's not how it works. Since Race record entries require the mod to be either active or merged, the complete changes of the mod are entered into the bashed patch. The Body-F tag only gives priority to that entry which allows it to over-ride any other mod that A: Doesn't change that particular record as well and/or B: Doesn't also have a Body-F tag.

If the tag allowed for true "import" of that data, like the NPCFaces tag, then the load order wouldn't matter at all.

For the record, in my bashed patch the RBP relations information, and most other data was getting through even before I moved the EVE_KhajiitFix.esp. The main thing I was losing was the changes to the racial powers, which were getting reset by the EVE mod. This is because Spell imports aren't supported yet, I believe.

Since the primary purpose (possibly only purpose) of the EVE_KhajiitFix.esp is to redirect the foot model to a different one, moving it and using the Body-F tag is the easiest solution.

One more thing, just as a disclaimer, my copy of the RBP core file was still tagged with Body-F and Body-M from when I was working around the Race bug from the 282 version. I've removed them and am currently rebuilding my patch to see if it alters the results at all.

Oh... okay, I just misunderstood what the race record tags were doing... why can't they be like other imports, importing just what's been tagged? If that was considered, but canned because it would cause problems, then that's the way it is :sheug: But if it's just that no one's brought it up, then consider this a feature request

The reason the racepatcher doesn't work like the standard import X: Bash currently via the bashed patch doesn't support (it could but would be a fair bit of coding... maybe in the future) adding brand new records; and hairs, eyes are brand new records (for the most part, exept for unlocked vanilla ones basically) which are then linked to in the race... necesitating the race be active/merged; same for racial powers (which it is true are not imported by any tags). However for Body-F, Body-M, R.Tongue, R.Teeth, R.Relations, and the upcoming R.Ears tags it would work fine not to just import without them being active/merge since those are simple paths for the most part... I'll add that to my list - and aso racial powers (probably will be tag R.Powers). Do note that currently (as of 281) it only imports changed values for each tag... like Body-F with just a changed foot path the rest will not be imported (but still could be merged last etc)

Can the purple highlighting be removed? The italics and the deactivate tag are cool, but I do not think the purple is very useful anymore.

not going to happen... but see my next post (running out of number of allowed quotes)

There appears to be a problem with BAIN in 283. I've dropped a couple of files into the Bash Installers folder and the installers tab is not registering that they've shown up there. Even a full data refresh did not fix this. This was working fine with 282.

adding to investigate list
Pacific Morrowind

[Mariana]

Okay, whatever to the purple thing...at least it is pretty. My Bash pages are already updated with the purple anyway. I only had to add the bit about the new italics distinction.

Edit: Are users warned about activated mods with the deactivate tag similarly to the warning about filter-tagged mods?

[Chantelle Walker]

I thought it was just a neat way to show which mods were mergeable but shouldn't be merged, a visual indicator of the NoMerge tag. It's not in the way at all, it conveys important information at a glance, and it's pretty. It's the same reasoning for the showing mergeable mods in green :shrug:

that's basically my view on it... including the pretty part

If whoever makes this wrye bash ever looks at this thread, I'd like to say thank you for helping me to get oblivion running with my awful cluster[censored] of mods.

thank you!

Wrye isn't on much, neither is Raziel23x right now but haama, Waruddar, Lojack, and myself read these fairly regularly... glad to hear that you are finding it useful and enjoying it.

But, some people like the purple text. Others don't. Some find one way confusing, others find the other way confusing.

PacificMorrowind would have to decided which group of people to please.

not quite... muahahahaha... I can at least partially please everyone; the wonders of the ini! I had already been thinking of letting users set what colour exactly the green/black/purple where. Well in that case you can set purple to black or green or something else... should be in 284.

All this back and forth over a silly text color. I'd hate for my far more interesting and important issue with BAIN to go unnoticed because of it

yipes... I don't know if the Bash thread has ever had well over 70 posts in 24 hours!

Adding new packages is working for me too. I am running the Python26 setup...in case that matters.

Edit: Can a check box be added to turn off the hide prompts? I kind of remembered where archives were hidden after the first or second time...

oh yes definitely... should be in 284.

So where is Bash keeping the data on what installers it has? I just made backups of the Oblivion Mods\Bash Installers\Bash\Installers.dat file and then deleted it along with the .bak file and then loaded Bash back up. It still knows about the current packages AND project files, and is still not updating with news stuff being dropped into the Installers folder.

that well those are the two files... if they aren't there bash shouldn't be able to get that data... double check that you don't have a second location accidentally created (ie C:\Oblivion Mods\Bash Installers\Bash\Installers.dat rather than C:\games\Oblivion Mods\Bash Installers\Bash\Installers.dat for example) - that would also explain why it wasn't finding your newly placed packages.
Pacific Morrowind

[Yvonne]

Even if users are allowed to change the color, I am NOT going to update my docs for that. A users should know what that means if they do that.

[Farrah Lee]

Did you notice my comment about ctrl-A in the mods tab?

I get this error:

Traceback (most recent call last):  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 1389, in OnItemSelected    self.details.SetFile(modName)  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 1501, in SetFile    tagsStr = '\n'.join(sorted(modInfo.getBashTags()))TypeError: sequence item 3: expected string, Path found

[Veronica Martinez]

Like Arthmoor, my Installers tab is also acting wonky.

Attempts to "List Structure" mods that are installed correctly produces the error:

Traceback (most recent call last):  File "F:\Games\Bethesda Softworks\Oblivion\Mopy\basher.py", line 6283, in Execute    text = installer.listSource(archive)  File "F:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 10374, in listSource    raise InstallerArchiveError('Unable to read archive %s (exit:%s).' % (apath.s,result))bosh.InstallerArchiveError: Unable to read archive F:\Games\Bethesda Softworks\Oblivion Mods\Bash Installers\LessAnnoyingMagicExperienceEV 1,7.7z (exit:1).

Attempting to "Refresh" working installed mods produces the error:

Traceback (most recent call last):  File "F:\Games\Bethesda Softworks\Oblivion\Mopy\basher.py", line 6392, in Execute    installer.refreshBasic(apath,SubProgress(progress,index,index+1),True)  File "F:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 9713, in refreshBasic    self.refreshSource(archive,progress,fullRefresh)  File "F:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 10250, in refreshSource    raise InstallerArchiveError('Unable to read archive %s (exit:%s).' % (archive.s,result))bosh.InstallerArchiveError: Unable to read archive F:\Games\Bethesda Softworks\Oblivion Mods\Bash Installers\Kragenirs_Death_Quest_1_06-26219.rar (exit:1).

And, some mod packages just straight up refuse to open correctly. I repackaged the files and made a new archive, containing only the esp in the root of the archive, and a readme file in the Docs subfolder. However, bash claimed this new installer was "Corrupt/Incomplete", yet running the "Open" command on it shows the file to open just fine in winrar. The above two commands also failed in the same way. Other archives were downloaded directly from the Nexus, verified that their directory structures were compatible, and still failed with the all of same errors above.

[Marguerite Dabrin]

that well those are the two files... if they aren't there bash shouldn't be able to get that data... double check that you don't have a second location accidentally created (ie C:\Oblivion Mods\Bash Installers\Bash\Installers.dat rather than C:\games\Oblivion Mods\Bash Installers\Bash\Installers.dat for example) - that would also explain why it wasn't finding your newly placed packages.
Pacific Morrowind

I figured, but no, deleting them outright did nothing to stop BAIN from still seeing populated data. This was before I went about trying to fix it too so there were no other copies of the stuff hiding anywhere. With the fresh install of 283, I made triple sure of that, but then of course that flat out refuses to start with no indication anywhere about why.

Buggy or not, 282 is working as expected so I'll stick with it for now until something pops, cause I really don't want to go blowing up the install again.