Took much longer to get to a working stopping point, but...v0.3a is released.

Status Update:

• All Oblivion record types are supported.
  
• LAND record fields can be accessed in two ways:
  
  • Raw: each field can be directly accessed, completely uninterpreted by CBash
    
  • Interpreted: each field can be accessed through Position[][], which calculates height, provides easier access of associated normals, colors, and alpha layers. It supports setting these values as well, and (untested) will automatically update the underlaying heightmap including the heightmaps of the surrounding LAND records as needed. One remaining limitation is that positions where the quadrants overlap won't report all of the alpha layers that could apply; it returns the first one found, not all of them. These others may be accessed through raw access.
  
  
• Threading has been enabled for mod loading. This reduces load times by over a second on my computer with a Core 2 Duo.

There are other improvements scattered throughout the code, but those are the highlights.

As a result of spending so much time on the LAND records, I'm confident that I'll be able to support merging heightmaps when I add mod merging support. The result may not necessarily be pretty, but it should be better than nothing. Also, I'll be able to generate reports on possible floating / embedded objects where a placed object / npc / creature is above or below the land surface. They won't be definitive since I can't account for the height of the placed reference, nor for references on top of each other (stacked rocks, forts, etc), but they might still be useful.

I won't have much time to code for ~1 month (MCAT, and research conference / vacation all in April), so I've decided the next releases will be v0.3.1 - v0.3.xx in order to flesh out the current code. They won't provide any major new functionality, but they will reduce memory usage, speed up execution, and make sure that all existing functions work as they should.

After I get back from the trip, I'll go back to the scheduled road map and work on FO3 support.

Well, I've been back for a week, and am still plugging away at this. I've decided to switch the roadmap around some. Instead of doing FO3->Beta->Integration, I'm going to do Integration->Beta->FO3. So, right now I'm working on getting CBash integrated with Bash, and then there will be a beta release. After the beta release, I'll work on adding FO3 support while I wait on feedback and fix any bugs that come up. This should make Oblivion players happy since they'll get the new toy a bit sooner than originally planned :hubbahubba:

Status Update:
CBash has a new home at https://sourceforge.net/projects/cbash/.

Nice. It isn't exactly clear to me after reading things over - are you planning to have a specific function included for automatically cleaning dirty mods? (identical to master+undelete/disable)

For compressed records, since it didn't look like anyone commented yet, I would lean toward maintaining compression only on those records that already have it. So far as I've ever seen, that would be NPC_, LAND, and PGRD.

Also, what's a BSGN record? I can't recall having seen one before.

Hooray!


The birth sign record, I presume. But yeah, not many mods tinker with those.

In a general sense, it was already planned in that I was going to go through TES4Edit and replicating most any function that could reasonably be used via script. I've explicitly added it to the list. It'll probably make an appearance as a both bashed patch option, and a right-click context menu action.


Heh, that's actually what I was going to spend time today implementing. Good timing.

I'll be going back and adding support for writing compressed records. If the record was originally compressed, it will be written compressed unless the IsCompressed flag is changed. Those three record types (and probably ROADs as well, gotta double-check) will have that flag enabled by default.


As shadeMe said, it's the birthsign record. The only mods that tend to mess with them are the magicka overhauls.

I figured it would be a good idea to host CBash somewhere other than my local storage. After seeing what nearly happened to NifSE... bliviongate:

Awesome work!
I look forward to the FO3 support.
Possibly, I may be able to help you. (I'm not so good at Python, but understand C++ a little )

Cheers.

Good news of the day. I'm slowly beginning to integrate CBash with Bash. So here's http://www.tesnexus.com/downloads/file.php?id=30154 :celebrate:

This marks a major change in how Bash works and will need heavy testing, so I'm only going to convert one Bash function at a time before committing the change to Bash's SVN. Each converted function will use CBash if it is present, and use Bash's existing code if CBash isn't installed. This dual support will only last while CBash is in testing so that if something odd occurs Bash can be reverted to normal behavior by deleting or renaming CBash.dll. This also means that Bash can be updated and released as normal during the conversion process, and only those that actively download CBash will see any changes. When CBash has been fully integrated, it will become a required part of Bash and much of Bash's code will be trimmed.

The first functions that I will convert are based off of the right-click menu. These include the various Export/Imports, Add Master, Copy to Esm/p, Decompile all, etc.

The very last function that I will convert is the building of the bashed patch. I know that this is what many people are looking forward to, but it is also the most complex. I need to be sure that everything else works before I delve into that particular monstrosity.

I will only add new functions to Bash/CBash (Cleaning dirty mods, mod merging, etc) after every existing function is converted and the integration is complete.

Every time Bash undergoes a release during this process, I will post in this thread which functions CBash currently affects. Bash's releases will NOT be based on CBash's integration progress, so there may be anywhere from zero to many functions that need public testing with each release. Please test the functions that I post both with and without CBash, and give me feedback.

p.s. valda, I'm sure I'll have questions for you regarding FO3 when I get to that. Thank you for offering the help.

v0.4.1a is http://www.tesnexus.com/downloads/file.php?id=30154. This DLL version is already included with Bash 285 as "Rename_CBash.dll", so you do not need to download it unless you want the source. It just fixes various bugs I found while converting functions.

Speaking of which, here's the list of affected functions:

• Export/Import EditorID
  
  • Now handles CELL,WRLD,ACHR,ACRE,REFR records as well.
  
  
• Export Actor Factions
  
  • Import is used in the bashed patch, so hasn't been converted yet. There is a bug in Bash 285 if Import Factions is used in the Bashed patch while CBash is enabled.
  
  
• Export/Import Names
  
  • Now handles DIAL/CELL/REFR/WRLD as well.
  
  
• Export/Import NPC Levels
  
  • Supported.
  
  
• Export/Import Scripts
  
  • It works, but it has a quirk. For every script that is imported, a backup of the mod will be made. If you import 110 scripts, you'll end up with 110 backups.

Each function is significantly faster than Bash's original code.

A note about backups and temporary files. Whenever CBash saves a mod, it first writes to a temporary file in the Data directory. If it is successful, it then renames the original file by adding ".bak.TIMESTAMP" to its file name. An example of the TIMESTAMP is "2010_06_01_02_28_37" for June 1, 2010 at 2:28:37 am. The naming is very similar to TES4Edit's backup system. It then renames the temporary file to the original name of the mod. If CBash saves multiple files in a short time span, you may find that the TIMESTAMP on the backups are set to a time in the near future. CBash will add a minute to the TIMESTAMP as need in order to keep from renaming the backups to the same name,

If CBash has a problem writing the temporary file, it tries to delete the temporary file and leaves the original mod alone. If the problem is severe enough, CBash may crash entirely and leave the temporary file behind. You can identify these temporary files by looking for a file with a random name that starts with the letter x and no extension (such as "xsa2bf"), and they're safe to delete.

If CBash has a problem renaming the original file (such as it's open in TES4Edit), it leaves the original file alone and renames the temporary file to the original name and adds ".new.TIMESTAMP". So, if you tried to save Oblivion.esm, but had it open in TES4Edit (or any other application that locks the file), the saved file would be named "Oblivion.esm.new.2010_06_01_02_28_37".

For now, Bash does NOT notify you when these problems occur. You'll have to look in the Data directory to cleanup any loose temporary files, and to see if the file was saved with the ".new.DATESTAMP" suffix. You'll also have to go into the Data directory to clean up any backups.

Thank you for this! :tops:

Me too: thanks for this!

But I've got a problem with it. I'm running a very special configuration, as my game system is Win2003 64bit. Wrye bash didn't start with CBash, so I tried running your test script. It ends like this:

Traceback (most recent call last):  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\Test.py", line 1, in     from CBashInterface import *  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\CBashInterface.py", line 7, in     CBash = CDLL("CBash.dll")  File "C:\Python26\lib\ctypes\__init__.py", line 353, in __init__    self._handle = _dlopen(self._name, mode)WindowsError: [Error 14001] This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem

Python 2.6 is 32bit version, Wrye bash and all of it's functions runs fine without problems.

Got a WinXP system too, not for gaming but with python, and there your program runs without errors.

Any idea why it doesn't like Win2003/64 ?

Offhand, I have no idea. I use Win7 x64 myself, so it must be something with Win2003, installed libraries, or your python install. The publicly released versions of CBash were accidentally set to dynamically link its libraries. I've fixed that a while ago, and set it to statically link so that it isn't dependent on what you happen to have installed on your computer. Whenever the next public release is made (no ETA, but probably sometime around the time Bash makes it's next update), hopefully it will fix your problem. If not, let me know and I'll look into it more.

Edit: A quick http://www.velocityreviews.com/forums/t711804-ctypes-error.html shows that this is likely the problem. So it should be fixed with the next release.

Aaargh!!! :banghead: Already read about this problem, and on the XP system used the static linked dll from your Sourceforge project. I was sure that I copied it to the game system, but must have mixed it up somehow. Looked on it with 'Depends.exe' and the unresolved VC dlls still showed up. Replaced it, and now it's loading fine. Thanks again, gonna play around with it now .

Well, as long as you're grabbing it from SourceForge, you may want to get the dll from this latest commit (rev 41, just finished). Might as well play with the latest build

edit: this was my fault. if you're getting errors like this, check your installation!

Hi Waruddar,

I seem to be getting an intermittent crash from CBash when I use it from WB (svn rev 476). Sometimes it crashes the entire Python process, sometimes it works, but I get strange errors afterwards (can't find icons, for example), and sometimes I get backtraces like:

Traceback (most recent call last):
File "C:\oblivion\Mopy\basher.py", line 4884, in Execute
patchFile.initData(SubProgress(progress,0,0.1)) #try to speed this up!
File "C:\oblivion\Mopy\bosh.py", line 14267, in initData
patcher.initData(SubProgress(progress,index))
File "C:\oblivion\Mopy\bosh.py", line 16480, in initData
fullNames.readFromMod(srcInfo)
File "C:\oblivion\Mopy\bosh.py", line 12194, in readFromMod
for type,block in modFile.aggregates.iteritems():
File "C:\oblivion\Mopy\cint.py", line 17258, in aggregates
("CELL", self.CELLS),("ACHR", self.ACHRS),("ACRE", self.ACRES),("REFR", self.REFRS),
File "C:\oblivion\Mopy\cint.py", line 17190, in REFRS
refrs = refrs + cell.REFR
File "C:\oblivion\Mopy\cint.py", line 10064, in REFR
numSubRecords = CBash.GetFIDFieldArraySize(self._CollectionIndex, self._ModName, self._recordID, 38)
WindowsError: exception: access violation reading 0x02094A10

or

Traceback (most recent call last):
File "C:\oblivion\Mopy\basher.py", line 4884, in Execute
patchFile.initData(SubProgress(progress,0,0.1)) #try to speed this up!
File "C:\oblivion\Mopy\bosh.py", line 14267, in initData
patcher.initData(SubProgress(progress,index))
File "C:\oblivion\Mopy\bosh.py", line 16480, in initData
fullNames.readFromMod(srcInfo)
File "C:\oblivion\Mopy\bosh.py", line 12204, in readFromMod
record.UnloadRecord()
AttributeError: 'GMSTRecord' object has no attribute 'UnloadRecord'

another note: when building a patch with just import names, the progress bar does not move at all while building the patch

First, please be sure that you're using the correct dll. You may have CBash.dll from an older revision, and Rename_CBash.dll from the newer one. I've had other reports where that was the case.

Also, please try installing the newest revision (478). It looks like you're inadvertently using the wrong files...the line numbers from those backtraces are way off from what they should be for revision 476 (your trace shows the line "fullNames.readFromMod(srcInfo)" at 16480, and it's at line 18186 in rev 476). As well, GMSTRecord has had the UnloadRecord attribute since revision 465.

All in all, it looks like your install needs to be double-checked before I can help.

Double checked. You were certainly right about things being out of sync. I synchronized with svn revision 478. I definitely see a difference! It looks like it was on track to finish in 1 minute instead of its usual pace of 15-20 minutes. CBash kicks ass!

I did still get an error, though:

Traceback (most recent call last):
File "C:\oblivion\Mopy\basher.py", line 4942, in Execute
patchFile.buildPatch(SubProgress(progress,0.1,0.9)) #try to speed this up!
File "C:\oblivion\Mopy\bosh.py", line 14941, in buildPatch
applyPatchers = [patcher.apply for patcher in sorted(patchers,key=attrgetter('editOrder')) if hasattr(patcher,'apply') and patcher.iiMode]
AttributeError: CBash_GmstTweak instance has no attribute 'iiMode'

Doh!

Will be fixed in the next revision Thanks!

thanks : ) Also, I notice that a few of the patchers are missing from the bashed patch dialog, like "Tweak Names". Is this just one of the ones that isn't done yet?

Yeah, any functions that don't work with CBash are disabled while CBash is in use. I'm actually finishing up Tweak Names right now.

svn 480:

Traceback (most recent call last):
File "C:\oblivion\Mopy\basher.py", line 4942, in Execute
patchFile.buildPatch(SubProgress(progress,0.1,0.9)) #try to speed this up!
File "C:\oblivion\Mopy\bosh.py", line 14984, in buildPatch
patcher(self)
File "C:\oblivion\Mopy\bosh.py", line 23979, in finishPatch
book = getBook(patchFile, objectId)
File "C:\oblivion\Mopy\bosh.py", line 23974, in getBook
book.text = '