[Jah Allen]

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...

[Kate Norris]

NoMerge means just that. Do not merge. Do not choose under "Merge Patches". This is actually a message to Bash itself that prevents it from even offering you the chance to merge it.

Deactivate means "Don't have it active the normal way either". It's to have its graphics imported only, not to be active in any way.

[(G-yen)]

NoMerge means just that. Do not merge. Do not choose under "Merge Patches". This is actually a message to Bash itself that prevents it from even offering you the chance to merge it.

Deactivate means "Don't have it active the normal way either". It's to have its graphics imported only, not to be active in any way.

I guess I knew that, the thing is that when you click Rebuild Patch, it prompts you that they should be Deactivated...

[El Goose]

They should be, if they have "Deactivate". They don't have to be active to import graphics from them.

Or is it prompting you for all "NoMerge" ones as well? I'll admit I'm a little iffy on that myself, so maybe all "NoMerge" ones need to be deactivated as well. They probably do, come to think of it.

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

[Agnieszka Bak]

They should be, if they have "Deactivate". They don't have to be active to import graphics from them.

Or is it prompting you for all "NoMerge" ones as well? I'll admit I'm a little iffy on that myself, so maybe all "NoMerge" ones need to be deactivated as well. They probably do, come to think of it.

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

Yeah, All of the Purple ones prompt you to deactivate wether Italic or not, Mod checker tells you they should be Deactivated as well...

[Olga Xx]

They should be, if they have "Deactivate". They don't have to be active to import graphics from them.

Or is it prompting you for all "NoMerge" ones as well? I'll admit I'm a little iffy on that myself, so maybe all "NoMerge" ones need to be deactivated as well. They probably do, come to think of it.

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

That is not redundant. IFor example, the book replacer ESP does not have to be deactivated because, when activated, it fixes the position of various books. If the user does not care (or does not know) deactivating it is fine too. I guess I should've mentioned that it is tagged with NoMerge and Graphics. However, most (but I certainly cannot say all) mods with the NoMerge tag should or might as well be deactivated.

[Jack Walker]

Oh I know what that error is... you are using the Unicode rather than ANSI version of wxPython... fairly harmless errors for the most part; install the ANSI version of wxPython if you don't want to have them or just live with them
Pacific Morrowind

Thought I did ANSI version but checking somehow I used the Unicode, mistake in downloading both.
Reinstalled with the ANSI version.
Put tejón back in and no errors.
thanks

[Adam Porter]

Yeah, All of the Purple ones prompt you to deactivate wether Italic or not, Mod checker tells you they should be Deactivated as well...

Well I have at least one thing, the TIE+Frans Inventory Patch, that if left untagged Bash will mark in green, saying it can be merged. However every time I had tried that, it didn't work properly. So it needs to be activated, which to me probably means it shouldn't also be merged. If tagging something NoMerge is going to forcefully deactivate it, that's just plain wrong. NoMerge is not a functional equivalent for Deactivate.

[Solène We]

That's what I thought at first, but then I started to question my own thinking.

So "NoMerge" and "Deactivate" should be treated separately and you should be able to have both or either on a mod, depending on circumstances. That probably means that WB behaviour regarding the tags needs to be updated.

[Emily Jeffs]

So, I'm the guy that long ago promised to try and get Wrye Bash working on Linux, and, since I have finally after all those months gotten a chance to play Oblivion again, I might actually deliver on my promise now. Anyway, I have a question, Pacific: the first line Wrye Bash fails is during the initialization process:

Traceback (most recent call last):  File "Wrye Bash Launcher.py", line 97, in     bosh.initDirs(personal,localAppData,oblivionPath)  File "/home/arne/games/wine/Oblivion/drive_c/Program Files/Bethesda Softworks/Oblivion/Mopy/bosh.py", line 20041, in initDirs    personal = getShellPath('Personal')  File "/home/arne/games/wine/Oblivion/drive_c/Program Files/Bethesda Softworks/Oblivion/Mopy/bosh.py", line 20019, in getShellPath    import _winregImportError: No module named _winreg

This is the relevant part of the function:

#--Determine User folders from Personal and Local Application Data directories    #  Attempt to pull from, in order: Command Line, Ini, win32com, Registry    #  Import win32com, in case it's necessary    try:        from win32com.shell import shell, shellcon        def getShellPath(shellKey):            path = shell.SHGetFolderPath (0, shellKey, None, 0)            path = path.encode(locale.getpreferredencoding())            return GPath(path)    except ImportError:        shell = shellcon = None        reEnv = re.compile('%(\w+)%')        envDefs = os.environ        def subEnv(match):            key = match.group(1).upper()            if not envDefs.get(key):                raise BoltError(_("Can't find user directories in windows registry.\n>> See \"If Bash Won't Start\" in bash docs for help."))            return envDefs[key]        def getShellPath(folderKey):            import _winreg            regKey = _winreg.OpenKey(_winreg.HKEY_CURRENT_USER,                r'Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders')            try:                path = _winreg.QueryValueEx(regKey,folderKey)[0]            except WindowsError:                raise BoltError(_("Can't find user directories in windows registry.\n>> See \"If Bash Won't Start\" in bash docs for help."))            regKey.Close()            path = path.encode(locale.getpreferredencoding())            path = reEnv.sub(subEnv,path)            return GPath(path)

I guess you want to find the AppData folder so you can store Wrye Bash data there, but the way that it's returned confused me a bit.

return GPath(path)

What does the function GPath do? I was thinking that to solve the problem, I would just load a path from a file or have the user input it in a shell, but I'm not sure what GPath does, so I'm uncertain as to how 'path' is formatted. I searched for 'def GPath' in bosh.py and I found nothing, so it must be defined elsewhere, but I didn't see it imported anywhere either. Could you shed some light on this?

[Shelby McDonald]

So, I'm the guy that long ago promised to try and get Wrye Bash working on Linux, and, since I have finally after all those months gotten a chance to play Oblivion again, I might actually deliver on my promise now. Anyway, I have a question, Pacific: the first line Wrye Bash fails is during the initialization process:



I guess you want to find the AppData folder so you can store Wrye Bash data there, but the way that it's returned confused me a bit.

return GPath(path)

What does the function GPath do? I was thinking that to solve the problem, I would just load a path from a file or have the user input it in a shell, but I'm not sure what GPath does, so I'm uncertain as to how 'path' is formatted. I searched for 'def GPath' in bosh.py and I found nothing, so it must be defined elsewhere, but I didn't see it imported anywhere either. Could you shed some light on this?

GPath returns a python path object of a file path (in string format) that is entered into it (ie say GPath(r'C:\Program Files\Oblivion) for example).
It is defined in bolt.py. (and imported at the start of bosh.py by import bolt)
Hope that clarifies it.
EDIT just remembered, should mention that starting Bash via command line you can already manually define those; just use the following or simlar code as your command line (don't know what changes would be required on linux though):

C:\Python26\python.exe  "Wrye Bash Launcher.pyw" -p "C:\\Documents and Settings\\Wrye\\My Documents" -l "C:\\Documents and Settings\\Wrye\\Local Settings\\Application Data"

Pacific

[Emmanuel Morales]

That's what I thought at first, but then I started to question my own thinking.

So "NoMerge" and "Deactivate" should be treated separately and you should be able to have both or either on a mod, depending on circumstances. That probably means that WB behaviour regarding the tags needs to be updated.

I think that alerting the user about it is okay, but the alters should be different. Mods tagged with NoMerge often are better off deactivated, so the alert to suggest doing that is helpful to users that might otherwise overlook that option. However, the Deactivate tag needs to be alerted (for obvious reasons.)

[Monique Cameron]

Gettting an error with the .obse statistics feature.

Traceback (most recent call last):  File "D:\Oblivion\Mopy\basher.py", line 10084, in Execute    saveFile.logStatObse(log)  File "D:\Oblivion\Mopy\bosh.py", line 6047, in logStatObse    log(_('    Mod :  %02X (%s)') % (modIndex, self.masters[modIndex].s))IndexError: list index out of range

Small bump.

[Sammygirl500]

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

[Amysaurusrex]

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?

OBSE scripts are not the same as OBSE plugins. OBSE scripts are TXT or INI files that can be installed into custom directories. They are harmless, so Wrye Bash will allow them to be installed if you choose the "Has Extra Directories" option.

OBSE plugins (in the context we are referring to) are DLL type files that are loaded by OBSE when starting Oblivion. DLL files can be exploited to do potentially harmful things to your computer, so Wrye designed WB to exclude those types of files. He wanted to make sure that if you installed any DLL files, you did it intentionally and with awareness of what you were doing.

There is a hack to expose the ability. I don't know what it is, but since there are only a few DLL files to begin with, and they are updated fairly rarely, I'd just install them by hand. They are very easy to control in a manual way.

[Tina Tupou]

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

It does not. "Has Extra Directories" is not for OBSE. It is for mods with non-standard folders (and the OBSE folder would not be non-standard, anyway) It is not a matter of want. Many of use would like that extension, but coding has other restrictions. Hopefully, the answer to your question is yes. I have not heard anything of v284 offering that functionality, but I have yet to download it.

[Leonie Connor]

Honestly I can′t seem to understand how real modders mod their game in practice. Take for example how you pros REALY install their mods. Wyre bash seems to be the way to go and even then you seem to have to install some mods that use OBSE with OBMM. How does that even work out if two programs that dictate the load order both supply a different list? You can hardly install mods with both programms right?

And then there's an other issue involving the practice of mod installing. Take for example the guide to install FCOM. It says to "Download and install OOO 1.33 in EXE or OMOD-ready format". If you install OOO this way it aint an archive and you can't load it into wrye bash since it doesnt support omods, and how can you even use wrye bash to configure FCOM later on then? There seems to be a very confusing discrepancy in what the programs do and in what the modders do. Hell a some mods don't even have a archive format download on some sites in favour of omod ready.

Also a more wrye bash specific problem: when you install OOO with OBMM it asks you if you want harvest flora, living economy etc etc. But when I dumped the archive of OOO in wrye bash it just activated without asking anything. How do I know what's installed now? Do I have to place the files manualy?

It would be reeeealy appreciated if someone can answer these questions, because I can't find some readme or site that can help me out here.

I'm not sure what guide you're referring to, but have you seen this site? http://sites.google.com/site/oblivionpoinfo/

[Zosia Cetnar]

nvm, third edit's the charm apparently.

[Angel Torres]

That's what I thought at first, but then I started to question my own thinking.

So "NoMerge" and "Deactivate" should be treated separately and you should be able to have both or either on a mod, depending on circumstances. That probably means that WB behaviour regarding the tags needs to be updated.

I posted something about an anomaly with how this is working earlier (loadingscreens.esp). My understanding is that a mergeable mod that is tagged with NoMerge should be deactivated and will be highligthted in purple. My concern is that a mod that is not mergeable and has the nomerge tag is included in the Rebuild Batch prompt to deactivate.

The Deactivate tag seems to be appropriate for when there are tags which result in all elelments being incorporated in the bashed patch and which should therefore be deactivated.

I think some of this needs a little bit of tidying up to be more reliable.

[m Gardner]

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

[Elisha KIng]

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.

[Nicholas C]

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.

[Ludivine Dupuy]

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... :facepalm:

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 anolyse 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.esmTraceback (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

[Becky Palmer]

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!

[Sophie Payne]

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.