[Janine Rose]

Well then, that explains it!
For the record: Race raises the concept of merging to another level, really. :rofl: B)

[Eire Charlotta]

Thanks for staying on top of the thread, showler. I really appreciate it. Gives me more time to focus on getting CBash working.

Speaking of which, I'll give a quick status update. Since this next release of Bash is taking longer than I thought it would, it looks like it'll have the entire bashed patch converted to use CBash. I only have ~10 functions left to convert for the patch.

The next release will probably still require manual renaming of CBash.dll in order to activate it. The release after that will likely have CBash enabled by default, but can have CBash disabled by renaming the dll. At that point, any new functionality will require CBash. Later on, CBash will be the only option and it won't be able to be disabled.

[Andrew Tarango]

I only have ~10 functions left to convert for the patch.

That's quite impressive! I've been following the sourceforge updates and you are doing a nice job! Thanks for the time you are putting into it!

[Sarah Knight]

I have a master containing only hair and eye records: KhRaces.esm. I have three plugins that assign these hairs and eyes to races: KhRaces - Eyes for Stock Races.esp, KhRaces - Hairs for Stock Races.esp, and KhRaces - New Race.esp.

So I tagged the Eyes plugin with "EYES" and the Hairs plugin with "HAIRS", ticked the boxes next to both under "Merge Patches" and "Race Records", and clicked "Rebuild Patch". I got (and got and got and got) the following error:

Traceback (most recent call last):  File "C:\_Ob\Oblivion\Mopy\basher.py", line 4883, in Execute    patchFile.buildPatch(log,SubProgress(progress,0.8,0.9))#no speeding needed/really possible (less than 1/4 second even with large LO)  File "C:\_Ob\Oblivion\Mopy\bosh.py", line 14426, in buildPatch    patcher.buildPatch(log,SubProgress(subProgress,index))  File "C:\_Ob\Oblivion\Mopy\bosh.py", line 20051, in buildPatch    raise StateError(_('Mesh undefined for eye %s in race %s') % (strFid(eye),race.eid,))bolt.StateError: Mesh undefined for eye (KhRaces Master.esp,0x001650) in race Argonian

Now, I use EE meshes replacer-style, without assigning them in a plugin. All of the eyes in the Eyes plugin are EE-compatible, though there are some other eyes in the master that are only used by the New Race plugin. The New Race plugin assigns another eye mesh to the new race. If I disable the Eyes plugin, I get the same error for the race added by the New Race plugin. And just in case, I did manually clean the master and all three plugins to be sure I didn't accidentally set a new mesh or clear the stock mesh from any of the stock races. That didn't work, and neither did actually assigning the EE mesh.

However, merging the plugins with the master so that all the eye records originate from the plugin assigning the eyes to races makes the error go away and the patch works fine. All three work fine in-game independently without a patch, too, but I want to use them all at once - and sometimes in tandem with other plugins that modify stock races.

I can de-isolate all the plugins, but I don't wanna unless that's the only solution. Halp? Please and thank you in advance.

PS - Please don't bite my fingers off! I googled to no avail.

[Robert DeLarosa]

I'll be sure to look into it when I convert that function to CBash. Not sure what is going on there without reviewing the code.

Should get to it later today. It's about half-way down the list of functions for me to look at.

[kasia]

I'll be sure to look into it when I convert that function to CBash. Not sure what is going on there without reviewing the code.

Should get to it later today. It's about half-way down the list of functions for me to look at.

Hooray!

Thank you so much for all your hard work!

[jeremey wisor]

I'd guess it might have something to do with Bash's "googly eyes" fixer. Something to ensure that meshes/textures match correctly for eyes.

[Kelsey Anna Farley]

Hrm.

Not particularly happy that mod is there. Not because I don't personally agree with supporting the Data\INI directory (if it was up to me, I'd add support for it in a heartbeat), but because we haven't added support for a reason. It is a touchy subject with Wrye. Lots of drama involved with the decision...support was added at one point, and Wrye explicitly disabled support and admonished people for adding it. We'd rather not step on his toes and get permission to update Wrye Bash taken away from us.

I don't want to disrespect Wrye after he granted the use of such an incredible tool for which OB would be unplayable w/o (IMHO). :bowdown: (No sarcasm intended) So I'm sorry if this makes the situation more difficult for you. I'm glad you said something about this. I appreciate all the work the current developers have done as well.

[(G-yen)]

Hooray!

Thank you so much for all your hard work!

After reviewing the code, I still don't know what's going on. That is a very confusing area of code...I'll just do a full rewrite of the blasted thing for CBash, and hope it incidentally solves your problem.

[Dalton Greynolds]

svn482
tag 'Invent' is not work?

CNRP Cheydinhal.esp
% {{BASH:Invent}}
Screenshot
http://yfrog.com/jxinventkp

[Emilie Joseph]

Umm, I get this error during Rebuild Patch:

