[Jaki Birch]

With 289 and 290 not possible.

Seems I really have to install the whole game again?!

No problem here building a patch under 290. I'm running Kvatch Rebuilt as well so it isn't likely to be a fault with that unless your copy of the mod is corrupted. Rather than reinstalling your whole game, try reinstalling KR and see if that helps.

[Assumptah George]

Right click the pakage you are installing and check "Has extra Directories".

Thanks!!

3+ years of Wrye Bash and I'm still learning the features.

[Hayley Bristow]

No problem here building a patch under 290. I'm running Kvatch Rebuilt as well so it isn't likely to be a fault with that unless your copy of the mod is corrupted. Rather than reinstalling your whole game, try reinstalling KR and see if that helps.

Thanks for your effort.

Just tried that also to no avail.
Also after that I then deinstalled Wyre Bash, Python, reinstalled them again, used v290 with v287, reinstalled Kvatch Rebuilt and all it′s patches and was finally able to built bashed patch. No errors. Fine so far.
I started the game, new game - wow! It loaded!
I use "Alternative Start Arrive by Ship", no problems inside the cabin.
Screen loaded, arrived in Anvil, had some pop up messages...then I saw 2 Erics (from viking village) instead of one, next thing I could not open any containers or the luggage, had some beep errors (Windom Earle's Crash Prevention), went to the city gate and the game crashed.

It did not matter if I went to IC or Anvil, everywhere the same. Some double NPCs from different mods, container does not open and crashes, crashes, crashes...

Just to point it out again. I did NOT change any of my mods. It is the same loading list I had with v287!

Seriously, I spend so many hour since v288 came out to try to make the game run again, that I could have installed the whole game with all my mods three times - and I did it already one time.

Because I am to stupid to figure out, what is the problem with the new Wyre Bash, I will leave that to better people and just go straight back to plan A.
Delete the whole mess, install the game again, use 287 and hope that my problem then is solved. At least the game, Wyre Bash 287 and Wyre Pyhton 03a will be "clean" again.
Hopefully nobody else has that kind of problems.

By the way, I still have WinXP SP2 as PC system.

[He got the]

Another minor anomaly:
Select the Installers tab.
Look at the lower right corner.
I see Packages: 248/4( << the ( is actually part of a 6. The actual number of packages I have is 464.

The space needs to be resized in the Installers tab or maybe abbreviate "Packages" to "Pkgs:".

[Bereket Fekadu]

Zoar5:

I understand your frustrations, but you should be a little bit more grateful for all the hard work that PM and the team put in to provide you with new features and improvements to Wrye Bash.

For future, unless you are willing to be a beta tester and understand the risks of using a bleeding edge software product, you should just stick with the versions that have been tried and tested.
v287 works fine.

This isn't like microsoft or something, where they have their own team of internal testers. We are the testers.

Cheers, I hope you get your game sorted out.

[Haley Cooper]

Well sorry for the new round of bug reports - I have a few new feature requests, but they seem to me a bit premature considering the reports.

Still I'd like to get them in and make them easy to find. :unsure:



Best of luck with working the bugs out and thank you for considering these additions.

And most of all thanks for the work you do.

[edit] mistakes [/out]

noto so many bugsies it looks like with 290 (feverishly knocks on all the wood he can find - and given that I live in a house with real hardwood floors thats a lot)
1. already _planned_ ... I'll try to get it actually done instead of just on the list.
2. huh that does sound like a good idea... adding to the list

This request has actually already been sitting on the bench for quite a while. Since April I think. Requested for different reasons.
There is discussion to revise the entire directory structure that Bash uses. I'm not sure why it sits unaddressed.
The official request is http://sourceforge.net/tracker/?func=detail&aid=2985605&group_id=284958&atid=1207904

I second this request. Regardless of the issue with multiple installs.

The issue of multiple installs is not as simple as just moving the installers.dat file et al into the Mopy folder though.
In fact, as far as multiple installs go, I'm not sure what can be done on Bash's end to be able to rectify the problem.

Even if all the dat files are moved so that they are isolated to the bash instance, there is still other things in the BAIN Mods folder that will cause conflict.
In particular, the Bash Mod Data\Hidden folder contains any hidden plugins as well as any hidden installers.
You don't want those changes mitigated to your other instances of Oblivion.
The hidden plugins are not so much of an issue, they are specific to one instance of Oblivion.
The hidden installers on the other hand.. No matter how you cut it, if you use a common BAIN mods folder for multiple instances of Oblivion, you cannot hide any installers, or those installers will be hidden in every instance.

There may be other important considerations as well.

Ideally, I think all the bash settings files belong in the Mopy folder. Not in the user profile or in the BAIN Mods folder.

In order for bash to properly support multiple installs, the installers must be segregated from all instance specific stuff..
There must also be a different way of hiding installers so that they don't remain hidden when the same installers are listed in another instance.
BCF's can probably stay with the installers. Pretty much nothing else though, from what I can tell.

just no one has got around to it - it works currently although is not the best so never been high on the list... pushing it up on my list and I'll make sure to get it done for 291... hmm probably put all the data/settings files into Mopy/foldername (so as not to leave it cluttered and to have a single folder rather than x dozen or so files in with x 2 dozen files are what you want to backup) ...erm what folder name would be good hmmm not sure.. any ideas? (thought about /data but that is already used... ah maybe /profile ... what do you all think?)

So what's the working state on CBash these days?

it works amazingly fast ... More patchers are possible with it... the current state: works great except for one bug: it can't handle more than 255 esp/ms including imported and merged ones. Also still a couple patchers to finalize/double check.

Never used it myself, I dont think I ever will either if I were to utilise hidden functions I know sometime in the future I would forget what has been hidden and cause myself more problem solving grief

---------------------------------------------------------

Edit2: The following resolved with v290


Edit1: Also tried going back to Installers, multi-selecting all and re-installing everything (noticed T.I.E version listed as 1.37 when I have 1.39, so I guesse some information had been lost along the way recently changing different versions of Wrye bash) - Long story short; All went well up until the end of the build again and received the same stdout error noted above.

I've never used the Hide X features personally either.
ah I like Edit 2
in regards to loosing data, it shouldn't loose any data for anything but the installers - and even then only if you have used installers in 288 there is a small chance it'll have saved some bad data which it won't be able to link to the real data and hence get lost... sorry about that.

I have a question, I used Bash's merge races function and it works well but I don't like that it assigns random hairs for NPCs who have no hair. For example it assigned a long hair for an orc smith in SI who supposed to be bald. So I disabled the merge races option in the bashed patch and used Tes4Gecko for the race merging. Is there any way to disable this option in Bash? Why was it included in the first place?

I could add an option to not assign hair/not assign eyes/not assign hair or eyes... (currently only way to disable would be to edit the racepatcher code of your copy)...

Ooops; Addendum

Also found a typo. In Tweak settings - Actor Strength Encumbrance Multifier (Multiplier?)

oh that that would be British English as used in Canada... ... okay it is just a typo unlike with color and colour I can't say that... fixing, thanks.

Semantics really, but the way v290 is packaged, it suggests the bash docs should be placed in Data\Docs\Bash (which is preferable). Bash complains when you launch it however, saying the installation is incomplete, because it expects the css files to be in Data\Docs.

I resolved it by moving the css files up to Data\Docs and leaving the rest of the bash docs in Data\Docs\Bash.

@ Wrye bash team - The Wrye bash.html needs an ammendment, in the "If bash wont start" section

Generating the Bugdump
? Open a command shell (Start: Programs: Accessories: Command Prompt).
? chdir to the Mopy directory. "chdir" means "change directory". E.g.: chdir C:\Program Files\Bethesda Softworks\Oblivion\Mopy
? Type: c:\python25\python.exe bash.py -d

I cant remember when the dos commands changed but the /D needs including for chdir, and parenthesis around a path with spaces needs including (which has always been a necessity in dos), otherwise files\bethesda in the included example becomes another parameter as far as dos is concerned.

and python25 .. does anyone use that version now?

Edit: At Quintus - Unless you have need for a certain Python setup for another application, just use the WryePython03a installer on tesnexus (I always run it as admin), sets it all up perfectly. I have found in the past un-installing (in control panel, add/remove programs) all parts of a previous setup of python can solve a multitude of problems, then a right click of the newly installed Wrye Bash Launcher and send to desktop automatically includes the correct target and start in directory for the latest Wrye bash.

Python 2.5x... I really don't know... I use 2.7x half the time now adays - bit faster IMO (as in I think so but haven't done any real timed tests so could be totally wrong) I would think that most users use 2.6x.
I'll update that, thanks.

Deleted everything WB related in %documents% and it runs again. Not sure how I messed up the original tho..

well given that it was in %documents%... well I guess somehow on close python or Bash (or disc write error I suppose is a unlikely but potential possibilities as well) itself had an error/made a mistake and saved one or more of the files in documents with some corruption which prevented proper initialization
Pacific Morrowind

[nath]

noto so many bugsies it looks like with 290 (feverishly knocks on all the wood he can find - and given that I live in a house with real hardwood floors thats a lot)
1. already _planned_ ... I'll try to get it actually done instead of just on the list.
2. huh that does sound like a good idea... adding to the list


just no one has got around to it - it works currently although is not the best so never been high on the list... pushing it up on my list and I'll make sure to get it done for 291... hmm probably put all the data/settings files into Mopy/foldername (so as not to leave it cluttered and to have a single folder rather than x dozen or so files in with x 2 dozen files are what you want to backup) ...erm what folder name would be good hmmm not sure.. any ideas? (thought about /data but that is already used... ah maybe /profile ... what do you all think?)

Pacific Morrowind

Cool!

For the Mopy folder name I'd think Bash Installers is fine - just in the Mopy folder ... Oh wait maybe you mean for the hidden issue.

But also retaining an entry in the ini that allows reassigning would be great.

[edit] Just hit me for another request.

Using the same method as hiding save games make it possible to have a path that you can define in the ini that allows you to back them up. I suppose the hidden function can be used for that, but I don't think I'm alone in wanting to back them up outside of the profiles folder on my C drive.

thanks again.

[bimsy]

it works amazingly fast ... More patchers are possible with it... the current state: works great except for one bug: it can't handle more than 255 esp/ms including imported and merged ones. Also still a couple patchers to finalize/double check.

Which patchers still need finalizing/checking?

For the moment I'm under the 255 ceiling so I guess it's about time to give that puppy a whirl and see where it goes.

Not sure if it's normal or not - but it spit out a huge amount of seemingly random data to the debug window when the patch build got to importing NPC faces.

[Vickytoria Vasquez]

Is my request for the new import tags in the queue somewhere? I posted details in the previous thread and there's also a feature request on sorceforge.

[patricia kris]

It works again. The WxPython download link located in the readme is outdated and doesn't work.. The one in this thread does and so my Wrye Bash works again:).

updating, thanks.

Bain Packages with custom folders.
According to the Bain documentation I could find, Wrye bash will skip files in non standard directories
Standard Directories being, meshes, textures, video, ect . . .

However files in some non-standard directories are installed
examples: _tejon, ini

Files in some non-standard directories are not installed
eamples: _ini, _bsa

I assume that "_tejon" and "ini" were added to the list of directories not skipped.
I this information documented anywhere?
Is it possible to set up bain to not skip other non-standard directories?

-dan

not very well documented... updated the documentation for skips in the readme, thanks.
(oh btw the full list of non-standards directories that are autorecognized is: ini, ini tweaks, pluggy, scripts, streamline', and '_tejon').

Another minor anomaly:
Select the Installers tab.
Look at the lower right corner.
I see Packages: 248/4( << the ( is actually part of a 6. The actual number of packages I have is 464.

The space needs to be resized in the Installers tab or maybe abbreviate "Packages" to "Pkgs:".

upped the size a bit, looks fine now even with 3 digit active and inactive numbers - at least on my screen, if still no good with the next version/the svn, just let me know and I'll see what I can do (probably just change to Pkgs: as you suggested)

Zoar5:

I understand your frustrations, but you should be a little bit more grateful for all the hard work that PM and the team put in to provide you with new features and improvements to Wrye Bash.

For future, unless you are willing to be a beta tester and understand the risks of using a bleeding edge software product, you should just stick with the versions that have been tried and tested.
v287 works fine.

This isn't like microsoft or something, where they have their own team of internal testers. We are the testers.

Cheers, I hope you get your game sorted out.

well it is always nice to show appreciation but the simple fact is that I should not have released 288 as it was... there was just too many bugs that I should have caught. 289 had one bug that was new that I could replicate and in my opinion I should have caught it given that all that had to be done was build the patch in non-CBash mode but 1 bug is to my mind at the limit of acceptabilty... so really I feel that I did poor quality control there and hence I do feel really sorry to everyone who has had less fun than they shoulda coulda and woulda had if I'd done a few more tests before release. I will try to make sure that it does not happen again, and thank-you everyone for your patience and of course reporting the bugs is always apreciated.
Pacific Morrowind

[CHangohh BOyy]

just no one has got around to it - it works currently although is not the best so never been high on the list... pushing it up on my list and I'll make sure to get it done for 291... hmm probably put all the data/settings files into Mopy/foldername (so as not to leave it cluttered and to have a single folder rather than x dozen or so files in with x 2 dozen files are what you want to backup) ...erm what folder name would be good hmmm not sure.. any ideas? (thought about /data but that is already used... ah maybe /profile ... what do you all think?)

I know you guys are busy doing a great job. Thanks muchly.
You should take your time with this one though. It's a pretty significant change.
If need be, I already hatched a plan for a workaround using mTES4. Though it would be great if I didn't need to do that

My suggestion to move everything to the Mopy folder was mostly based on grouping all the bash files instead of being so dispersed.
I'm not personally fixated on it all being in Mopy, in case I made that impression.

After reconsideration, it might make more sense if all the settings go in the users game profile. With all other user-related data.
If you put the settings in the Mopy folder, then if a user decides to uninstall, they have to consciously backup their settings if they might want them.
If the settings are in the profile the user has to consciously delete them. This is alot safer in case of ignorance. Better to have remnants than to have no recovery.

I mostly agree with Haama's sentiments on the feature request though.

How will backward compatability be handled?

When a new structure has been decided, I may take this on if you like.

This probably belongs on the SF feature request discussion, but I think we can get alot of input from users here who likely don't have an SF account....
I've gone ahead and drawn up a proposed restructure.

Here is the existing structure (that I know of):

Spoiler

........\Oblivion\
................\Builds\ <-- I've never seen this folder, what's it for?
........\Oblivion Mods\
................\Bash Installers\
........................\Bain Converters\
................................\--Duplicates\ <-- what's this for?
........................\Bash\
.................................\Converters.dat
.................................\Installers.dat
................\Bash Mod Data\
........................\Table.dat
........................\Backups\ <- backup plugins
........................\Hidden\ <- hidden plugins and installers
........................\INI Data\ <- INI tweak states?
.................................\Table.dat
........\My Games\
................\Oblivion\
........................\BashProfile.dat
........................\BashSettings.dat
........................\Saves\
................................\Bash\
........................................\Backup\
........................................\Hidden\

Here is the proposed structure:

Spoiler

........\Oblivion\
................\Builds\ <-- I've never seen this folder, what's it for?
........\Oblivion Mods\
................\BAIN Converters\
........................\--Duplicates\ <-- what's this for?
................\BAIN Installers\
................\BAIN Projects\
........\My Games\
................\Oblivion\
........................\Bash\
...............................\BashProfiles.dat
...............................\BashSettings.dat
...............................\Converters.dat
...............................\INI.dat
...............................\Installers.dat <-- include a field for hidden installers?
...............................\Plugins.dat
...............................\Bash Backup Plugins\ <- Not so keen on these being here, but it seems the most logical place outside of Oblivion\Data
...............................\Bash Hidden Plugins\ <- " "
........................\Saves\
................................\Bash Backup Saves\
................................\Bash Hidden Saves\

Notes:
Oblivion Mods\Bash Mod Data\Table.dat was renamed to My Games\Oblivion\Bash\Plugins.dat
Oblivion Mods\Bash Mod Data\INI Data\Table.dat was renamed to My Games\Oblivion\Bash\INI.dat

I'm not sure what to do about the hidden installers. My instinct is to change it to a table, instead of physically moving anything.

Bash Converters\ was renamed to BAIN Converters\ and moved beside BAIN Installers\ instead of within.
A new BAIN Projects\ folder was created, so they are segregated from the installers.
This should make it possible to have subdirectories within the BAIN Installers\ folder, allowing users to organize them better than just with the placeholders.

I'm not familiar with the other files that Bash generates, so I have not included them. Feel free to fill em in.
I expect they would all go to My Games\Oblivion\Bash\

Please fill in the gaps if I have missed anything.

[Samantha Jane Adams]

well it is always nice to show appreciation but the simple fact is that I should not have released 288 as it was... there was just too many bugs that I should have caught. 289 had one bug that was new that I could replicate and in my opinion I should have caught it given that all that had to be done was build the patch in non-CBash mode but 1 bug is to my mind at the limit of acceptabilty... so really I feel that I did poor quality control there and hence I do feel really sorry to everyone who has had less fun than they shoulda coulda and woulda had if I'd done a few more tests before release. I will try to make sure that it does not happen again, and thank-you everyone for your patience and of course reporting the bugs is always apreciated.
Pacific Morrowind

True enough
But as a programmer myself, I'm acutely aware of how difficult it can be to see the forest through the trees sometimes.

May I suggest offering a stable and an unstable version maybe though?
It would probably help alleviate alot of mayhem at release time.

[Andrew Lang]

Regarding Gaitcus' proposed structure...

Me likey - makes more sense for uninstall/reinstall/backup.

But with backing up save games I'd still vote for being able to change the path on that to outside of the profiles folder - for those of us who need room on our puny C drives. As default path though it sounds good.

So 290 is good? Guess it is time to upgrade.

But question about 7zip ... for creating archives I've been using 4.64 - and remember a post in the last thread that 7zip was updated to help with better disk defraging - is it recommended that I update that too? And if I did so will it be kosher with this update?

And does this mean the gigs of repackaged archives I have now are not so great for defragging?

[steve brewin]

Cool!

For the Mopy folder name I'd think Bash Installers is fine - just in the Mopy folder ... Oh wait maybe you mean for the hidden issue.

But also retaining an entry in the ini that allows reassigning would be great.

[edit] Just hit me for another request.

Using the same method as hiding save games make it possible to have a path that you can define in the ini that allows you to back them up. I suppose the hidden function can be used for that, but I don't think I'm alone in wanting to back them up outside of the profiles folder on my C drive.

thanks again.

can't have too many settable paths in the ini is what I say.
sure that sounds reasonable... hmm might have it ask where to copy them to instead of a default path... or at least both.

Which patchers still need finalizing/checking?

For the moment I'm under the 255 ceiling so I guess it's about time to give that puppy a whirl and see where it goes.

Not sure if it's normal or not - but it spit out a huge amount of seemingly random data to the debug window when the patch build got to importing NPC faces.

finalizing: ImportScriptContents (well really coding from the ground up to do what it was meant to do instead of the only things I could get it to do in non-CBash mode)
checking: well them all... they've had checks by both Warrudar and me (except for Import Acotrs: Spells which only I've looked at so far and not yet 100% of my LO possibilities)... so definitely could use lots of actual usage.

hmmm what kind of random data?
(if it is like this:
FileName = Pek_Painting_Exchanger.esp.ghost
Unimplemented GRUP =
Record skipped with duplicate formID: 00000000
Record skipped with duplicate formID: 00000000
Record skipped with duplicate formID: 00000000
Record skipped with duplicate formID: 00000000
Record skipped with duplicate formID: 00000000
Record skipped with duplicate formID: 00000000
its nothing to worry about right now,)

Is my request for the new import tags in the queue somewhere? I posted details in the previous thread and there's also a feature request on sorceforge.

yep I'm looking into it... probably be a week or so anyways.
Pacific Morrowind

[Cathrine Jack]

And does this mean the gigs of repackaged archives I have now are not so great for defragging?

I think that changelog message was in relation to something broken in a previous beta, not 4.6x (latest is 4.65, BTW). And it's only in relation to .zip archives anyway.

[Laura Simmonds]

Zoar5:

I understand your frustrations, but you should be a little bit more grateful for all the hard work that PM and the team put in to provide you with new features and improvements to Wrye Bash.
For future, unless you are willing to be a beta tester and understand the risks of using a bleeding edge software product, you should just stick with the versions that have been tried and tested.
v287 works fine.
This isn't like microsoft or something, where they have their own team of internal testers. We are the testers.
Cheers, I hope you get your game sorted out.

First: sorry for going to chew on your a... but I think your comment concern not only me.

Your critic is out of place. When I am frustrated with my game it does not mean I do not appreciate the skills and work not only here but with every modding and development others are doing, especially when they are better than I am. That should be perfectly clear by my posts. Because I do not know sh... about the "higher work" they are doing here, also I really try hard, it is not that I am "grateful" for their work, it is that I have the highest respect and admiration for it. And I doubt that I am alone with that.

You should consider if it is not a good thing that people like me who are obviously not so "gifted" tell the team about their problems and frustration instead of just shutting up, giving up and not using Wyre Bash.
Also what is for experts quite natural is for others a book with seven seals. Not everybody would be able to discuss the theory of relativity with Einstein and develop it further but lots of people like occupy themselves with it even using it in one way or another without fully understanding everything and having times when they are frustrated and making their frustration public.

So for the future unless you propose Wyre Bash should be used only by expert people who understand perfectly and everything about scripting, modding, programming and so on and want them only to give praise without expressing their feelings from time to time, you should be a little bit more careful with that kind of criticism. Especially the part that sounds like that they should be grateful maybe because they are to stupid themselves...
Besides the point that - how you put it - we are all testers, I am not aware that there are stable and beta versions?

And by the way...Microsoft with it′s army of internal testers often has more bugs in their programs than alternative programs whose developers have only themselves. I dislike Microsoft and use alternative programs whenever I can do it.

Thanks for the cheers. :wink_smile:

... well it is always nice to show appreciation but the simple fact is that I should not have released 288 as it was... there was just too many bugs that I should have caught. 289 had one bug that ...
... so really I feel that I did poor quality control there and hence I do feel really sorry to everyone who has had less fun ...
...and of course reporting the bugs is always apreciated.

Do not fret about it
1. Everyone makes mistakes
2. Nobody is perfect
3. Therefore there are "testers" (all the one using WB) and I think it is kind of a "cozy" thought for all - also for the "only the error reporters" - that they might give you one or the other humble hint for making developments.

I thought my problems over again. Could it be that using CBash (working with vc2005 runtime) at one point lead to my actual problem?
When you told me during my trying with 289 at one point, that
"...Probably will fail on patch rebuild (it almost certainly will fail if not using CBash but will be fine if using CBash (though that still is slightly WIP and has one bug right now that I know of)"

and you were right BP did not rebuilt, I wanted to know if you were also right with CBash.
With CBash and 289 there were no error - therefore no error reports -, everything worked fine, also after building Bashed Patch it turned out orange. Unfortunately my game did not start at all after that. And the rest you know.

Once again
You doing an amazing work :foodndrink:
Thanks.

[stevie trent]

I'll just say that I apologize. I didn't mean to insult you and I should have worded it better.
I had just read several of your last posts and they each gave me the impression that you were obviously upset and seemed like you were blaming PM.

[Andrew]

I'll just say that I apologize. I didn't mean to insult you and I should have worded it better.
I had just read several of your last posts and they each gave me the impression that you were obviously upset and seemed like you were blaming PM.

In that case I have to apologize to you myself for giving you that impression. Of course I am upset but not with PM but with myself and my PC :brokencomputer:

Also I did not feel insulted and usually I am for myself not so delicate. Therefore the "First:sorry...".
I only responded in the way I did, because I know other people who are already overwhelmed from what they are reading not only here, reluctant to post what problems and feelings they have because they think they are out of their league, fear the responses and might become even more reluctant to post at all. I think this would be a pity.

However let us agree that Wyre Bash is awsome :celebration:

[GLOW...]

Not sure if I've got something screwed up, But Bash doesn't open with the WryeBash Launcher anymore, but seems to work if I launch Bash.PY ok.

[Add Me]

Not sure if I've got something screwed up, But Bash doesn't open with the WryeBash Launcher anymore, but seems to work if I launch Bash.PY ok.

Try running the launcher from the cmd line.
C:\Pytho26\Python.exe "C:\Games\Oblivion\Mopy\Wrye Bash Launcher.pyw"

Does it say 'already started'?

[Lily Something]

Try running the launcher from the cmd line.
C:\Pytho26\Python.exe "C:\Games\Oblivion\Mopy\Wrye Bash Launcher.pyw"

Does it say 'already started'?

Getting this too, and yes, it does. Launching via Bash.py worked, and upon exiting again, the launcher worked as normal - it looks like the file that records if WB is open or not isn't getting updated on closing all the time, and WB's 'only run once' is then stopping you from launching it 'again'.

[BlackaneseB]

Getting this too, and yes, it does. Launching via Bash.py worked, and upon exiting again, the launcher worked as normal - it looks like the file that records if WB is open or not isn't getting updated on closing all the time, and WB's 'only run once' is then stopping you from launching it 'again'.

Gah. Almost certainly my fault. It seems i have solved one problem, only to cause another. Before starting Bash, does the file Mopy/pidfile.tmp exist?

Edit: hrm, you say that it works after launching with Bash.py? Running from there wouldn't affect the lock file, either creating it or deleting it. When the launcher fails, how long had it been since you previously closed bash?

[vicki kitterman]

I'd been using the same Icon for the last several updates, when I updated to 290 it didn't want to launch, even if I tried Previous versions. I went back to the 275 Installer, and it launched, but nothing latter would.
Reinstalled Python, from the 03a packege last night and 290 launched from the desktop icon (for Wrye Bash) but when I booted this morning, it wouldn't...
What is the differance from Wrye Bash Launcher.pyw and Bash.py??

*Ok pidfile.tmp was there, I renamed it, then Wrye Bash launces from the desktop...

**Seems to be working fine Now, it creates a New pidfile.tmp , then deletes it when I close Bash... :shrug:

[Jennifer May]

What is the differance from Wrye Bash Launcher.pyw and Bash.py??
...
**Seems to be working fine Now, it creates a New pidfile.tmp , then deletes it when I close Bash... :shrug:

The problem may be that some users start with a pidfile.tmp already in the Mopy directory, left over from a previous version.

btw, Wrye Bash Launcher.pyw parses the commandline, ensures only one process is running, etc. bash.py is the program proper.

Edit: attached patch to fix the "stale lockfile" problem to issue 3088781 (it mostly just reinstates some of PacificMorrowind's code that I removed because I mistakenly thought it wasn't needed with the new logic)

[Alisia Lisha]

Ok, no problem then, I think I Upgraded while Bash was Still open...
Looking Good :goodjob: