@Torello: Replacing "itemiters" with "items" seemed to fix those types of problems for me. I have not been able to get back to Wrye Bash to play around anymore since I first tried that fix yesterday though.

Great news. Thanks for the info :tops:

@ PetrusOctavianus - Uninstalling was no good either, it just caused the same problem

Do you really have to do that? I do not. I thought that not having to uninstall was the point of having an "anneal" function...or part of the point.

So that is what anneal is for? :facepalm:

But wait...I always get errors when checking and unchecking the boxes in front of the various components of an already installed mod.
So how excactly does one one use that function?

That is the bug I was complaining about earlier. If you install v276, you will notice that you do not receive those errors when checking or unchecking different plugins. At least earlier, those errors were not supposed to be triggered. I think the "itemiters" thing fixed the problem for me, but as I am not near my computer, I have not been able to use Wrye Bash enough to be sure.

should be fixed in 280... which should be up in a few hours.
(er edit: what Tomlong said)
Pacific Morrowind

Oh, sweet! I will be looking forward to the update then (as if that's anything new.)

Edit: BAIN is still "forgetting" about my DLCShiveringIsles plugin. It is still there, but the package show it missing. If I forget to leave lock times on, I have to reorder my load list so that DLCShiveringIsles.esp is back where it belongs.

If you go into a BAIN archive and tick some extra options/espm, the box next to it become red, indicating missing items. In this case you should right-click and choose 'install missing' (or install to put everything in again if you want)

If you go into a BAIN archive and untick some options/espm, the background of the archive goes a bright and rather groovy shade of orange. This indicates theres too much of the archive installed, of which right-clicking 'Anneal' will fix.

This is why I love BAIN and think it is the best thing ever in the world ever (after bash)

As long as a package is installed, you can use anneal for any modifications, including cases where you could use "install missing." A case where you make a change and the package does not turn orange and anneal would be required to make the appropriate changes is when you change the priority of an installed package. Install missing will do nothing because the files are there, but anneal would "see" that they are the wrong versions of the files according to installation priority and make the required changes. I assume that this is why it is preferable to use install missing in the cases of red, as opposed to anneal because its lack of those extra checks makes it faster. Likewise, you could use "install missing" to install an uninstalled package instead of "install," but "install" has fewer checks whereas "install missing" is going by the record of missing files. You would not want to use the latter the package being installed is to overwrite files from another package. In the case where "install missing" is the ideal choice, when a package is already installed but you have added to its current configuration) using "install" could cost much more time. Disregarding the missing files list, it processes the entire state of BAIN and goes througj the evaluations to install all of he packages resources, instead of the few missing pieces. Trust me, it is not fun to accidentally choose "install" when you are only trying to add a plugin from a project that happens to also contain the renamed MMM BSA. Talk about wasting time...

Edit: Update about those problems I was having.

The good news, the problems that were generating error messages are fixed, and the ctrl+up/down does indeed move the packages. The bad news, I think the ctrl+up/down may always have been working, still not sure. However, the real problem is that when I use ctrl+down the focus jumps to the top of the BAIN window. When I scrolled back down, I found that the change in position occurred. Lastly, BAIN is still "forgetting" about my DLCShiveringIsles plugin. Doing "install missing" on that same package every time I initialize BAIN, when the plugin is still THERE, is getting old...that's all.

Question for the mechanics and creators of this utility or anyone who happens to use BAIN in this way:

Would having all self-made BAIN packages be packages as projects (not compressed into archives and as simple directory folders) speed up the opening of the BAIN tab?

It would seem so.

In writing my new thread I started really thinking through my recommended process and I think I'm about ready to recommend projects for all self made BAIN installs as opposed to repackaging into yet more archive packages. It would make less archives and therefore more space and would be a bonus if that also sped things up.

Not that BAIN is slow with my heavy weight BAIN packages of hundreds of mods the installer tab only takes about 90 seconds to open. The bashed patch process takes about 5 minutes by comparison.

Are there any real risks from having excessive amounts of projects as opposed to packages?

thanks

oh yeah - any eta on the new Wrye Mash?

There's an option "Auto-Refresh Projects: Toggles the auto-refreshing of projects on/off. Preferred setting: enabled" that controls whether the crc32's for files inside projects are calculated. This is recommended to be enabled because not calculating the crc32 basically makes Bash not know if the project is installed cleanly. If any changes are made to the project, BAIN won't know about it. I added it at request, but the option really shouldn't exist; it does so only because it takes so long to open the installer tab.

With that setting disabled, it is faster to open the tab if projects are used. Like I said though, it makes BAIN not work as intended all the time.

Really, it's better if you use archives. That way, the crc32 data is simply read from the archive and not calculated for each item in the project. Install speed can be maximized if the archives are both uncompressed and non-solid. Disk space is maximized if the archives are highly compressed and solid.

What makes the installer tab take the most time to open isn't projects/packages so much as installed mods that include large numbers of files. The entire data directory is scanned and crc32's calculated for each item in order to see if anything has changed since the last time BAIN was opened. Crc32 calculation is expensive in terms of performance, so it's best to avoid it when possible (i.e. use archives).

Speaking of which, do you know why it scans Developer directories (i.e., "--Projects")?

OK thanks that is great information - I get the gist of it, but does anyone have a good definition or place they can point me to for defining what crc32 is exactly. UESP and CS wiki yielded nothing - I take it that it is more an OS/Windows/tech term?

What does it mean in terms of the scanning and Oblivion install though - simple answer will totally work here.

Been working on new BAIN thread already at 25 pages in word.

thanks much.

http://en.wikipedia.org/wiki/Crc32

As I understand it, it's a process of putting a file through a series of operations that spits out a big code at the end.

If the file is changed in any way, putting it through the same operations will yield a different code, so you know the files aren't exactly the same.

Does this have anything to do with why BAIN keeps overlooking the DLCShiveringIsles.esp when I initialize it?

Offhand, I think that's an oversight. Those files would never be installed by BAIN, so I don't see any reason they should be indexed.

There might be some reason for it, but I really can't think of any. That said, it's been so long since I looked at the Bash code, I'm not as familiar with it as I once was.

Bash has been updated so many times since I was actively involved, that I can't definitively answer that. It does sound related...odd that it would only affect DLCShiveringIsles.esp though.

Edit: showler is exactly right. It is simply a way for BAIN to tell if a file has changed. Unfortunately, to calculate the crc32, it has to read in the entire file. Hard drives are relatively slow, and the data directory can have a LOT of files, so it takes time to process everything. When I add CBash support to Bash, I might be able to speed it up by having CBash do the file reading and crc32 calculating. I really doubt it'll speed it up much though...python isn't as fast as c/c++, but the hard drive is really the limiting factor. I'd be surprised if it shaves off more than a couple seconds from the scan speed. I'll look into other ways of speeding it up later after CBash hits v1.0. Might be some windows api calls that could be used to monitor the folders...really not sure.

It is not isolated to the DLCShiveringIsles.esp. When I was using v276, I used to have BOSS stored in a project folder, and every time I initialized BAIN the BOSS.exe file was missing, really missing. Now, the only thing that is every "missing" (it is in the list but BAIN does not see it) is the DLCShiveringIsles plugin. I have not tried turning the project into an archive to see if the problem persists. Nor have I tried removing the project to see if BAIN will ignore another "one" item. Right now, I am short on time, but I may try those things later.

I too have the DLCshivering Isle issue, but you are mistaken about the BOSS.exe.

BAIN was designed to not install exe, dll, shader.fx, or other such files.

It does install DLCshivering Isles even as a package but when rescanning it reads it as missing even though it is not .... to be more specific. It is not really missing.

Thanks for all that on the crc32 - I will make sure to emphasize the usage of packages and mention projects as more of a temporary/modder type thing.

I eventually took the file out. It may have been the BAT file that was being uninstalled. It does install the uninstall files that various mods such as OOO and I don't know...Eventually I was just leaving those files in the project as backup, but I think BAIN removed the EXE I put in the data folder manually as well. Something was definitely odd...anyway, I am sure about the DLCShiveringIsles.esp, and whether or not this is the problem I had before, it is quite bothersome. If I do not leave lock times on, I have to put the plugin in the right position every time I have to reinstall it through BAIN because it was forgotten.

Do you have the plugin packed in an archive Psymon?

Great program... couldn't play without it, but...

Couldn't get the new 280 version to work... installed it as usual, but nothing happens, had to revert back to 279.... any ideas what could have gone wrong on my side?

Thanks again for a great tool for Oblivion players!!

Use a command prompt and the -d switch to see what's up...

I have a problem too with ver. 280

Wrong image- names (path, numbers - reads names form bash.ini could not find names in images directory), missing images, wrong settingname in bosher.py (something with scustom1o2pt)

Same problem here, and the cause seems to be:

bolt.ArgumentError: Missing resource file: bolt.Path('images\\GeneticaViewer16.png')

Looking in the images folder, I see Genetica16.png and GeneticaViewer316.png, but no GeneticaViewer16.png.

doh why do I always do that... added a couple final tool launchers and messed up the file path on them UGH... sorry to all you 26 fast downloaders... fixed (it is uploading - has been for the last 9 minutes (the joy of dialup) - should be done in about 5).
Pacific Morrowind
ps. Haama, could you put up the changelog into the first post?

Sorry about this, maybe this one is me? The previous version worked fine, but now 280 gives me this, can't make heads or tails of it.....

Traceback (most recent call last):
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 4516, in Execute
raise
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 4478, in Execute
patchFile.buildPatch(log,SubProgress(progress,0.8,0.9))
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 13872, in buildPatch
patcher.buildPatch(log,SubProgress(subProgress,index))
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 19182, in buildPatch
race.eyes.sort(key=lambda x: eyeNames.get(x))
AttributeError: 'set' object has no attribute 'sort'

Help?