» Wed Mar 30, 2011 1:41 pm Random Failure trying to uninstall TestArchive... SVN1056
OPtions in context menu changed and there is no option to uninstall
Traceback (most recent call last):
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\balt.py", line 1560, in DoColumnMenu
item.AppendToMenu(menu,self,iColumn)
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 6690, in AppendToMenu
menuItem.Check(settings[self.key])
File "C:\Python26\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", line 11557, in Check
return _core_.MenuItem_Check(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed at ..\..\src\msw\menuitem.cpp(333) in wxMenuItem::Check(): CheckMenuItem() failed, item not in the menu?
EditINI related
EDIT: Shouldn't bBorderRegionEnabled=1
...be Enabled..True???
Or is this backward??? Did Beth muck it up or Bash???
EDIT: Nevermind. A Restart fixed that..
REREEDIT: It did it again.. After Applying a EditINI to Oblivion ini go to the ini tab and see that border regions is 0 but oblivion.ini still says 1
Edit yet again: Here is a pic http://imageshack.us/photo/my-images/268/editini.jpg/
OPtions in context menu changed and there is no option to uninstall
Traceback (most recent call last):
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\balt.py", line 1560, in DoColumnMenu
item.AppendToMenu(menu,self,iColumn)
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 6690, in AppendToMenu
menuItem.Check(settings[self.key])
File "C:\Python26\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", line 11557, in Check
return _core_.MenuItem_Check(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed at ..\..\src\msw\menuitem.cpp(333) in wxMenuItem::Check(): CheckMenuItem() failed, item not in the menu?
EditINI related
EDIT: Shouldn't bBorderRegionEnabled=1
...be Enabled..True???
Or is this backward??? Did Beth muck it up or Bash???
REREEDIT: It did it again.. After Applying a EditINI to Oblivion ini go to the ini tab and see that border regions is 0 but oblivion.ini still says 1
Edit yet again: Here is a pic http://imageshack.us/photo/my-images/268/editini.jpg/
ugh pyAssertionError... try restarting Bash and doing the same thing; sometimes thats a random error... if it happens again let me know and I'll look deeper into it.
I think you want it to be zero - uh make sure you don't have multiple lines that say have the border region (sometimes happens Idkw).
And often B is met with some resistance to it actually being a problem and not end user misuse. That gets tiring. It seems no matter how much time one can put in here or how much beta testing one does - if the opportunity exists to discount and noobify it is usually taken.
I hope you've never felt that from the Bash team, if you have have please pm me for a civil discource about it.
Of course fixing bugs sometimes takes a while but I try to not discount bugs at report - especially from those who have reported bugs before then I have a better assurance that it isn't user error - but if I have done that I do appoligize.
Speaking of which did anyone see Yacoby's suggestion a page or two back? I think it would be a great idea to have a core set of Wrye files that get updated perhaps separately than the files that are game dependent (mash, flash, flashNV, bash), but then again I'm not a developer. My ulterior motive for that would then be to advocate for the changes that Gaticus proposed about having more localized BAIN info storage.
yeah I think it sounds great.
Yes, I centralized resource WOULD be great, but what if no one would maintain it.
Ex. I'm playing morrowind right now, the oblivion or skyrim part doesn't matter....
Are you willing to double the manpower for an good Idea that no one may hold their bets upon?
So, far, there are only those who help dev and so so...
Until they clone themselves, well...............I think you know the answer.
Ex. I'm playing morrowind right now, the oblivion or skyrim part doesn't matter....
Are you willing to double the manpower for an good Idea that no one may hold their bets upon?
So, far, there are only those who help dev and so so...
Until they clone themselves, well...............I think you know the answer.
well it would be part of Bash, Mash, Flash, FlashNV so as devs did changes to those they would do required changes to the shared code, so I think that wouldn't be much problem. and it should decrease manpower after an initial outlay of course.
Reading OMODs is more important because there are numerous existing files already in the wild that used those. Nehrim may be popular but it's a tiny minority of users who use Bash with it. Prioritization is a necessity in any project.
And I was serious, if you don't' think you'll have time to help with followup on your bug reports, you shouldn't be reporting them. That's not meant to be an attack, it's just simple fact. The developers can't go asking other random souls to help with it if you're the one experiencing the problem.
And I was serious, if you don't' think you'll have time to help with followup on your bug reports, you shouldn't be reporting them. That's not meant to be an attack, it's just simple fact. The developers can't go asking other random souls to help with it if you're the one experiencing the problem.
prioritization is based on two things: perceived importance by devs, and what the heck the devs feel like doing
if it's a good bug report (and a repeatable bug) even if you don't have to to test it often can be fixed without followup but vague ones really do need followup.
Basically, what I want to know is if I re factored everything common between projects out to a new projected, is likely that my patches would get accepted? I am willing to basically all the work but I don't want that work to be for nothing.
Whatever happens, I wouldn't do anything until end of may/june. I have exams atm
The idea is that if you had something really general, you would commit the changes to the centralized project rather than the game specific project.
Whatever happens, I wouldn't do anything until end of may/june. I have exams atm
The idea is that if you had something really general, you would commit the changes to the centralized project rather than the game specific project.
definitely
yeah I just drove into town yesterday for an examy thing.
precisemant
If this installers.dat file were divorced from the BAIN directory and stored in the save game directory (ideal) or in the Mopy directory even (or even settable to anywhere via an ini setting) then one could have one BAIN archive and depending upon what each clone reads from the installers.dat file it would then read and access the BAIN archive (Oblivion Mods/Bash Installers) differently with each clone (installers.dat file).
Where hidden archives (Bash mod data) goes would likely need to be addressed by also making those locations related to the three areas above. mTES4Manager works with Oblivion, F3, and FNV already. Not morrowind but there are similar programs for it - and my bet is that they too would benefit from this.
Trying to have Wrye Bash as an independent program that does not switch or remains separate from the clones switching yet tracks them is, I think, a bad idea - and again maybe I misunderstand. It really seems to be about just changing the locations of where certain files are read and stored. So the suggestion is not to have bash track clone switching - the suggestion is just to divorce the installers.dat file and the hidden folders from the BAIN archive. Let mTES4Manager handle the rest.
An update to the system would require users of the older scheme to back up certain folders - which could be easy as just installing the new would not remove the old. But yeah I'd expect a thread of complaints.
It seems simple to me anyway. Gaticus' proposals were posted back in Oct-Nov 2010 in bash threads.I'd think mod makers would love this idea - then they could have a modding clone with their data folder just so and bare except for what they are working on - and then another folder to play with or test their mods in the mix).
Where hidden archives (Bash mod data) goes would likely need to be addressed by also making those locations related to the three areas above. mTES4Manager works with Oblivion, F3, and FNV already. Not morrowind but there are similar programs for it - and my bet is that they too would benefit from this.
Trying to have Wrye Bash as an independent program that does not switch or remains separate from the clones switching yet tracks them is, I think, a bad idea - and again maybe I misunderstand. It really seems to be about just changing the locations of where certain files are read and stored. So the suggestion is not to have bash track clone switching - the suggestion is just to divorce the installers.dat file and the hidden folders from the BAIN archive. Let mTES4Manager handle the rest.
An update to the system would require users of the older scheme to back up certain folders - which could be easy as just installing the new would not remove the old. But yeah I'd expect a thread of complaints.
It seems simple to me anyway. Gaticus' proposals were posted back in Oct-Nov 2010 in bash threads.I'd think mod makers would love this idea - then they could have a modding clone with their data folder just so and bare except for what they are working on - and then another folder to play with or test their mods in the mix).
it's on the list just a larger change and no one's gotten around to it.
Pacific Morrowind
