Lo folks,
After a clean install of bg2, tob + patch, I'd like to lump my override directory into a biff, to keep things a little cleaner, so I can see whats going on easier.
My question is, when using --make-biff, the new biff file is placed in the \data directory - how does this affect file precedence?
Is it possible to put the new biff in the override directory, to ensure it's used instead of any files in the \data directory?
When I move the biff into override by hand, weidu gives chiten.key errors.
What about if I have separate files in the override directory, would these override a biff placed in the override directory?
I guess my question boils down to: how can I put the default override directory in a new biff file, which is used in preference to any exising files, and that can be overriden by any files later added.
Hope that makes sense :-)
Cheers
/igi
ps. sorry if this isnt 100% relevant to weidu, but I am using weidu to create the biff :-)
biffing and overriding
Started by igi, Jun 13 2003 12:42 PM
14 replies to this topic
#2
japheth
-
- Member
- 317 posts
Codewalker
Posted 13 June 2003 - 01:47 PM
If you do a weidu --make-biff override and then delete eveything in your override, strange things popup when viewing files in NI.
For every file that you added from your override, there will now be two references to that file when you view any tree in NI. (For instance, if you pack up the patched ToB override, there will be two references of 25stweap.2da, two references of abclasrq.2da, etc.)
I think Wes would have to add support for overwriting of files within .bif's in order for --make-biff to work correctly for files that already exist in biffs.
(e.g. He would point the file reference that already exists in the chitin.key to the new bif.)
WinBiff does this, but it's buggy. If you create a new bif using WinBiff, it will prompt you for each file that it recognizes as already being in game. However, it doesn't match the files caselessly. (e.g. It thinks 25STWEAP.2DA and 25StWeap.2da are different because of their different cases.)
So, after you add the biff using WinBiff, you end up with a half-ass job. Some of the files are replaced correctly, while others still have two references in the .key file that are shown.
So, you'll either have to wait until Wes decides that this is a pressing issue (if you ask him nicely, he might do it
), or until Theo decides to fix WinBiff to match files caselessly.
For every file that you added from your override, there will now be two references to that file when you view any tree in NI. (For instance, if you pack up the patched ToB override, there will be two references of 25stweap.2da, two references of abclasrq.2da, etc.)
I think Wes would have to add support for overwriting of files within .bif's in order for --make-biff to work correctly for files that already exist in biffs.
(e.g. He would point the file reference that already exists in the chitin.key to the new bif.)
WinBiff does this, but it's buggy. If you create a new bif using WinBiff, it will prompt you for each file that it recognizes as already being in game. However, it doesn't match the files caselessly. (e.g. It thinks 25STWEAP.2DA and 25StWeap.2da are different because of their different cases.)
So, after you add the biff using WinBiff, you end up with a half-ass job. Some of the files are replaced correctly, while others still have two references in the .key file that are shown.
So, you'll either have to wait until Wes decides that this is a pressing issue (if you ask him nicely, he might do it
), or until Theo decides to fix WinBiff to match files caselessly.
Check out BG1Tutu.
#3
hlidskialf
-
- Modder
-
- 2510 posts
Incarnation of the Eternal Ale Warrior
Posted 13 June 2003 - 02:09 PM
Another oddity with Winbiff (not sure if it's true with weidu as well) is that the problem Japh mentioned mostly disappears if the new biff is alphabetically named higher than the files it's overwriting. What I mean is that the base rule files are in Default.bif. If you name your new rules containing .bif something like NewDeflt.bif most of the problems with read-errors subside. But if you name it AlphaRLZ.bif, your game will pick up on the originals, even though you've authorized the overwrite. Bizarre. Theo's been told, hopefully he's solved the problem for the next release.
The great wolf Fenrir gapes ever at the dwelling of the gods.
#4
japheth
-
- Member
- 317 posts
Codewalker
Posted 13 June 2003 - 02:12 PM
Oh, and if you simply can't wait for Theo to fix the case problem or for Wes to add the feature, you could write some sort of batch file that will automatically rename all files in the override to uppercase. There's probably some freeware programs out there that do this as well.
(I think there's a program called Lupas or something I used a while back to do some batch renaming.)
However, you will also have to hop on #teambg on irc.teambg.net to get WinBiff. The TBG servers are currently down.
(I think there's a program called Lupas or something I used a while back to do some batch renaming.)
However, you will also have to hop on #teambg on irc.teambg.net to get WinBiff. The TBG servers are currently down.
Check out BG1Tutu.
#5
japheth
-
- Member
- 317 posts
Codewalker
Posted 13 June 2003 - 02:18 PM
Oh yeah, one more thing. This only applies if you have ToB and the latest patch though.
If you find a renamer and find WinBiff, before you create the bif make sure you open up ar0072.tis in the override and remove the 24 byte header from the top of the file.
(You can use any hex editor to do this.)
If you don't, I'm pretty sure the .tis will fail to load after it's been biffed up.
{edit: Nevermind, WinBiff doesn't pack up .tis files very well at all. I tried adding the .tis with and without the header and both resulted in "GUI map screens" when I moved to ar0072. So, if I were you, I'd rename everything to uppercase, move ar0072.tis out of the override temporarily, make the new .bif, save the key and then move ar0072.tis back into the override.}
If you find a renamer and find WinBiff, before you create the bif make sure you open up ar0072.tis in the override and remove the 24 byte header from the top of the file.
(You can use any hex editor to do this.)
If you don't, I'm pretty sure the .tis will fail to load after it's been biffed up.
{edit: Nevermind, WinBiff doesn't pack up .tis files very well at all. I tried adding the .tis with and without the header and both resulted in "GUI map screens" when I moved to ar0072. So, if I were you, I'd rename everything to uppercase, move ar0072.tis out of the override temporarily, make the new .bif, save the key and then move ar0072.tis back into the override.}
Check out BG1Tutu.
#7
WelloBanir
-
- Member
- 11 posts
Posted 16 June 2003 - 01:27 PM
Another "solution" would be to write a batch-file which extracts all the data from the biffs into directorys (named after the biffs), replaces the buggy files with the bugfixed ones from the override folder, deletes the chitin.key or replaces it with an empty one, and finally rebuilds all the biffs and the chitin.key, while using weidu, of course.
A bit too much for one simple patch, but probably good for bigger modifications and/or patches.
A bit too much for one simple patch, but probably good for bigger modifications and/or patches.
#8
-Idobek-
-Idobek-
-
- Guest
Posted 17 June 2003 - 05:17 AM
On a related note is there a way to get WeiDU to extract files from a specific biff?
I have tried/am trying the batch file idea. Problems are (in no particular order):
1. WeiDU doesn't unpack/repack tis files so well so biffs containing them need to be avoided (one reason for the question).
2. Not all biff files in BG2 are stored in in the data folder, but WeiDU repacks there regardless (a consistancy issue mainly, plus problems with less than full install) (another reason for the question).
3. In order to make sure that no files disappear during the transfer from override to biff you really need to take it a biff at a time (primary reason for the question), do all biffs at once (problem 1. comes into play as well as a whole host of others), or reorganise the biffs by file type (problem 1. again plus problem 2., compatibily with mods problems- ToB detection checks - although this is easily worked around).
However, if WieDU can extract from a specific biff then progress can be made, taking things a biff at a time avoiding biffs with tis files.
I have tried/am trying the batch file idea. Problems are (in no particular order):
1. WeiDU doesn't unpack/repack tis files so well so biffs containing them need to be avoided (one reason for the question).
2. Not all biff files in BG2 are stored in in the data folder, but WeiDU repacks there regardless (a consistancy issue mainly, plus problems with less than full install) (another reason for the question).
3. In order to make sure that no files disappear during the transfer from override to biff you really need to take it a biff at a time (primary reason for the question), do all biffs at once (problem 1. comes into play as well as a whole host of others), or reorganise the biffs by file type (problem 1. again plus problem 2., compatibily with mods problems- ToB detection checks - although this is easily worked around).
However, if WieDU can extract from a specific biff then progress can be made, taking things a biff at a time avoiding biffs with tis files.
#9
WelloBanir
-
- Member
- 11 posts
Posted 18 June 2003 - 06:14 AM
The problem with the tis isn't probably one, because if you extract them from a biff an repack them, i think there is no header change in the whole process. Tell me if i'm mistaken.
Can't weidu patch the ar0072.tis? Give an offset and a value, and weidu does the rest.
Maybe before extracting, weidu should make lists of all the content of all biffs. Isn't there an example in the weidu package, for dialogues? These lists could be used for the automatic extraction AND repacking.
It is no problem that everything is being put into the data folder, as long as the new biffs' names match those iin that one 2DA, where the caching is organized, arealink.2da or another one.
@Idobek: Keep batching(i mean batch file writing), such a batch file would be good for various tasks, and should be included into the weidu package, besides an empty chitin.key.
Can't weidu patch the ar0072.tis? Give an offset and a value, and weidu does the rest.
Maybe before extracting, weidu should make lists of all the content of all biffs. Isn't there an example in the weidu package, for dialogues? These lists could be used for the automatic extraction AND repacking.
It is no problem that everything is being put into the data folder, as long as the new biffs' names match those iin that one 2DA, where the caching is organized, arealink.2da or another one.
@Idobek: Keep batching(i mean batch file writing), such a batch file would be good for various tasks, and should be included into the weidu package, besides an empty chitin.key.
#10
-Idobek-
-Idobek-
-
- Guest
Posted 18 June 2003 - 07:58 AM
@WelloBanir: As far a I know you are right about tis file headers. I am just get errors when extrating tis files - so I am avoiding them at the mo. I am also working with BG1 (less files to worry about) so that could be the problem. Thank you for pointing out the arealink.2da issue - that would diffinately caused me a headache.
--biff should be the command used to list the contents of a specific biff but I can't make it do a damned thing! (Possible bug?) However with the combined power of WinBiff, WeiDU and DOS I'm getting around the individual program limitations (I'm extracting files via a tp2 then running the batch from there). It won't be universal though - I'm sticking to replacing the files in the biffs with their duplicates in the override (keeping the same biffs) not adding anything new, and their will be separate batchs for BG1 & BG2 (no surprise there). I'd like to complately restructure the biffs & the chitin.key but I think sticking with the original file index is better for compatibilty with mods. Also the larger batch file can eaily broken down in to smaller files for individual biffs.
The code is a bit clumsy but also easily understandable (it has to be if I'm writing it). I just hope it doesn't freeze peoples' computers - there is a lost of disk activity. Oh - another reason for avoiding extraction of tis files and directory restructuring - at one point (the switch over for tp2 to batch file) all biffs being updated are sitting extracted in their own personal folders - the potential HD eater.
I'll keep you posted. Any advice/warnings is more then welcome.
--biff should be the command used to list the contents of a specific biff but I can't make it do a damned thing! (Possible bug?) However with the combined power of WinBiff, WeiDU and DOS I'm getting around the individual program limitations (I'm extracting files via a tp2 then running the batch from there). It won't be universal though - I'm sticking to replacing the files in the biffs with their duplicates in the override (keeping the same biffs) not adding anything new, and their will be separate batchs for BG1 & BG2 (no surprise there). I'd like to complately restructure the biffs & the chitin.key but I think sticking with the original file index is better for compatibilty with mods. Also the larger batch file can eaily broken down in to smaller files for individual biffs.
The code is a bit clumsy but also easily understandable (it has to be if I'm writing it). I just hope it doesn't freeze peoples' computers - there is a lost of disk activity. Oh - another reason for avoiding extraction of tis files and directory restructuring - at one point (the switch over for tp2 to batch file) all biffs being updated are sitting extracted in their own personal folders - the potential HD eater.
I'll keep you posted. Any advice/warnings is more then welcome.
#11
Rassadihn
-
- Member
- 80 posts
Eater of Avatars
Posted 20 June 2003 - 01:51 AM
No, WeiDU is just picky about how you specify the biff. You *must* use the filenames from CHITIN.KEY (those from "weidu --list-biffs"): filenames not in CHITIN.KEY will not work. For example, "weidu --biff data\dialog.bif" will work from any directory, but "weidu --biff .\test.bif" will not work even if there is a test.bif in the local directory. It ought to give an error in this case, but it fails silently. WeiDU wasn't meant to be a generic BIFF tool.--biff should be the command used to list the contents of a specific biff but I can't make it do a damned thing! (Possible bug?)
CHITIN.KEY is a maintenance nightmare, and a poor solution to the problem of having BIFFs scattered across CDs. The designers dropped the ball a bit on this one.
#12
WelloBanir
-
- Member
- 11 posts
Posted 20 June 2003 - 06:18 AM
@Idobek:If there are errors with the extraction of tis files, report them to Mr WeiDu, Westley Weimer. Bugfixing is done quickly most of the time. As far as i know he also owns bg1 no, so he may be able to reproduce those errors himself.
While doing this, you might also ask him about a feature for the automatic patching of tis files while being biffed. This is probably useful for bg1, or bg2 or iwd1/2 and/or ps:t, i don't know which one of those have this offset problem.
There is another 2da which may cause problems when restructuring the biff content. I guess it is arealins.2da.
Oh, it is just for bg2.
I won't agree with you, Rassadihn. Maybe the chitin.key is annoying, and the loss of it may result in a complete reinstall of the game and all mods(okay, backup is an old idea), but it is a necessary and useful file. Maybe its structure is not perfect, but the maintenance of files with some thousand independent data sets is always a bit hard.
Maybe this thread leads to some sort of optimization of the usage of this file.
While doing this, you might also ask him about a feature for the automatic patching of tis files while being biffed. This is probably useful for bg1, or bg2 or iwd1/2 and/or ps:t, i don't know which one of those have this offset problem.
There is another 2da which may cause problems when restructuring the biff content. I guess it is arealins.2da.
Oh, it is just for bg2.
I won't agree with you, Rassadihn. Maybe the chitin.key is annoying, and the loss of it may result in a complete reinstall of the game and all mods(okay, backup is an old idea), but it is a necessary and useful file. Maybe its structure is not perfect, but the maintenance of files with some thousand independent data sets is always a bit hard.
Maybe this thread leads to some sort of optimization of the usage of this file.
#13
-Idobek-
-Idobek-
-
- Guest
Posted 25 June 2003 - 01:11 PM
@Rassadihn: Thanks for the --biff tip: I was using data/dialog.bif. It never occured to me to use '\' WeiDU normally hates them.
@WelloBanir: I'll try to start keeping a record of any extraction problems and if there turns out to be a pattern I'll pass it on. However, I've found a neat way of avoiding the areaxxxx.bif files (where most of the tis files are kept) so if there are problems if won't affect the program. Also, it seems to me that very few mods and patches actually change a lot of tis, wed, mos or area bmp files. The really big mods do, but they tend not to use the override and this batch isn't really intended for them anyway. So my thought is that to avoided screwing around unnecessarily with biffs I'm unlikely going to change, I'll just ignore them. It won't be hard to put them back in the picture if required.
Anyway things are progressing, even if in a bit of a one step forward two steps back kind of way. I might look at releasing batch files to repack specific biffs (items for example) that are used a lot, as well as a big all purpose one. The individual ones would be easy to do I think, especially if I just send out the required file fragments and file lists instead of generating them in the batch.
@WelloBanir: I'll try to start keeping a record of any extraction problems and if there turns out to be a pattern I'll pass it on. However, I've found a neat way of avoiding the areaxxxx.bif files (where most of the tis files are kept) so if there are problems if won't affect the program. Also, it seems to me that very few mods and patches actually change a lot of tis, wed, mos or area bmp files. The really big mods do, but they tend not to use the override and this batch isn't really intended for them anyway. So my thought is that to avoided screwing around unnecessarily with biffs I'm unlikely going to change, I'll just ignore them. It won't be hard to put them back in the picture if required.
Anyway things are progressing, even if in a bit of a one step forward two steps back kind of way. I might look at releasing batch files to repack specific biffs (items for example) that are used a lot, as well as a big all purpose one. The individual ones would be easy to do I think, especially if I just send out the required file fragments and file lists instead of generating them in the batch.
#14
Idobek
-
- Member
- 429 posts
Pocket Plane Gibberling
Posted 27 June 2003 - 11:38 AM
Things are progressing very quickly. Thanks to Japheth the batch file should be compatible with BG1 and BG2 (and IWD1&2, I guess). I'm basically in refinement stages now so I am putting out a call for beta testers: I you're gambler and want to put up your chitin.key and data directory in to the pot drop me a line at:
idobek@yahoo.co.uk
Subject: ReBiffer Testing
I need testers for all IE games and, this being a batch file, all Windows platforms (I have XP Pro).
idobek@yahoo.co.uk
Subject: ReBiffer Testing
I need testers for all IE games and, this being a batch file, all Windows platforms (I have XP Pro).
#15
Idobek
-
- Member
- 429 posts
Pocket Plane Gibberling
Posted 03 July 2003 - 03:13 PM
Well, this little batch file is almost finished. I'm just ironing out the wrinkles. I wrote most of the ReadMe today, and hopefully a beta version will be out within the week.
Here's a run down of what if does:
1. Makes a list of all the biffs in the data directory (the user can provide a list if they wish).
2. Makes a list of the files in each biff and compares that against the Override directory.
3. If a match is found it extracts the files from the biffs into a directory named after the biff and moves the matching files from the Override directory into the new directory (any replaced files are backed up).
4. Deletes the old biff.
Steps 2-4 are done biff by biff the batch then pauses and asks you to run NI's 'Keyfile cleanup' tool.
5. Makes new biffs and places them in the data directory.
6. Creates UnInstaller.
Any files specified in LEAVE_OVERRIDE.TXT are ignored by the program. You can add to this list at your pleasure.
Anyone have any thoughts or requests?
Can anyone tell me if the TITLE command works in Win9x?
Here's a run down of what if does:
1. Makes a list of all the biffs in the data directory (the user can provide a list if they wish).
2. Makes a list of the files in each biff and compares that against the Override directory.
3. If a match is found it extracts the files from the biffs into a directory named after the biff and moves the matching files from the Override directory into the new directory (any replaced files are backed up).
4. Deletes the old biff.
Steps 2-4 are done biff by biff the batch then pauses and asks you to run NI's 'Keyfile cleanup' tool.
5. Makes new biffs and places them in the data directory.
6. Creates UnInstaller.
Any files specified in LEAVE_OVERRIDE.TXT are ignored by the program. You can add to this list at your pleasure.
Anyone have any thoughts or requests?
Can anyone tell me if the TITLE command works in Win9x?
