MAKE_BIFF

[Miloch]

From the WeiDU doc:

MAKE_BIFF name-of-biff BEGIN directory-file-regexp list END

Create a biff Data/name-of-biff.bif from the files that can be matched by directory-file-regexp. The chitin.key file is restored as a normal file, and reloaded whenever the component is installed or uninstalled (which means that its contents will be available exactly when the biff exists), while the .bif file itself is NOT deleted on uninstall.

Could've fooled the crap out of me.

Don't get me wrong - I want it deleted. But my uninstall batch file was complaining when trying to delete it because it wasn't there (and yes, I checked it was created on install).

(Now add tisunpack and oggdec to WeiDU and we won't need batch files .)

[the bigg]

Could've fooled the crap out of me.

Don't get me wrong - I want it deleted. But my uninstall batch file was complaining when trying to delete it because it wasn't there (and yes, I checked it was created on install).

Life is too short to keep the readme synced with the code.

(Now add tisunpack and oggdec to WeiDU and we won't need batch files .)

Last time I tried, oggdec started requiring that 300000 different libraries be built in, and tisunpack almost worked but suffered by an off-by-one and popped up a million message boxes warning me of errors. I'll take a look and see if I can get them to work this time.

[the bigg]

Incidentally, is there any reasons why you're biffing files yourself rather than letting gen_biff do it at the end?

[Kulyok]

MAKE_BIFF, not war.

(sorry, couldn't resist)

[Miloch]

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.

[Miloch]

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

[the bigg]

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.

[the bigg]

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

[Miloch]

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

[the bigg]

Will code SOURCE_BIFF and IS_COMPRESSED_BIFF, then.

[the bigg]

Done, uploading as beta.

[Miloch]

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?

[the bigg]

I think the DECOMPRESS_* commands will fail if the biff is over 16 MB, so UNCOMPRESS would still be needed.

[Miloch]

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.

[the bigg]

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.

[Miloch]

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

[the bigg]

Cheers. Do backups work correctly? Does it work on BG2-like BIFC files?

[Miloch]

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.

[the bigg]

Thank you. I need to run some tests on the latest L1NPC beta, then I'm ready to push 224.