Good people pointed the 291 installer to me, I uninstalled the 275 topped up with 287 topped up with 290.
Then I made fresh install of the brand new and shiny 291 (installer worksfine) and rebuilt the patch. Eerything works fabulous.

One suggestion: why not pin the download link for 291 at the top of post #1?

PM posted an early beta of it, but 291 has not been officially released. There have been vast improvements since that beta.

Edit: Aha! Found the bug. Now just gotta figure out how to handle it.

For the curious, here's what's happening:
1) Every mod that is being imported from is basically off in its own little load order separate from the main load order. This allows Bash to import mods even if the main load order is full. The imported mods masters are NOT loaded because they may not exist (filter mods).
2) Since it has its own load order, its formIDs do NOT match up with the formIDs of the main load order.
3) 01001D88 in the imported mod refers to DLCSpellTomes.esp.
4) 01001D88 in the main load order refers to TR_OoT_Main.esm.
5) When CBash looks up the history of 01001D88 for Book Jackets OB+SI+DLC.esp, it looks in the main load order. It just so happens that the record exists, but it's the wrong one. More importantly, it's the wrong type of record. Bash thinks that it is a book record since that's what it asked about, so it asks for the 8th field (the modt_p attribute) thinking that its getting an array of bytes. Instead it gets whatever the 8th field is of whatever record type it actually is. It happens to return a zero, Bash thinks it's a null pointer, and boom.

Will get a fix out soonish. Need to decide whether it's important for the imported mod masters to be loaded if they exist, or if I can get away with a quick fix.

Getting this error with 753 when clicking on a BAIN package in the installers tab, reproduced several times:

Traceback (most recent call last):  File "E:\Spel\Oblivion\Mopy\balt.py", line 1386, in OnItemSelected    self.RefreshDetails(self.GetItem(event.m_itemIndex))  File "E:\Spel\Oblivion\Mopy\balt.py", line 1349, in RefreshDetails    if self.details: return self.details.RefreshDetails(item)  File "E:\Spel\Oblivion\Mopy\basher.py", line 2712, in RefreshDetails    if (index == currentIndex): self.RefreshInfoPage(index,installer)  File "E:\Spel\Oblivion\Mopy\basher.py", line 2829, in RefreshInfoPage    _("== Configured Files"),isPath=True))UnicodeDecodeError: 'ascii' codec can't decode byte 0xa0 in position 54: ordinal not in range(128)Traceback (most recent call last):  File "E:\Spel\Oblivion\Mopy\balt.py", line 1386, in OnItemSelected    self.RefreshDetails(self.GetItem(event.m_itemIndex))  File "E:\Spel\Oblivion\Mopy\balt.py", line 1349, in RefreshDetails    if self.details: return self.details.RefreshDetails(item)  File "E:\Spel\Oblivion\Mopy\basher.py", line 2712, in RefreshDetails    if (index == currentIndex): self.RefreshInfoPage(index,installer)  File "E:\Spel\Oblivion\Mopy\basher.py", line 2829, in RefreshInfoPage    _("== Configured Files"),isPath=True))UnicodeDecodeError: 'ascii' codec can't decode byte 0xa0 in position 54: ordinal not in range(128)

What is the name of the package?

DLCs-BAIN.7z is the name of the first package where it happens. Checked on another 10 packages down the list and all except one caused it. Name of the one where it didn't happen was Elven_Map_For_Shivering_Isles-16640.7z if that helps any

Hrm.

In the last couple commits, I re-enabled support for extended characters. So this should only occur on packages that contain files with extended characters (and then, only on non-supported extended characters).

Can you do a "List Structure..." on one of the packages that aren't working? It will probably throw an error as well, but there's a chance it won't.

Edit: Actually, do you know if you have the ascii version of wxPython installed? The new changes require the unicode version to work properly.

If you used the installer version of Bash, you probably have the ascii version (I need to double check). You can either install the unicode version or revert to an earlier revision of Bash.

No extra errormsg from doing that and all files shows up there. However they don't show up in the General tab or subpackages / esp/m filter tabs.



And here's example of one List Structure from a package that worked correctly:



Edit: Just noticed your edit, will look it up quickly.
Edit 2: Appears I do have the ascii version yes, as wxPython was installed via wxPython2.8-win32-ansi-2.8.11.0-py26.exe

Arthmoor, halo112358, please try revision 754. I made a quick change to CBash that should prevent the bug. There's a chance it will result in import patchers importing more than they should from a record, but I don't think it will be a problem.

Edit: Hurray for edit wars Please install the unicode version and see if you still have problems. You can always switch back to the ascii version if it doesn't work for you.

Will try it out, once I can find the unicode version somewhere. Downloading wxPython2.9-win32-2.9.1.1-py26.exe currently from sourceforge, not sure if that's it.

Wrong version. Let me dig up the link real quick.

Edit:
http://downloads.sourceforge.net/wxpython/wxPython2.8-win32-unicode-2.8.11.0-py26.exe

The 2.9 series is under development, so we haven't tested it at all with Bash.

Found it I think, wxPython2.8-win32-unicode-2.8.11.0-py26.exe should be the correct one judging from the filename of the ascii-version. Sorry about that.
And yep, it was according to your edit.

No errors thrown with 754.

I was looking through the patch that was built before trying 754 and it looks like bugs 3111390 and 3111400 still exist, but I can't see any evidence of the others still existing. Once those two get squashed somehow then all that will remain is getting the Actors.AIPackages function working in CBash.

Okay, installed the unicode package whilst keeping the ansii package installed aswell (default to different folders after all). Unicode as the default wxPython. Result is still the same:

Traceback (most recent call last):  File "E:\Spel\Oblivion\Mopy\balt.py", line 1386, in OnItemSelected    self.RefreshDetails(self.GetItem(event.m_itemIndex))  File "E:\Spel\Oblivion\Mopy\balt.py", line 1349, in RefreshDetails    if self.details: return self.details.RefreshDetails(item)  File "E:\Spel\Oblivion\Mopy\basher.py", line 2712, in RefreshDetails    if (index == currentIndex): self.RefreshInfoPage(index,installer)  File "E:\Spel\Oblivion\Mopy\basher.py", line 2829, in RefreshInfoPage    _("== Configured Files"),isPath=True))UnicodeDecodeError: 'ascii' codec can't decode byte 0xa0 in position 54: ordinal not in range(128)

Results with both installed and ansii as default package is exactly the same.

Finally tried with ansii uninstalled and unicode installed, and still got the same results. 751 is the latest version I tried prior to this which worked perfectly, but I'll gladly keep testing if there's anything else you can think of.

Arthmoor, just to confirm, the formID bugs have been fixed, yes? Those last two bugs shouldn't be too hard to fix in Bash's patcher code.

Peste, I'm afraid I'm not making much sense of this. Not sure what's wrong if installing the unicode version of wxPython didn't fix it.

Let's backtrack a bit. What version of python and components are you using?

For comparison, I'm testing with:
comtypes-0.6.2.win32.exe
psyco-1.6.win32-py2.6.exe
python-2.6.6.msi
pywin32-214.win32-py2.6.exe
wxPython2.8-win32-unicode-2.8.10.1-py26.exe
wxPython2.8-win32-unicode-2.8.11.0-py26.exe

I'll try updating my wxPython and see if it bugs out.

The updated wxPython still works on my end :shrug:

Using the exact same versions as you except that I have the 2.8.11.0 package of wxPython.
I could try a complete reinstall of Bash from 275 > 287 > 290 > latest SVN and see if that changes any, never know.

Edit: That didn't change anything I'm afraid.

Ack. That's a convoluted install process.

Just install those components above, and then the latest SVN. There's no need to go through all those upgrade steps.

Ah, I see - just did it that way since 275>287>290 was what I was told was best prior to 291. Will uninstall and simply add the SVN package and see if there's any difference.

Edit: No dice, still the same message. Will try uninstalling all Python components and reinstalling them.

Wish I knew what was going on. The unicode support is working perfectly on my end.

If other people have the same issue, we'll have to make unicode optional and disabled by default. Bit more work to maintain, but I'd hate to completely give up on it. Need to talk with PM and see if he has any ideas.

I'll go ahead and start adding the code required to make it optional. It'll be useful to have around while we work the kinks out.

Ok uninstalled and reinstalled everything Python related from scratch now (all components the same as those you listed above), and still getting the same errormsg. Not sure what else I could try now to make it work (besides reverting to a previous version ofcourse )

One sec. 751 works for you? I added unicode support in 750.

Lemme see what changed in 752, and perhaps I'll find an answer.

Edit: If 751 worked, 752 should. 752 just removed broken variable assignment.
753 is the more likely candidate as the commit that broke things for you.

Hang on a second, I have to doublecheck that 751 was the latest working version. Think it might've been 748 I used last actually. Will edit this post in a sec.

Edit: Yes indeed, was 748. Not sure why I thought it was 751 at first, possibly due to just having read the discussion in this thread about that version. Sorry for the mixup.

Alright, makes a bit more sense. 749 should work as well, btw.

Like I mentioned earlier, I'll do what I can to make the unicode support optional. That will give us some breathing room while we figure out what is causing your problem. I'll get the update with optional support out asap, so you may want to wait for it if you use CBash. If you don't use CBash, then reverting to 748/749 will be fine for now.

Will revert back to 749 for now. Thanks for looking at it.
Oh and since I'm quite clueless at the ansi/unicode stuff, I don't suppose OS or even OS language could matter in causing this? I'm running Win 7 x64, but am using the 32bit versions of Python and its components since that's what was recommended.

Edit: NM the language part I guess, forgot I wasn't using swedish win7, but english.

Yeah, OS and/or locale could affect it. Was going to ask about that next if I hadn't decided to just make unicode optional.

I'm running Win 7 x64 with 32bit Python as well, so we're still in the dark.

hmm, I'm getting the following with r755 - blerg, forgot to delete cbash.dll and use the new one


getting this with r755 now

Traceback (most recent call last):  File "D:\games\oblivion\Mopy\basher.py", line 5083, in Execute    patchFile.buildPatch(SubProgress(progress,0.1,0.9)) #try to speed this up!  File "D:\games\oblivion\Mopy\bosh.py", line 16892, in buildPatch    patcher(modFile, record, bashTags)  File "D:\games\oblivion\Mopy\bosh.py", line 30198, in apply    entryRecords = ObCollection.LookupRecords(entryId)  File "D:\games\oblivion\Mopy\cint.py", line 6123, in LookupRecords    return [RecordType(self._CollectionID, cModIDs[x], RecordID, 0, 0) for x in range(1, cModIDs[0] + 1)]TypeError: 'NoneType' object is not callable