Traceback (most recent call last):  File "E:\Program Files\The Elder of Scrolls IV - Oblivion\Mopy\basher.py", line 4921, in Execute    raise  File "E:\Program Files\The Elder of Scrolls IV - Oblivion\Mopy\basher.py", line 4883, in Execute    patchFile.buildPatch(log,SubProgress(progress,0.8,0.9))#no speeding needed/really possible (less than 1/4 second even with large LO)  File "E:\Program Files\The Elder of Scrolls IV - Oblivion\Mopy\bosh.py", line 14426, in buildPatch    patcher.buildPatch(log,SubProgress(subProgress,index))  File "E:\Program Files\The Elder of Scrolls IV - Oblivion\Mopy\bosh.py", line 20501, in buildPatch    tweak.buildPatch(log,progress,self.patchFile)  File "E:\Program Files\The Elder of Scrolls IV - Oblivion\Mopy\bosh.py", line 20295, in buildPatch    if record.full.lower() == 'bendu olo': continueAttributeError: 'NoneType' object has no attribute 'lower'

Edit: I see it's a problem with Mayu's option in Bash, is there any beta of Wrye which has it updated?

[Rhysa Hughes]

Hrm.

Not particularly happy that mod is there. Not because I don't personally agree with supporting the Data\INI directory (if it was up to me, I'd add support for it in a heartbeat), but because we haven't added support for a reason. It is a touchy subject with Wrye. Lots of drama involved with the decision...support was added at one point, and Wrye explicitly disabled support and admonished people for adding it. We'd rather not step on his toes and get permission to update Wrye Bash taken away from us.

At the risk of once more beating this dead horse, the reasoning for blocking Data\ini was never properly justified, and when Wrye asked for reasons to support it, several of us provided extensive lists of mods which already use the path. He originally had Data\Scripts instead, and at the time not one of us found any mods actually using that path. Fast forward to today, and you have even more supporting Data\ini. The reality of it is, the utility is not keeping actual usage in mind.

As far as the permission issue, legally speaking nobody needs permission. Wrye Bash is licensed under GPL 2.0 which grants anyone the right to modifiy and distribute the results. I'm sure it would ruffle some feathers, but seriously, if he wants to handle things that way over one feature that makes no sense to begn with, then perhaps it's time to fork development. That would be pretty dumb to do over a single feature but come on.

[Karl harris]

I think it's More about Respect,...

[Betsy Humpledink]

Got no problem with respect, but seriously, are you suggesting we hold up on something users will find useful and friendly out of respect for one person who isn't even playing the game anymore?

[Kelvin]

If I may intrude for a moment...I'm having a slight (well, major) problem. I installed the Wrye Python 02 pack and the Wrye Bash 285 - Archive Version from TESNexus. It all installed fine, I dropped Wrye into my Oblivion folder, and...nothing. I click on Wrye Bash Launcher.pyw and nothing happens. Nothing. No error message, no program. I'm running Windows 7 Ultimate 64-bit...what do I do? I need to use Bashed Patch so I can merge TNR faces. =/

EDIT: Well, I did some cmd line crap and then ran it from bash.py and it launched. So, fixed (I guess). O.o

[Colton Idonthavealastna]

Got no problem with respect, but seriously, are you suggesting we hold up on something users will find useful and friendly out of respect for one person who isn't even playing the game anymore?

It's really not my spot to suggest anything one way or another, but I can understand where one Modder would have Issues changing someone else's creation in a way they were specifacly opposed to, regardless of reasons... :shrug:

[Bethany Short]

It's really not my spot to suggest anything one way or another, but I can understand where one Modder would have Issues changing someone else's creation in a way they were specifacly opposed to, regardless of reasons... :shrug:

I agree with Brozly, GPL or not, as long as this tool sails under the name of Wrye his wishes should be respected.

[Add Meeh]

At the risk of once more beating this dead horse, the reasoning for blocking Data\ini was never properly justified, and when Wrye asked for reasons to support it, several of us provided extensive lists of mods which already use the path. He originally had Data\Scripts instead, and at the time not one of us found any mods actually using that path. Fast forward to today, and you have even more supporting Data\ini. The reality of it is, the utility is not keeping actual usage in mind.

As far as the permission issue, legally speaking nobody needs permission. Wrye Bash is licensed under GPL 2.0 which grants anyone the right to modifiy and distribute the results. I'm sure it would ruffle some feathers, but seriously, if he wants to handle things that way over one feature that makes no sense to begn with, then perhaps it's time to fork development. That would be pretty dumb to do over a single feature but come on.

So Wrye would rather we use Data\Scripts for INI files? Or is this about modders NOT using INI files at all?
Edit: Thanks for clarification.

[SiLa]

