Jump to content

How does biffing affect modding?


jastey

Recommended Posts

I am very much hoping for a tutorial here. Biffing is scaring me - as a modder, it influences a lot of things that were no problem without it. But, as Megamodifications get more popular, more and more players have biffed overrides. So:

 

-no quick re-install of updated mods to eliminate a bug

 

-no re-use of game ressources, e.g. for areas: no use of game ambients: copying them into the override isn't enough any more

 

 

My questions:

-What do I do if I have a biffed modded game and want to update one of the mods - not possible?

 

-Can I use an existing tis (using the original name and all) for a custom area (with custom name) or how would I use an exsiting tis, do I have to create a custom tis by COPY_EXISTING?

 

And everything else that is affected by biffing.

Link to comment

chitin.key has an index of biffs and which files are in them. However, any file in the biffs is ignored if the game finds the same file in the override folder. (This is why generalized biffing speeds up the game--the game 'knows' where every file is thanks to chitin.key and, since it's empty, the override checks are faster.) Whether it's the original biffs that the game ships with, or player-created biffs, this is the model and neither will affect how your mod works.

 

If something gets tossed into a biff, it doesn't make it inaccessible to mods. E.g. for RE's duplicate NORH, whether the tileset and ambients are in the override or in a biff makes zero difference.

 

This is really the only issue:

 

-no quick re-install of updated mods to eliminate a bug

 

Generalized biffing is just another mod, albeit one that takes a really long time to install. If you update RE underneath it, WeiDU will uninstall it and the rest of the stack to get to RE, and then you'll have to wait for the stack and generalized biffing again.

Link to comment

And having posted that, I'm sure someone will come along to point out all the ways that I'm wrong. (There are some differences between biffed and unbiffed files, but none that should affect the average modder--header-less tilesets work when biffed, but crash if left in the override. Or vice-versa, I can never remember.)

Link to comment

The issue with area ambients and such can be solved by decompressing the original biff (with DECOMPRESS_BIFF). The game's only got a problem with area-files being in different places if one of those places is a compressed biff.

Link to comment
[...] The game's only got a problem with area-files being in different places if one of those places is a compressed biff.

Compressed biff = biff? Or are there compressed and non-compressed biffs?

Link to comment

Compressed biff = biff? Or are there compressed and non-compressed biffs?

There are two kinds of compressed biffs and one kind of uncompressed biffs. Offhand I don't know if there's a mod tool that informs you what kind of biff you're dealing with. You can find out by reading the file signature (the first 8 bytes of the file), but it's perhaps a bit technical. DECOMPRESS_BIFF will decompress compressed biffs and leave uncompressed biffs alone.

Link to comment

Bear with me, but I am not sure I got it.

 

So, biffing (uncompressed) wouldn't be a problem for an area, not for used (originally named) ambients, not for (unchanged) tis? it is only the compressed bif that make the problem? So, if I want to use game .tis (references to unchanged game tis), all I have to do is DECOMPRESS_BIFF of the original game's area, and my area is stable and working, regardless of whether the player installs more mods, biffs the override, or loads saves?

Link to comment

For area ambients, I remember that some are biffed in AMBSound.bif and others, in biffs with respective areas. IIRC (from my own experience), the former are safe to refer to in new areas. For the latter though, trying to use them will cause the game to crash (unless you extract them into the Override, but that's not what we want here) So it seems to me, the safe way to use original area sounds is to copy them with your own name and biff with your area. No idea if this compressed/uncompressed thing affects anything in this case, though

Bear with me if my post has nothing to do with your questions, pray. I too am just starting to learn this biffing thingy

Link to comment
There are two kinds of compressed biffs and one kind of uncompressed biffs [...]

Aside from saving memory, -- which I assume is what compressing biffs gives (and which is hardly important for modern computers) -- are there any advantages/disadvantages in favor of a certain type of biffing? Which type is easier for IE to handle?

Link to comment

It was said that DECOMPRESS_BIFF is the way to go, but doesn't this put the files in the cache - that can be emptied any time the game needs to cache something else? This goes together with my above question. If I am not mistaken, you both are saying that biffing is no problem for a custom area using game resources, but it is a fact that areas crash if ambients are biffed elsewhere, so I don't understand it.

Link to comment
If I am not mistaken, you both are saying that biffing is no problem for a custom area using game resources, but it is a fact that areas crash if ambients are biffed elsewhere, so I don't understand it.

As I have said earlier, for your area you can safely use original ambients that are stored in AMBSound.bif

As for ambients biffed elsewhere, you will have to extract them, rename, and biff along with your area files (.TIS, .WED, etc) Not sure if the .ARE file has to be in the same biff (hope to learn it soon enough)

The alternative is to uncompress the biffs, if I understand correctly what Wisp says

Or am I misunderstanding your question now?

Link to comment
[...] Can I use an existing tis (using the original name and all) for a custom area (with custom name) or how would I use an exsiting tis, do I have to create a custom tis by COPY_EXISTING? [...]

(Somehow I missed this part the first time)

I guess you can refer to an original .WED which in its turn, refers to the respective .TIS. Yet it may well turn out that this depends on where it's biffed. Looks like not all .BIF files are equal in the eyes of IE

Link to comment

Thank you, _Lu, sorry for giving you the feeling that I am ignoring you.

 

With "you both" I meant Wisp and CamDawg, because right now, all I memorize from you Wisp and CamDawg, that biffing is no problem (might require DECOMPRESS_BIFF), but experience shows that areas *DO* crash and I still didn't get how these statements go together because for me, there is a contradiction. :(

 

So, I guess I didn't understand something and I would be very glad if someone would try to explain and answer my above question(s). If the answer is already stated above, I am too dumb to see it.

Link to comment

From my understanding(and I have no huge understanding of areas, can't even tell a .tis from a .wed), you're

- okay if you just want to copy an area from a game(say, my O#1600 area is a full copy of AR1600, only .are files and area scripts are different).

- you're okay if you use your custom .tis, but you need either to provide your own. wed, or, if you're using a game .wed, rename it and use a renamed reference.

 

If I'm wrong, please, correct me.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...