Okay, how do you get BAIN to install an extra folder that just has text files in it? BAIN will not install the Enhanced Economy folder that contains price files. The folder is called Enhanced Economy and needs to be installed directly in the data folder. What is the difference between this and tejon's folder. Does the folder have to contain an INI file or something? Also, what does that "has extra directories" function do. It has not helped with anything... How is BAIN deciding what folders to skip? Would putting...say...the Enhanced Economy INI file in the folder force it to be installed?

My enhanced economy has the INI in the "00 core" folder along with the ESP. From My experiences with this, everything in this folder gets installed . Also any folder under this one also gets installed . So any meshes, texture, sound Folder would be installed This includes INI files.

Guess IF i had done the List Feature thing i could post Mine pretty easy right now...lol

Edit are you talking about the Prices.xls file?
For me that file gets swept into the Docs folder along with the readme. the file is in the Enhanced Economy folder loose.Pretty sure this was a BAIN ready download. Ya looking at the structure I diden't make this....
Just Checked....Yep...is small file but Very Organized!

No, the price txt files. Look in BAIN. In the skipped list, you should see a number of "Enhanced Economy\XXX.txt" I think you have to choose the price files subpackage or something. I cannot access my desktop with LogMeIn right now, so I cannot check for the exact paths. Everything else is installed. The price files are not in the core folder. The price files are optional. BAIN has not ever failed me, installing default folders (i.e., Meshes, Textures, Sound.) I want to no the policy on non-default folders.

Edit: I have not altered EE's BAIN package, and I have the latest version. I already posted in the EE thread, and theNiceOne said to ask here because he does not use BAIN.

Ok dont listen to me , In my search for a White page for the installer tab.(no Grey backgrounds) I would take over and move files around by hand to get things where they belonged. so in this case it looks Like I moved that folder by hand and then deleted it from the installer. No grey Background (skiped files).
Not Clean but functional...lol.
Edit to not add to much clutter here...

Like I said not clean Thats why in my comment section I leave my self notes.

Yeah...I am a neat freak. I want all of my mods installed by BAIN such that they can all be uninstalled by BAIN, and BAIN cannot uninstall your EE folder.

I think the WB developers are going to have to decide whether or not they want to expand the BAIN functions beyond what Wrye initially intended.

OBSE's ability to read outside files is expanding the file list requirements of some mods.

Though, it's also possible that TheNiceOne could fix this by changing the price list files to have the INI extension.

I will suggest that, thanks.

That Would really make this the ONE stop program !! We are talking about just ".txt files in a folder. Still can keep the ".exe files as a NO no .

Edit: Ohh and DLL too!

If by that you mean, have BAIN install OBSE plugins, then I would have to wholeheartedly agree...well, there is still the shaders issue, I guess...

Just to duplicate it here. Changing the extensions to ini doesn't help, because WB is ignoring the entire "02 Price Lists" folder in BAIN, even with "Has Extra Directories" turned on. However, dropping a duplicate of the ESP file into the "02 Price Lists" folder does fix the problem with "Has Extra Directories" also enabled.

Thank you. I really appreciate the replies.

I have asked before about having Wrye Bash install OBSE plugins. The devs were against the idea, as OBSE .dll and .dlx files were different kinds of plugins that Wrye Bash was not intended to handle. While I respect the devs wishes for the official code, I personally prefer to be able to use Wrye Bash as a one-stop mod management program. I made a few modifications to bosh.py to allow it to install OBSE plugins (and Enhanced Economy price files):