Wrye wanted people to use Data\Scripts for INI files. This is because, technically, all the INI files are scripts, but not all script files are INI files. He wanted a centralized location that would make sense for any text file that was used by a mod via RunBatchScript. So he chose the more generic "Scripts" directory instead of the "INI" directory. He did ask for input when he was making the decision, but it was overlooked by most. Later, when people began wondering why INI files weren't installing, they were less than pleased that Wrye had chosen a directory that they didn't like. PacificMorrowind added support for the INI directory by request, and Wrye was less than pleased because he had already asked for input a few months before this, and considered the location as standardized. He removed support for the INI directory, and had a few choice words with all involved.

The whole kerfuffle was because Wrye wanted to enforce the Scripts directory standard. The problem is that he failed. As mentioned, nobody really uses the Scripts directory, and many use the INI directory. So the INI directory is now the de facto standard.

That said, we have already been discussing adding support for the INI directory again since the whole thing is getting kind of silly. We are all leaning towards it, and sent a PM to Wrye a month or so ago. It has yet to be answered. Unless Wrye responds with an emphatic "No!", we are considering adding support sometime in the next couple releases.

As this is a sensitive topic, please drop this subject for now.

[CHANONE]

So Wrye would rather we use Data\Scripts for INI files? Or is this about modders NOT using INI files at all?

He said he wants people to use Data\Scripts, but when arguments were presented about why this is either confusing or an inconvenience to mods that already used Data\ini he simply reverted back to basically saying "this is how I want it". There was also some arbitrary reference to a discussion that he tried to start several months before BAIN was even known. It may well be that nothing used either path that far back, but he got it in his head that because nobody spoke up, they forever forfeited their chance to say anything about it later.

The number of mods using the Data\ini folder is only growing, and to date I'm still not aware of a single one that uses Data\Scripts. Honestly, it's only serving to cause inconvenience now because you're unlikely to get all of those modders to go back and change their work for the sake of one utility that's not doing it right. I don't really think it's fair to ask 40+ people to go back and alter their mods when a simple change in allowing BAIN to process one more folder is much easier and only encourages further adoption of BAIN.

Ultimately this is going to be up to those who are currently maintaining the package, so if they don't want to do it, it won't get done. It just seems pretty silly to block it because ONE person hated it.

[N Only WhiTe girl]

I need a little help. When I try to start Wrye Bash it crashes when it comes to initializing windows.

Bugdump

Traceback (most recent call last):  File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\Wrye Bash Launcher.pyw", line 94, in     main()  File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\Wrye Bash Launcher.pyw", line 83, in main    app = basher.BashApp()  File "C:\Python26\lib\site-packages\wx-2.8-msw-ansi\wx\_core.py", line 7978, in __init__    self._BootstrapApp()  File "C:\Python26\lib\site-packages\wx-2.8-msw-ansi\wx\_core.py", line 7552, in _BootstrapApp    return _core_.PyApp__BootstrapApp(*args, **kwargs)  File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 3678, in OnInit    size=settings['bash.frameSize'])  File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 3066, in __init__    self.notebook = notebook = BashNotebook(self,-1)  File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 2991, in __init__    self.AddPage(MessagePanel(self),_("PM Archive"))  File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 2734, in __init__    import wx.lib.iewin  File "C:\Python26\lib\site-packages\wx-2.8-msw-ansi\wx\lib\iewin.py", line 15, in     import wx.lib.activex  File "C:\Python26\lib\site-packages\wx-2.8-msw-ansi\wx\lib\activex.py", line 36, in     import comtypesImportError: No module named comtypes

I have installed python 2.6.4, wxPython2.8 and psyco 1.6

[Scotties Hottie]

ImportError: No module named comtypes

You missed the comtypes requirement.

[Nick Tyler]

I keep getting this error if I include http://tesnexus.com/downloads/file.php?id=19949

MERGE/SCAN ERROR: M.O.E. - Main Quest Delayer.esp
Traceback (most recent call last):
File "F:\games\oblivion\Mopy\basher.py", line 4921, in Execute
raise
File "F:\games\oblivion\Mopy\basher.py", line 4882, in Execute
patchFile.scanLoadMods(SubProgress(progress,0.2,0.8)) #try to speed this up!
File "F:\games\oblivion\Mopy\bosh.py", line 14331, in scanLoadMods
raise
File "F:\games\oblivion\Mopy\bosh.py", line 14327, in scanLoadMods
patcher.scanModFile(modFile,nullProgress)
File "F:\games\oblivion\Mopy\bosh.py", line 18016, in scanModFile
if record.eid.lower() == tweak.key:
AttributeError: 'NoneType' object has no attribute 'lower'

Also, was thinking of trying CraftyBits... I do not need to include the .esp during bashing but the other 2; .esm and the coblglue is still needs to be bashable, yes?

[Lexy Dick]

You missed the comtypes requirement.

I know that. What I don't know is how to fix it.

[Alexandra walker]

I know that. What I don't know is how to fix it.

Did you read the first post in this very thread by any chance ? :whistling: