Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: the bigg
« on: November 06, 2010, 08:52:50 PM »

Thank you. I need to run some tests on the latest L1NPC beta, then I'm ready to push 224.
Posted by: Miloch
« on: November 06, 2010, 08:49:03 PM »

Yes on both accounts. Tested both install and uninstall/restore on BG2 and PST.

Very easy to test btw - I just used a single tp2 line e.g. DECOMPRESS_BIFF ~CD2/Data/AREA000B.bif~ and then looked at the biff resources in DLTCEP to make sure they didn't get hosed.
Posted by: the bigg
« on: November 06, 2010, 05:33:39 AM »

Cheers. Do backups work correctly? Does it work on BG2-like BIFC files?
Posted by: Miloch
« on: November 06, 2010, 12:12:54 AM »

It appears to work uncompressing a PS:T .cbf file (not only that but actually makes DLTCEP usable with the uncompressed biff, as it wasn't before).
Posted by: the bigg
« on: November 03, 2010, 04:47:10 AM »

Up as beta in the usual 15 minutes (didn't test, only checked that it compiles).

DECOMPRESS_BIFF ~data/xyz.bif~ ~data/abc.cbf~ EVALUATE_BUFFER ~%impossible%stack%of%variables%~

data/xyz.bif will be overwritten by the decompressed version (and restored properly on uninstall). data/abc.cbf will be moved from data/ to mymod/backup/x/ (and restored as per MOVE action); data/abc.bif will be created with the new content (and deleted on uninstall). No changes to chitin.key.
Posted by: Miloch
« on: November 01, 2010, 04:37:48 AM »

I think the DECOMPRESS_* commands will fail if the biff is over 16 MB, so UNCOMPRESS would still be needed.
Yeah, if fails with a memory error on a COPY. So UNCOMPRESS_BIFF never made it in? Specifically, I need to uncompress PST .cbf files, which apparently follow this format.
Posted by: the bigg
« on: September 19, 2010, 06:45:50 PM »

I think the DECOMPRESS_* commands will fail if the biff is over 16 MB, so UNCOMPRESS would still be needed.
Posted by: Miloch
« on: September 19, 2010, 06:38:14 PM »

Done, uploading as beta.
Cheers. Now that I think of it, UNCOMPRESS_BIFF might be useful too. Is it already there, or can it already be done using one of the DECOMPRESS* commands?
Posted by: the bigg
« on: September 19, 2010, 07:42:07 AM »

Done, uploading as beta.
Posted by: the bigg
« on: September 18, 2010, 11:06:51 AM »

Will code SOURCE_BIFF and IS_COMPRESSED_BIFF, then.
Posted by: Miloch
« on: September 18, 2010, 10:38:40 AM »

That said, a sleeker solution IMHO would be UNCOMPRESS_BIFF ~data\whatever.bif~.
I don't know if it's the best solution as far as saving disk space, since it's only an issue with ambients, and then only certain ones, so not everything in the biff needs to be uncompressed necessarily.
It appears that there is a `FILE_IS_IN_COMPRESSED_BIF file' undocumented tp2 feature - is that enough for your purposes?
It should be sufficient for the current purpose, though it might also help in the future to have something like a SOURCE_BIFF that returns the file's actual biff (or null if it isn't biffed).
Posted by: the bigg
« on: September 18, 2010, 06:46:18 AM »

It appears that there is a `FILE_IS_IN_COMPRESSED_BIF file' undocumented tp2 feature - is that enough for your purposes?
Current behavior:
file is not in a biff: fail installation (should be changed to returning false, I guess)
file is in a cbif: return true even if there's a copy in the override
file is in a standard bif: return false
Posted by: the bigg
« on: September 18, 2010, 04:42:45 AM »

Sure. That said, a sleeker solution IMHO would be UNCOMPRESS_BIFF ~data\whatever.bif~. Mods don't add cbifs, thus the fixpack (or another early mod) can decompress cbifs and permanently fix the issue (even on subsequent partial installs). Of course, if you prefer the GET_CONTAINER_BIFF and IS_BIFF_COMPRESSED approach, I'll code these instead.
Posted by: Miloch
« on: September 18, 2010, 02:58:55 AM »

Another biff question (though not related to MAKE_BIFF). I want to determine which biff a resource is in (and furthermore whether that biff is compressed, though I guess I can do that by reading the .bif file signature). NI displays this in its status bar when you click on a resource. Is there an easy way to do this via WeiDU without extreme hackery? I experimented with the various *biff command line options but none of them seemed to give the results I wanted (and indeed, some produced incomplete or garbled output).

The goal is to avoid commonly-occurring nonsense like this (check if the .wav if in a compressed biff that the area is not in - if so: copy it to another resource name). I have code that does this on a single-mod basis, but when I scanned a BWP install, it returned several hundred mod area ambients that may or may not be problematic (hence the need to check whether they're in compressed biffs - many are in ambsound.bif which I believe is not compressed).
Posted by: Miloch
« on: September 16, 2010, 02:50:41 PM »

Incidentally, is there any reasons why you're biffing files yourself rather than letting gen_biff do it at the end?
It's just 1 biff for the mod's movies that never get copied to the override - not biffing the other files.