206 replies to this topic

[showler]

Prompt please when the bug with Import AI Package will be corrected? And on how many this bug is critical?

At least another week or so, as PacificMorrowind is in the middle of exams. How critical depends on your mods, probably, but it doesn't seem to be causing many problems to the majority of players, if any at all.

[Arthmoor]

Prompt please when the bug with Import AI Package will be corrected? And on how many this bug is critical?

It's a minor inconvenience, at least so far. The NPCs that end up with AI packs in the wrong order are very few and probably not important enough to worry about. At least for my game anyway.

[PacificMorrowind]

I asked Wrye several times to add new function: 'Automatic Equip Corpses' based on a obscure mod with similar name.
Reason: When you finish looting a corpse (Gods, sometimes we sound macabre !) and put back clothes and armor you don't want in its inventory, corpse stays naked.
Kinda creepy. Thia mod (@Nexus) makes so that corpses are automatically equipped with the highest class armor/clothes/weapon in their inventory.
No more nekid dead wimin on your trail

Could I repeat this request as I see someone tinkers with the monkey's nuts already?

And of course: million thanks. Can you imagine our games with Wrye uninstalled? Brrrr...

hmm lets see I'm almost certain I said I'd look into this months back as well.
well just looked in to it... (I'm getting quicker I thnk since it took me around 2 minutes to analyse the esp)... it could easily be added to the patch function; however it would essentially be a copy of that esp merged in as if you used Tes4Edit or Tes4Gecko... so I'd have to check the readme on usage... but if that's fine I can certainly add it for probably 285 but [i]might make it into the full (ie non RC) 284.

Now, another thing:

wrye bash has given me errors a couple times. I'm on Win7 x64 - is this ok?

Fine.

E:\Games\Oblivion\Mopy\basher.py:1531: UnicodeWarning: Unicode unequal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  def OnTextEdit(self,event):

almost certainly that would be that you have the Unicode version of wxPython rather than the ANSI version.

Does anyone have a clue why I'm having this?

MERGE/SCAN ERROR: Oscuro's_Oblivion_Overhaul.esm
Traceback (most recent call last):
  File "E:\Games\Oblivion\Mopy\basher.py", line 4693, in Execute
    raise
  File "E:\Games\Oblivion\Mopy\basher.py", line 4654, in Execute
    patchFile.scanLoadMods(SubProgress(progress,0.2,0.8)) #try to speed this up!
  File "E:\Games\Oblivion\Mopy\bosh.py", line 13767, in scanLoadMods
    raise
  File "E:\Games\Oblivion\Mopy\bosh.py", line 13763, in scanLoadMods
    patcher.scanModFile(modFile,nullProgress)
  File "E:\Games\Oblivion\Mopy\bosh.py", line 19928, in scanModFile
    patchBlock.setRecord(record.getTypeCopy(mapper))
  File "E:\Games\Oblivion\Mopy\bosh.py", line 1600, in getTypeCopy
    myCopy = copy.deepcopy(self)
  File "C:\Python26\lib\copy.py", line 189, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "C:\Python26\lib\copy.py", line 338, in _reconstruct
    state = deepcopy(state, memo)
  File "C:\Python26\lib\copy.py", line 162, in deepcopy
    y = copier(x, memo)
  File "C:\Python26\lib\copy.py", line 235, in _deepcopy_tuple
    y.append(deepcopy(a, memo))
  File "C:\Python26\lib\copy.py", line 162, in deepcopy
    y = copier(x, memo)
  File "C:\Python26\lib\copy.py", line 255, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "C:\Python26\lib\copy.py", line 162, in deepcopy
    y = copier(x, memo)
  File "C:\Python26\lib\copy.py", line 228, in _deepcopy_list
    y.append(deepcopy(a, memo))
  File "C:\Python26\lib\copy.py", line 189, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "C:\Python26\lib\copy.py", line 347, in _reconstruct
    y.__dict__.update(state)
MemoryError

There are also other errors that appear. I'll try to collect them too.

#2

Traceback (most recent call last):
  File "E:\Games\Oblivion\Mopy\basher.py", line 3894, in OnCloseWindow
    self.notebook.GetPage(index).OnCloseWindow()
  File "E:\Games\Oblivion\Mopy\basher.py", line 485, in OnCloseWindow
    self.data.save()
  File "E:\Games\Oblivion\Mopy\bosh.py", line 10692, in save
    self.dictFile.save()
  File "E:\Games\Oblivion\Mopy\bosh.py", line 264, in save
    saved = bolt.PickleDict.save(self)
  File "E:\Games\Oblivion\Mopy\bolt.py", line 826, in save
    cPickle.dump(data,out,-1)
MemoryError

yes as Corepc said those look to be just that Python ran out of Memory - Win 7 might make that worse but I don't know - ... usually can avoid that if you restart Bash after acessing installers (massive amount of memory there) before building the patch (large amount of memory there too). (I can tell that the first one you got after attempting to build the patch and the second on attempting to close bash I believe)

WB v284 now suggests that I deactivate LoadingScreens.esp because it has the Graphics and NoMerge tags. The problem is that if you deactivate the mod, a number of unique Loading Screen records will be omitted from the bashed patch. Does this mean that the NoMerge tag has new significance in v284 or that WB is not handling this in the correct way?

Any comments and guidance will be very much appreciated.

For now, I am leaving it activated to ensure that I get all the Loading Screens.

If it isn't mergeable it doesn't need a NoMerge tag (and it would have zero effect)... if you don't want the new screens you can just import the changes, but otherwise definitely should be active.

I noticed after a couple days of screwing around and experimenting with what mods I want, my pythonw.exe memory usage was at 1.4gb. Is this anywhere near normal? Is this an unfortunate nature of bash, or was there a memory leak?

mainly due to some of the high memory use functions I would guess (BAIN probably)... just restart bash and any excess will be cleared (though 1.4gb is abnormally high - I don't think I've ever got it higher than hmm 900mb... even with bashing many patches, installing with BAIN without restarting Bash in between any of them.)

NoMerge should not equate to "deactivate". It means don't merge into the bashed patch. There's a specific tag for "deactivate".

No NoMerge is basically deactive but it is mergeable so it has to be told not to be merged for some reason (ie face mods are a good example).

I seem to have messed up my bash patch with improper merging, could use a bit of help, can I post the info here, and what info is needed?

fine to post here - what's wrong, what options you chose should be all that's required to troubleshoot it.
(ah that's nice to think of something not psychology, economics or sciences for a few minutes... exams are fun but a tad tiring)
Pacific Morrowind

[UndWDoG]

At least another week or so, as PacificMorrowind is in the middle of exams. How critical depends on your mods, probably, but it doesn't seem to be causing many problems to the majority of players, if any at all.

It's a minor inconvenience, at least so far. The NPCs that end up with AI packs in the wrong order are very few and probably not important enough to worry about. At least for my game anyway.

Thanks!

[Surazal]

If it isn't mergeable it doesn't need a NoMerge tag (and it would have zero effect)... if you don't want the new screens you can just import the changes, but otherwise definitely should be active.

I agree. The fact that WB prompts to deactivate will result in a key benefit of the mod being lost. Should WB be importing the new screen records as well or only the ones that override the oblivion.esm ones? Assuming the latter, should WB be prompting to deactivate a mod that is not mergeable (even if it has the nomerge tag)?

Thanks

Edit: Just took off the NoMerge tag and it works properly - so BOSS tag recommendation should be changed to only include the Graphics tag.

Edited by Surazal, 18 May 2010 - 02:46 PM.

[Torrello]

I've been using those loading screen mods by trollf for years, and now I find I've been using them wrong and they need to be active!!!

[FrodoTheDarkLord]

Short update: so far, there's not been a lot to fix- just a couple of paths messed up, plus the fact that Linux is case-sensitive as opposed to Windows means that some image file names need to be slightly adjusted. Or so I thought- until I got stuck with a segfault. Ugh... I checked the crashing python page on the python website, but nothing seems to be applicable... what a shame. Unless google helps me out here, I'm pretty lost.

[camperdave]

Hey guys -

I've been considering making a patch for Bash to handle some filetypes that it currently skips. Currently, bash avoids all executable filetypes, like dlls etc. While that's a great policy in terms of security, it can make using the installers tab a little more annoying than it should be, when doing re-installs of obse plugins, and the mods that require them.

To get the best of both worlds, I'm adding another option to the context menu like "Has Extra Directories" named "Trusted for Executables". Only installers with that option set would be able to copy executable files such as the OBSE plugin dlls.

Since this is sort of serving as a reason to learn python (one of the languages I have very little experience in), I wouldn't look for a patch too soon, assuming I even manage to figure it out.

My question is more of, is this worth doing at all? I mean, if there's no chance of it ever getting integrated into the main release, I'm probably not going to bother, since I definitely don't want to maintain an entire fork, lol.

-- camperdave

[shadeMe]

I wouldn't count on it. QUST records stand a higher chance than SCPT records of a XXXX sub-record due to the CTDA sub-records, and both QUST and SCPT records have the SCTX sub-record which holds the plain text scripting. Since OBSE removed the 32k limit on plain text, it is quite possible to hit the overall 65k limit that triggers the XXXX sub-record. Especially if the script happens to have a lot of commenting.

I didn't realize that the plain text limit was removed. Thanks for bringing that up.

It isn't too hard to account for the XXXX sub-record, especially if you're only reading and not writing out the record. CBash does it like:

Spoiler

unsigned int subType = 0;
    unsigned int subSize = 0;
    unsigned int curPos = 0;
    SCPTVARS *newVARS = NULL;
    ReqRecordField<GENSCR_> *newSCR_ = NULL;
    while(curPos < recSize){
        _readBuffer(&subType,buffer,4,curPos);
        switch(subType)
            {
            case eXXXX:
                curPos += 2;
                _readBuffer(&subSize,buffer,4,curPos);
                _readBuffer(&subType,buffer,4,curPos);
                curPos += 2;
                break;
            default:
                subSize = 0;
                _readBuffer(&subSize,buffer,2,curPos);
                break;
            }
        switch(subType)
            {
            case eEDID:
                EDID.Read(buffer, subSize, curPos);
                break;
            case eSCHR:
                SCHR.Read(buffer, subSize, curPos);
                break;
            case eSCDA:
                SCDA.Read(buffer, subSize, curPos);
                break;
            case eSCTX:
                SCTX.Read(buffer, subSize, curPos);
                break;
            case eSLSD:
                newVARS = new SCPTVARS;
                newVARS->SLSD.Read(buffer, subSize, curPos);
                VARS.push_back(newVARS);
                break;
            case eSCVR:
                if(newVARS == NULL)
                    {
                    newVARS = new SCPTVARS;
                    VARS.push_back(newVARS);
                    }
                newVARS->SCVR.Read(buffer, subSize, curPos);
                break;
            case eSCRV:
                newSCR_ = new ReqRecordField<GENSCR_>;
                newSCR_->Read(buffer, subSize, curPos);
                newSCR_->value.isSCRO = false;
                SCR_.push_back(newSCR_);
                break;
            case eSCRO:
                newSCR_ = new ReqRecordField<GENSCR_>;
                newSCR_->Read(buffer, subSize, curPos);
                newSCR_->value.isSCRO = true;
                SCR_.push_back(newSCR_);
                break;
            default:
                //printf("FileName = %s\n", FileName);
                printf("  SCPT: Unknown subType = %04x\n", subType);
                printf("  Size = %i\n", subSize);
                printf("  CurPos = %04x\n\n", recStart + curPos - 6);
                curPos = recSize;
                break;
            }
        };

Depending on what you're doing (assuming it's for your CS project), it may be simpler to take CBash and strip it down to what you need than to code something new.

Oh good! I'll take a look. But it seems that I won't need to read from the loaded plugin(s) after all - I came across a couple of functions in the executable's code that query the datahandler directly. I should be set if I can find the bloody thing altogether.

[PacificMorrowind]

I'm having landscape seam issues with Bravil Barrowfields. I want to move its load order around in Bash, but... the save option is grayed out, and I cannot paste in new mod dates to alter the load order. Is there any reason why I'm not allowed to?

the save option is only enabled when you have made changes to one of the fields above - you should be able to adjust the date freely (though if you don't enter the date in the right format Bash will complain on save and won't save the change(s))

Would it be possible to have BAIN indicate the install state in the Package List output generated by right-clicking?
038 - Landmarks, w Wells 1.10.zip (3C386A7E) <--- '-' Not installed
038 + Landmarks, w Wells 1.10.zip (3C386A7E) <--- '+' Installed

sounds good... hmm however possibly not noticeable enough; how about -- 038 <snip> = not installed and ++ 038 <snip> = Installed? - changed to be like that, feel free to suggest changing it (changing it again is just a matter of changing two text strings - very very very easy... oh easiest method of showing how I have it is to paste a copy of one of my testing Bash package lists - ie this isn't what I play with but I have 3 different installs of Bash designed to test different features):

Spoiler

Bain Packages:
-- 000 - USIP_Complete.7z (79CE866D)
-- 001 - UL_-_The_Heath_v11-11165-111.7z (09CE3DBC)
-- 002 - eveforartifacts.7z (28767760)
-- 003 - Pearl Palace (B633EEE1)
-- 004 - CBMS_Music_Pack-23377.rar (00000000)
005 - ==Last==
-- 006 - UL - Cheydinhal Falls 1.0.7z (B6E915AD)
-- 007 - UL_-_Ancient_Yews_and_Arrius_Creek_Patch_v11-16818.7z (E433DF5B)
-- 008 - UL_-_Ancient_Yews_v14-11458.7z (1CB282C4)
-- 009 - UL_-_Arrius_Creek_v111-16818.7z (E3E2D0B5)
-- 010 - UL_-_Blackwood_Forest_v1-25799.7z (3ECFCD50)
-- 011 - UL_-_Bravil_Barrowfields_v11-20426.7z (F2D19450)
-- 012 - UL_-_Brena_River_Ravine_v10-23573.7z (0CFC3F57)
++ 013 - UL_-_Cloudtop_Mountains_v10-16677.7z (F1939CFB)
-- 014 - UL_-_Colovian_Highlands_v111-15511.7z (3EC12128)
-- 015 - UL_-_Entius_Gorge_and_Arrius_Creek_LOD_Mesh-16818.7z (1F4B5069)
-- 016 - UL_-_Fallenleaf_Everglade_v12-17562.7z (A7F79A43)
-- 017 - UL_-_Imperial_Isle_v14-9531.7z (EA43854A)
-- 018 - UL_-_Lost_Coast_v161-14720.7z (AF4DC1A9)
-- 019 - UL_-_River_Ethe_10-17330.7z (D8BCFF63)
-- 020 - UL_-_Rolling_Hills_v131-10768.7z (749A3438)
-- 021 - UL_-_The_Dark_Forest_v103-11162.7z (D057B84C)
-- 022 - UL_-_The_Great_Forest_-_Ancient_Redwoods_v151-11163.7z (212143EE)
-- 023 - UL_-_The_Great_Forest_-_Lush_Woodland_v12-11164.7z (109E9FE9)
-- 024 - Unique_Landscapes _Entius_Gorge-7037.7z (08174034)
-- 025 - Unique_Landscapes_Fallenleaf_Everglade_11-9501.rar (16AB55F4)
-- 026 - xulPantherRiver_v11-20332.zip (E64756A8)

(only one active this second being UL Cloudtop.

Yeah, it seems the inventory importer is being flaky. TIE loading before KOTN, and even though KOTN makes no changes to inventory, the additions TIE is trying to put in are being ignored entirely. Further down into the creature stuff I noticed other mods seem to be getting along just fine. KOTN is not tagged with anything so this shouldn't be happening.

If there is a flaky spot of code TIE will find it (at least that's the conclusion I've come to)... I will look into it after my exams.

Eve_Knightsofthenine.Esp is in Purple text, tagged NoMerge, Graphics but the Patcher wants it Deactivated, as well as the Mod Checker, so what is the difference between NoMerge (Purple) and NoMerge, Deactivate (Purple Italics)??
I know Arthmoor already asked about this, but I never seen. and can't find the answer...

NoMerge and Deactivate shouldn't be tagged at the same time - they were in some instances due to a slightly faulty regex replacement I did... both mean the mod should be deactivated during build of patch and after (just different circumstances leading up to it).

Maybe the "NoMerge, Graphics, Deactivate" is redundant and just a leftover from how PacificMorrowind implemented the "Deactivate" tag when it went live?

bingo

Small bump.

er that is odd... could you post your save file (and obse/pluggy cosaves) - or email them (pacificmorrowind<at>gmail<dot><com>)

Hi,

I am using Wrye Bash 284 RC1. I notice that the option 'Has Extra Directories' when checked doesn't allow OBSE plugins to be installed. The help file supplied with Wrye Bash 284 RC1 implies that 'Has Special Directories' option should allow OBSE scripts to install. Will OBSE plugins be supported in a later version?
Some have mentioned that OBSE plugins can be installed using a hack. What is the hack? Is it advisable to use the hack?

Many thanks for an excellent program.
Regards,
niche99

OBSE plugins are very very unlikely to be supported at any time.
the 'Hack' is just changing the source of bosh.py to remove OBSE from the line that is

dataDirsMinus = set(('bash','obse','replacers')) #--Will be skipped even if hasExtraData == True.

(somewhere around line 9524 depending on version)... adviseable well it is slightly less safe - but if you are know what you are doing it is fine... really up to you. (but totally unsupported and use at your own risk etc.)

I agree. The fact that WB prompts to deactivate will result in a key benefit of the mod being lost. Should WB be importing the new screen records as well or only the ones that override the oblivion.esm ones? Assuming the latter, should WB be prompting to deactivate a mod that is not mergeable (even if it has the nomerge tag)?

Thanks

Edit: Just took off the NoMerge tag and it works properly - so BOSS tag recommendation should be changed to only include the Graphics tag.

WB can't import the new records (well it could be coded to but it isn't at this time at anyrate)... fixing the taging in the masterlist, taglist, thanks. Oh hmm yes I think that WB should assume that a NoMerge tag on a non-mergeable mod is a mistake and ignore it completely.
Pacific Morrowid

[PacificMorrowind]

Short update: so far, there's not been a lot to fix- just a couple of paths messed up, plus the fact that Linux is case-sensitive as opposed to Windows means that some image file names need to be slightly adjusted. Or so I thought- until I got stuck with a segfault. Ugh... I checked the crashing python page on the python website, but nothing seems to be applicable... what a shame. Unless google helps me out here, I'm pretty lost.

hmmm don't really know anything about segfaults but you could try pming/emailing (<pacificmorrowind><@><google><.><com>) me with your changed code, and what error messages you are getting running it along with what version of Python/addons and OS...

Hey guys -

I've been considering making a patch for Bash to handle some filetypes that it currently skips. Currently, bash avoids all executable filetypes, like dlls etc. While that's a great policy in terms of security, it can make using the installers tab a little more annoying than it should be, when doing re-installs of obse plugins, and the mods that require them.

To get the best of both worlds, I'm adding another option to the context menu like "Has Extra Directories" named "Trusted for Executables". Only installers with that option set would be able to copy executable files such as the OBSE plugin dlls.

Since this is sort of serving as a reason to learn python (one of the languages I have very little experience in), I wouldn't look for a patch too soon, assuming I even manage to figure it out.

My question is more of, is this worth doing at all? I mean, if there's no chance of it ever getting integrated into the main release, I'm probably not going to bother, since I definitely don't want to maintain an entire fork, lol.

-- camperdave

well that would almost certainly not go in - since it would be going exactly against Wrye's visioning - however I'm going to be PMing Wrye about some other stuff and can mention this as well.
What would certainly go in would be a popup warning on trying to install such files that says the didn't get installed and that the user should install them manually if desired.

I didn't realize that the plain text limit was removed. Thanks for bringing that up.

oh me neither... lets see how fast I can make a script use an XXXX record MUAHAHA - naw I won't do that... just jk
Pacific Morrowind

[ikariGendo]

Hi all

Im new to using Wrye Bash

I was wondering do I need to created the Bashed Patch?

Here are my mods

Spoiler

[codebox]Active Mod Files:
00 Oblivion.esm
01 Unofficial Oblivion Patch.esp [Version 3.2.6]
02 UOP Vampire Aging & Face Fix.esp [Version 1.0.0]
03 Oblivion Citadel Door Fix.esp
04 DLCShiveringIsles.esp
05 Unofficial Shivering Isles Patch.esp [Version 1.4.0]
06 Book Jackets Oblivion.esp
07 ImprovedSigns.esp
08 VA_BetterGold.esp
09 Map Marker Overhaul.esp [Version 3.4]
0A Map Marker Overhaul - SI additions.esp [Version 3.0.2]
0B DLCHorseArmor.esp
0C DLCHorseArmor - Unofficial Patch.esp [Version 1.0.5]
0D DLCOrrery.esp
0E DLCOrrery - Unofficial Patch.esp [Version 1.0.3]
0F DLCVileLair.esp
10 DLCVileLair - Unofficial Patch.esp [Version 1.0.5]
11 DLCMehrunesRazor.esp
12 DLCMehrunesRazor - Unofficial Patch.esp [Version 1.0.4]
13 DLCSpellTomes.esp
14 DLCSpellTomes - Unofficial Patch.esp [Version 1.0.1]
15 Book Jackets DLC.esp
16 GrimbotsSpellTomes.esp
17 MaleBodyReplacerV4.esp
18 EVE_StockEquipmentReplacer.esp
19 DLCThievesDen.esp
1A DLCThievesDen - Unofficial Patch.esp [Version 1.0.5]
1B DLCThievesDen - Unofficial Patch - SSSB.esp [Version 1.0.4]
1C DLCBattlehornCastle.esp
1D DLCBattlehornCastle - Unofficial Patch.esp [Version 1.0.4]
1E DLCFrostcrag.esp
1F DLCFrostcrag - Unofficial Patch.esp [Version 1.0.4]
20 Knights.esp
21 Knights - Unofficial Patch.esp [Version 1.0.9]
22 EVE_KnightsoftheNine.esp
23 P1DkeyChain.esp [Version 5.00]
24 Quest Award Leveller.esp
25 Quest Award Leveller - Battlehorn Castle.esp
26 Quest Award Leveller - Vile Lair.esp
27 Quest Award Leveller - Mehrunes Razor.esp
28 Quest Award Leveller - Knights of the Nine.esp
29 No psychic guards harder fix.esp
2A Oblivion XP.esp [Version 4.1.5]
2B EVE_KhajiitFix.esp
2C QTdof.esp
2D Real Lava 1.3.esp
2E MiniMap.esp
2F Oblivion Graphics Extender Support.esp [Version 0.2]

Load order was sorted with BOSS, I'm using OBMM to manage the mods

Specifically I'm wondering about merging leveled lists. Is it necessary with the mods I have?

Secondly, 2 mods are highlighted in red, with the bashed tags of 'graphics, deactivate'
Those are Real Lava 1.3 and GrimbotsSpellTomes.

Is having them active somehow causing problems?

Cheers

[PacificMorrowind]

With that Load Order it is not necessary - you may loose a few changes (i'd specifically be worried about loosing some EVE armor/clothing changes but I don't THINK any will be lost).
Deactivate don't worry about unless you are using the bashed patch.

[myk002]

Short update: so far, there's not been a lot to fix- just a couple of paths messed up, plus the fact that Linux is case-sensitive as opposed to Windows means that some image file names need to be slightly adjusted. Or so I thought- until I got stuck with a segfault. Ugh... I checked the crashing python page on the python website, but nothing seems to be applicable.

It may be a resource limit, depending on what limits are set for the current user. What were you doing when it crashed? I'm running Oblivion on Linux as well, so I can help test things out if you like. I'll PM you my email.

Edited by myk002, 19 May 2010 - 12:30 PM.

[FrodoTheDarkLord]

It may be a resource limit, depending on what limits are set for the current user. What were you doing when it crashed? I'm running Oblivion on Linux as well, so I can help test things out if you like. I'll PM you my email.

That seems unlikely; I tried it again with all other windows closed- nothing. Memory use is idling at around 750 MB out of 4 GB, and processor load is nonexistent. As far as source code is concerned, I changed only these lines:

basher.py

in class App_Tes4Gecko, line 10588:

self.java = GPath(os.environ['SYSTEMROOT']).join('system32','javaw.exe')

to

self.java = GPath('/usr/bin/java')

and in class App_OblivionBookCreator, line 10616

self.java = GPath(os.environ['SYSTEMROOT']).join('system32','javaw.exe')

to

self.java = GPath('/usr/bin/java')

These were necessary to change as I got a KeyError when trying to access 'SYSTEMROOT'. I figured just setting the path manually works for now, so I inserted the path to my java binary (as I guess that's what basher is looking for) instead.

The only other things I modified were the icon names, so they match the source code (as Linux is case sensitive as opposed to Windows). These icons need to be fixed for WB to even begin to initialize (given are the names after they have been fixed):

Insanity'sReadmeGenerator.png
• Boss16.png
• AutoCad16.png
• Blender16.png
• DDSConverter16.png
• bashmon16.png

[Tomlong75210]

Hi all

Im new to using Wrye Bash

I was wondering do I need to created the Bashed Patch?

Here are my mods

Spoiler

[codebox]Active Mod Files:
00 Oblivion.esm
01 Unofficial Oblivion Patch.esp [Version 3.2.6]
02 UOP Vampire Aging & Face Fix.esp [Version 1.0.0]
03 Oblivion Citadel Door Fix.esp
04 DLCShiveringIsles.esp
05 Unofficial Shivering Isles Patch.esp [Version 1.4.0]
06 Book Jackets Oblivion.esp
07 ImprovedSigns.esp
08 VA_BetterGold.esp
09 Map Marker Overhaul.esp [Version 3.4]
0A Map Marker Overhaul - SI additions.esp [Version 3.0.2]
0B DLCHorseArmor.esp
0C DLCHorseArmor - Unofficial Patch.esp [Version 1.0.5]
0D DLCOrrery.esp
0E DLCOrrery - Unofficial Patch.esp [Version 1.0.3]
0F DLCVileLair.esp
10 DLCVileLair - Unofficial Patch.esp [Version 1.0.5]
11 DLCMehrunesRazor.esp
12 DLCMehrunesRazor - Unofficial Patch.esp [Version 1.0.4]
13 DLCSpellTomes.esp
14 DLCSpellTomes - Unofficial Patch.esp [Version 1.0.1]
15 Book Jackets DLC.esp
16 GrimbotsSpellTomes.esp
17 MaleBodyReplacerV4.esp
18 EVE_StockEquipmentReplacer.esp
19 DLCThievesDen.esp
1A DLCThievesDen - Unofficial Patch.esp [Version 1.0.5]
1B DLCThievesDen - Unofficial Patch - SSSB.esp [Version 1.0.4]
1C DLCBattlehornCastle.esp
1D DLCBattlehornCastle - Unofficial Patch.esp [Version 1.0.4]
1E DLCFrostcrag.esp
1F DLCFrostcrag - Unofficial Patch.esp [Version 1.0.4]
20 Knights.esp
21 Knights - Unofficial Patch.esp [Version 1.0.9]
22 EVE_KnightsoftheNine.esp
23 P1DkeyChain.esp [Version 5.00]
24 Quest Award Leveller.esp
25 Quest Award Leveller - Battlehorn Castle.esp
26 Quest Award Leveller - Vile Lair.esp
27 Quest Award Leveller - Mehrunes Razor.esp
28 Quest Award Leveller - Knights of the Nine.esp
29 No psychic guards harder fix.esp
2A Oblivion XP.esp [Version 4.1.5]
2B EVE_KhajiitFix.esp
2C QTdof.esp
2D Real Lava 1.3.esp
2E MiniMap.esp
2F Oblivion Graphics Extender Support.esp [Version 0.2]

Load order was sorted with BOSS, I'm using OBMM to manage the mods

Specifically I'm wondering about merging leveled lists. Is it necessary with the mods I have?

Secondly, 2 mods are highlighted in red, with the bashed tags of 'graphics, deactivate'
Those are Real Lava 1.3 and GrimbotsSpellTomes.

Is having them active somehow causing problems?

Cheers

For future reference:

Wrye Bash - http://sites.google..../prep/wrye-bash
Bash's Mods Tab - http://sites.google....ash/bashmodstab
Finishing the Installation - http://sites.google....oinfo/tunesetup
Bashed Patch - http://sites.google....all/bashedpatch

There will be much more information with the future overhaul of the site. It should develop to the point where user will not have to complain about what the outdated Bash Read Me is lacking, in content and in depth. It will not make the Read Me obsolete though. You'll find it linked somewhere on most Bash-related pages.

Your questions have already been answered, and I will only add that you should switch from managing your load order with OBMM to using only Bash for that purpose. It will give you more control and flexibility. Using both to manager you load order can be pretty confusing, especially if you begin using a bashed patch.

[Katnap]

I have a mod with weapon stats that is being overwritten by Oscuro's in the bashed patch. The stats tag itself is more than just weapons stats so I gather from the Wrye Bash readme so I can't really see anyway of excluding weapons stats from oscuros's in the bashed patch without affecting other things. Is this correct, or have I missed something in the readme.

[Blade Of Mercy]

I regret to report very unpleasant bug. Very.
Every time after I run TES4View, Wrye bash gives me error message and in mid-BAINstallation of 360+ packages simply refused to load anymore, quickly running a lot of messages instead and not loading at all.
This happens if I run TES4View with Wrye Bash closed or open, no matter.
Hope you'll find cure, for now will reinstall and start fresh BAINstallation without using TES4View.

[FrodoTheDarkLord]

[IMG]http://i261.photobucket.com/albums/ii79/ihatethisfreakingusername/Wrye_Bash_Linux.png[/IMG]

I tracked down the error by inserting massive amounts of print statements into every step of the program. it turned out to be a seemingly innocent line in basher.py

basher.py, line 4346, in class BashApp(wx.App)

progress.Update(80,_("Initializing Windows"))

Commenting it out fixed the segmentation fault. Now I'm off to seeing if Wrye Bash actually works beyond the GUI.

Edited by FrodoTheDarkLord, 20 May 2010 - 08:00 AM.

[Corepc]

I have a mod with weapon stats that is being overwritten by Oscuro's in the bashed patch. The stats tag itself is more than just weapons stats so I gather from the Wrye Bash readme so I can't really see anyway of excluding weapons stats from oscuros's in the bashed patch without affecting other things. Is this correct, or have I missed something in the readme.

You need to tag your mod with Stats so that is overwrite OOO stats. Which mean you may need to load it after OOO.esp or OMOBS in order for you stats to stick has well.

[lunat!c]

Not sure if this was done intentionally, but I am going to ask anyway.

When I am using BAIN, and have finished an BAIN achieve.. I check whatever is necessary, and install it. Now it is possible that I have found something on-line which is related to the package. I then unpack the achieve, add the file(s) and repack it.

Whenever I add something to my package that has a number which is greater than the rest, everything is fine. Now whenever I add a directory that is in between the first <=> last number, the checked boxes spring a level up (depending on how many folders I add - 2 = 2 levels up). When dealing with smaller packages then it is no problem, but larger (say, 50 folders) it can become rather confusing.

Is this a function which has some special meaning? Or something which has not been addressed yet?

(using RC1).

lunaaaa

[Surazal]

Is this a function which has some special meaning? Or something which has not been addressed yet?

This is how WB works. I recall that someone has already asked for WB to "remember" which sub-packages have been selected rather than base the selection on sequence, but can't remember whether it was going to be done.

[Katnap]

You need to tag your mod with Stats so that is overwrite OOO stats. Which mean you may need to load it after OOO.esp or OMOBS in order for you stats to stick has well.

Thanks Corepc, I did tag it stats but forgot to check it in the merged list.

[myk002]

I tracked down the error by inserting massive amounts of print statements into every step of the program. it turned out to be a seemingly innocent line in basher.py

basher.py, line 4346, in class BashApp(wx.App)

progress.Update(80,_("Initializing Windows"))

Commenting it out fixed the segmentation fault. Now I'm off to seeing if Wrye Bash actually works beyond the GUI.

I think I found the real reason for the crash, which I'm surprised doesn't happen on Windows too. The line before

progress.Update(80,_("Initializing Windows"))

is

progress.Destroy()

. Moving the Destroy line after the Update line avoids the crash, and still updates the progress bar (like I assume it was intended to).

[Waruddar]

That is a silly mistake.

Fixed for next version.

Wonder how long it's been there...

Edit: It's present way back in Wrye Bash 0.79, which is the oldest one I have archived. So it's been there from the beginning

Edited by Waruddar, 20 May 2010 - 01:50 PM.

[Tomlong75210]

Okay, how in the world does the 64-bit work around or installation work? I have looked at at least five open cases of those users not being able to run Wrye Bash, so I think it is time I went to the source for an answer or two. I saw the advice on the UESP Wiki pages, and I want to confirm or get help with the right instructions for this configuration.

My post: http://forums.bethso...st__p__15962012 <-- Do I have the correct shortcut config here? What is the shortcut config for Win7 users? Do they need to download wxPython separately from the Wrye Python 02 package?

[Waruddar]

I run Win7 x64, without any runtime issues.

There is an install issue though. After running Wrye Python 02, you'll have to go into the extracted folder (Wrye Python) and run wxPython2.8-win32-ansi-2.8.10.1-py26.exe manually. The exe installer extracts wxPython, but it doesn't actually run it for some reason. Btw, it's normally fine to delete the Wrye Python folder afterwards. All it should contain are five install files.

Edited by Waruddar, 20 May 2010 - 03:31 PM.

[Tomlong75210]

I run Win7 x64, without any runtime issues.

There is an install issue though. After running Wrye Python 02, it you'll have to go into the extracted folder (Wrye Python) and run wxPython2.8-win32-ansi-2.8.10.1-py26.exe manually. The exe installer extracts wxPython, but it doesn't actually run it for some reason. Btw, it's normally fine to delete the Wrye Python folder afterwards. All it should contain are five install files.

Thank you very much. I can save (by introducing them to Wrye Bash) about seven users now, haha.

[showler]

Only problem I had with the WryePython02 package was that I had to run several of the sub-installers as an Administrator in order to make them install correctly. Probably because I do install those into my Program Files folder.

Haven't bothered trying to run with 64-bit versions of the Python components, because those aren't feature complete last I read.

[Waruddar]

Yeah, I'm running 32 bit Python.