--- Mopy/bosh.py        2010-03-06 07:39:22.000000000 -0800+++ ../../../oblivion/Mopy/bosh.py      2010-03-13 20:57:39.826161320 -0800@@ -9433,12 +9433,12 @@     #--Package anolysis/porting.     docDirs = set(('screenshots',))     dataDirs = set(('bash patches','distantlod','docs','facegen','fonts',-        'menus','meshes','music','shaders','sound', 'textures', 'trees','video'))-    dataDirsPlus = dataDirs | docDirs | set(('streamline','_tejon','ini tweaks','scripts'))-    dataDirsMinus = set(('bash','obse','replacers')) #--Will be skipped even if hasixtraData =http://forums.bethsoft.com/index.php?/topic/1081915-relz-wrye-bash/= True.+'menus','meshes','music','obse','shaders','sound', 'textures', 'trees','video'))+    dataDirsPlus = dataDirs | docDirs | set(('streamline','_tejon','ini tweaks','scripts','Enhanced Economy'))+    dataDirsMinus = set(('bash','replacers')) #--Will be skipped even if hasixtraData =http://forums.bethsoft.com/index.php?/topic/1081915-relz-wrye-bash/= True.     reDataFile = re.compile(r'(masterlist.txt|dlclist.txt|\.(esp|esm|bsa))$',re.I)     reReadMe = re.compile(r'^([^\\]*)(read[ _]?me|lisez[ _]?moi)([^\\]*)\.(txt|rtf|htm|html|doc|odt)$',re.I)-    skipExts = set(('.dll','.dlx','.exe','.py','.pyc','.7z','.zip','.rar','.db'))+    skipExts = set(('.exe','.py','.pyc','.7z','.zip','.rar','.db','.ace','.tgz','.omod'))     skipExts.update(set(readExts))     docExts = set(('.txt','.rtf','.htm','.html','.doc','.docx','.odt','.mht','.pdf','.css','.xls'))     imageExts = set(('.gif','.jpg','.png'))

SVN #213-217

esp RenGuardOverhaul.esp
if rename RenGuardOverhaul.esp to RenGuardOverhaulz.esp
Then error
---------------------------------
Traceback (most recent call last):
File "D:\Games\Oblivion Gold\Mopy\basher.py", line 3712, in RefreshData
bosh.modInfos.rescanMergeable(scanList,progress)
File "D:\Games\Oblivion Gold\Mopy\bosh.py", line 8055, in rescanMergeable
canMerge = PatchFile.modIsMergeable(modInfo) == True
File "D:\Games\Oblivion Gold\Mopy\bosh.py", line 13704, in modIsMergeable
if 'NoMerge' in modInfos[GPath(modInfo.name.s)].getBashTags(): reasons += "\n. Has 'NoMerge' tag."
File "D:\Games\Oblivion Gold\Mopy\bosh.py", line 7288, in getBashTags
tags = self.getRow().get('bashTags')
File "D:\Games\Oblivion Gold\Mopy\bosh.py", line 7021, in getRow
return self.getFileInfos().table[self.name]
File "D:\Games\Oblivion Gold\Mopy\bolt.py", line 676, in __getitem__
return self.data[key]
KeyError: bolt.Path('RenGuardOverhaulz.esp')
---------------------------------

Thanks for checking this out. I can of course add a dummy esp file to the additional folder in order to trick BAIN into installing the folder and its content, but I really, really think the best solution by far is to change BAIN to allow such installations. One thing is that it will protect the user from installing .dll and .exe files, but alos "protecting" the user from installing .txt and .ini files only have one effect: To create trouble. Look at the current thread about a player not being able to sit down with its char. The reason was that BAIN wouldn't install the ini file of kuertee's mod properly, just because the ini file was iniside an ini folder. I really don't see any advantage of BAIN having those restrictions.

Wait, would it have done this for SVN #214 too? I really didn't touch any of that stuff in #215-217.

On Extra Directories - I don't remember the exacts, but there was a real reason for not including every folder. The only thing I can think of as truly extra, though, are thumbnails.

At the time, I can certainly understand excluding extraneous text files and other files that are not specifically included in the Docs folder. Partly to be clean, partly to let the the modder add extra information in the package without it all being installed.

However, the new OBSE/Pluggy functions now make a lot of those text files an important part of the mod.

Clearly, at the moment, they cannot be put in a separate option folder or they get ignored, so people will have to remember that when building their BAIN structure for now.

In the long run, I wonder if it might not be possible to include a special file that indicates which extra directories should be included in the install options if you need to override WB's default handling?

Doesn't BAIN support .ini files inside the Data/scripts folder?

gothemasticator

It does, but that was a point of contention a while back because not everyone wanted to put their INI files in a "scripts" folder.

Regarding BAIN Converter Files. Was the intention with them to allow them to "fail gracefully" when converting multiple archives to a single BAIN archive if one of the original archives was missing?

For instance, in experimenting with an MMM BCF, the BCF was built with the BSA archive, the ESM/ESP archive and a replacement file for DiverseWaterlife.esp in a third archive. Ideally, if the DiverseWaterlife archive was not included when the user did the conversion, a warning would come up but the conversion would continue with that file just skipped.

What I got was this error:

Traceback (most recent call last):  File "C:\Games\Bethesda\Oblivion\Mopy\basher.py", line 6567, in Execute    message += '\n* '.join(sorted("(%08X) - %s" % (x,self.data.crc_installer[x].archive) for x in self.converter.srcCRCs)) + '\n'  File "C:\Games\Bethesda\Oblivion\Mopy\basher.py", line 6567, in     message += '\n* '.join(sorted("(%08X) - %s" % (x,self.data.crc_installer[x].archive) for x in self.converter.srcCRCs)) + '\n'KeyError: 1608422373L

This may be because the DiverseWaterlife.esp in the update file was a replacement for an identically named file in the ESM/ESP archive, but with a different CRC obviously.

I wonder if some flexibility is possible in this situation.

Next test will involve leaving out an archive that includes unique files, rather than replacement ones.

They shouldn't be activatable if any of the original archives are missing. If they are, that's a bug I need to fix.


If you'll pm me with steps to reproduce the above error, I'll see what I can do to fix it. The original archives you used, their data crc from the installer tab, the file order, etc.

It shouldn't matter whatsoever if any files are identically named. BCFs exclusively work off of the CRC values. If it has the same CRC, it's the same file. If it has a different CRC, it's a different file.

Exactly what kind of flexibility do you want? I'm hesitant to make BCF's much more complicated, but give me a proposal, and I'll consider it. Keep in mind that I can't do too much without breaking backwards compatibility.

I was hoping that a BCF could be created with, for instance, six archives being merged into it. When the user is applying the BCF, if any of the archives is missing, the files from that archive are simply skipped along with any empty folders resulting from them.

This would be useful for things like MMM's optional downloads and compatibility patches. It would allow a single BCF to create a BAIN friendly archive for all, or some of the optionals, without forcing the user to download patches for mods he/she doesn't have just to use the BCF.

The end result would be similar to the Filter tag for the bashed patch, where missing files are skipped gracefully rather than preventing the archive from being built at all.

As for the error above, the reason for it is obvious. I built a BCF using three archives from MMM: the bsa package, the ESM/ESP package and an archive containing an update for a single ESP where the earlier version was already included in the ESM/ESP archive. I then deleted the archive with the single updated ESP from the Bash Installers directory and attempted to apply the BCF to just the two remaining archives. It threw that error and refused to build the archive.

The refusal to build the archive in this case might be desirable, since it was a replacement file that was missing, but a more elegant failure would be better. A message explaining what was missing, or an option to build the archive without the missing file, maybe?

I'm not saying "No", but while I can see the occasional utility, I really don't want to do this. Let me explain why.

There has to be some level of hand-holding. Currently, BAIN does this by requiring that all archives are present (or it should...looks like I'll have to go fix something). If the BCF is activatable, the resulting package is usable (as defined by the BCF author). If you can do it, it'll work. If it won't work, you can't do it. Nice, simple, and easy to understand.

If I allow any and all source archives for BCFs to be optional (the easiest thing to code), then I'll have to enable the BCFs as long as there is even one of the source archives available. With this, the user is suddenly responsible for making sure all of the required archives are present. Then, if those are used, the user could wind up with a very broken final package (imagine if the BCF was applied when 5 of the 6 archives were missing). I could add in a notice of which files were missing, but I honestly don't see the end user paying that much attention. He'd apply a BCF, click through whatever pops up, activate the final package, and then, when the broken package (obviously) doesn't work, either start posting about how BAIN didn't work or (worse) just stop using BAIN.

I could get around this issue by allowing the BCF creator to somehow mark which source archives are required and which are optional. Then, the author becomes responsible for the hand-holding. This adds quite a bit of complexity to the existing code, and I'm also limited by backwards compatibility. I can't easily add anything to the BCF.dat file. If I do anything along these lines, this'd be the approach I take.

Either approach adds an extra burden to the user and BCF author, and if I go by their lack of adoption and general confusion, BCFs are already considered complicated enough. BCFs were never meant to be much more than they currently are; a quicker way to repackage BAIN unfriendly packages. BCFs are meant as a last resort if the original author is either unavailable or unwilling to repackage their mod. If a mod is still in active development, it is much preferred for the original author(s) to package it in a BAIN friendly manner.


After you deleted one of the source archives, BAIN should have disabled the BCF you made. It looks like the BCF data isn't refreshing properly. I'll poke around this weekend and fix this. I'll also look into what I'd have to do to support optional source archives, but at this point it is unlikely unless I can do it simply and not risk backwards compatibility.

Okay, for now the users will be told that all archives are required for any BCFs they want to use.

If you do have any success with a filter option then I can look at it again.

As it happens, the one big archive that I was hoping to make optional is no longer supported in MMM anyway, so no worries there.

Regarding INI's and TXT's in packages: BAIN will automatically sweep anything that looks like a readme (has readme/read me/etc in the name) and all *.txt files into the Docs folder. The idea behind this is to reduce the clutter from the hundreds of documents added by various mods all into one nice clean folder, so your main /Data folder isn't cluttered up. Similar idea with the INI files. INI files are only recognized if they're in the /Data/Scripts folder. Same reasoning there, it's not a good idea to promote mod creators putting their INI files right in the /Data directory, cluttering up everything, they should put it in the standardized INI folder (I know, I know, the whole /Data/INI versus /Data/Scripts discussion).

Anyway, I think the final decision would have to be left up to PM about design philosophy about these things, seeing as we haven't seen much of Wrye around lately. I know Wrye would definitely be against changing directories for the INI files. Personally, I think mod writers should stick with the /Data/Scripts directory as a default for putting .ini/.txt files needed by their mods, so we don't end up with too many extra directories.

Just my 2cents.

That is not a true statement as I have many mods with INIs properly installed through BAIN. BAIN does NOT sweep ALL doc files into the Docs folder. I have installed over 1000 BAIN packages. I am also a neat freak and absolutely fine with INI files being in the Data folder. It is nice not having to go down yet another level in order to tweak new INIs I am unfamiliar with or try out new settings. INIs, ESPs and ESMs are all find in my Data folder. I always have that folder sorted by "type." I have at least seven INIs in my Data folder, and it does not feel cluttered.

Edit: I also have INI files installed properly in "_tejon" and the folder use by Kuertee Horse Commands for the template INIs. None of the INIs from a mod I have tried to install have ended up in the wrong place. I do not think BAIN even blanket sweeps all text files to the Docs folder. I have not had to go into the Docs folder to get to tejon's readmes if I recall correctly.

New http://www.gamesas.com/index.php?/topic/1084996-relz-wrye-bash-thread/
(and http://www.gamesas.com/index.php?/topic/1079336-relzwrye-bash-thread-36/, for those searching through old threads)

I'll throw in 2 more cents on the ini stuff - I obviously want all the folders I've enabled through Pluggy...