Jump to content


Photo

Multiple Install Notes


  • Please log in to reply
28 replies to this topic

#21 FredSRichardson

FredSRichardson

    WeiDU Meddler

  • Member
  • 258 posts

Posted 04 March 2004 - 09:19 AM

BUG ALERT

Just in case anyone has tried using the chitinHD02CD1.exe program, I thought I'd issue a bug warning. I've found that moving to the area AR1403.ARE will cause the game to ask you to insert the "Baldur's Gate CD 1" into drive D.

There's some file mapping I haven't gotten quite right, but I'm not sure what it is. It could be that some of the entries in the chitin.key aren't exactly correct, and the game just searches "data\" for anything it can't find. Since I've moved everything under "data\" to "CD1\data\" this would cause a problem.

I'll post here as soon as I fix the bug with a link to a new version of the program.

Which brings me to another point, the current version of chitinHD02CD1.exe doesn't have any version information. I'm going to make it so that running the command with no arguments gives the version along with the usage.
I gotta get rid of this friggin idiotic signature...

#22 FredSRichardson

FredSRichardson

    WeiDU Meddler

  • Member
  • 258 posts

Posted 06 March 2004 - 06:46 PM

OK, I did a bunch of tooling around, and finally looked at the chitin.key file generated for BG1Tutu, and this was enlightening.

I can solve this issue without moving files out from under data. The trick is to make entries that reference a relative path like:

..\BGOrig\data\SomeBif.bif

So one can augment all the entries in the chitin.key file to use relative paths and this should work.

While trying to figure this out, I noticed that often a chitin entry will indicate several different directories to search, and a bif with the same name will exist in several of these dirs. I thought this meant that all the bifs need to be searched to find a given file. But actually I think that these are identical bifs (so that you don't have to swap CD's all the time). This means that more space can be saved by removing the duplicate files and rebuilding the chitin.key file to access the remaining unique file with a relative path.

Anyway, I'll have to test this stuff out a bit more to see how well it works.

EDIT: Actually, you can probably only save around 60Meg or so (the duplicate files are small). But at least it's possible to eliminate the need to copy the "data" dir and clean up the chitin file a bit as well.

EDIT2: Hmm... doesn't work to make relative paths to any BIF files in the CD? directories. The program seems to only allow relative paths for "BIFF" files (which are in the HD0 "data" directory) and not "BIFC" files (which are in the CD?\data directories). Interesting. I'm not sure if there's a reason to convert the BIFC files to BIFF or the other way around. Maybe BIFC are smaller, but then you have the decompression overhead.
I gotta get rid of this friggin idiotic signature...

#23 FredSRichardson

FredSRichardson

    WeiDU Meddler

  • Member
  • 258 posts

Posted 06 March 2004 - 11:49 PM

OK, so I think I can put together a program that will work, and you won't need to move the .\Data\ directory at all. I wrote something in Perl that seems to solve the problems I was having before.

Here's an update for IESDP (for the Key file section):

For BIF entries, the 2 byte word at offset 0x000a indicates the CD or CD directory for the BIF file. Here are the bit flags values which can be OR'd together to indicate that more than one CD directory should be searched:

0x0001 HD0
0x0002 ???
0x0004 CD1 # Not used in BG2
0x0008 CD2
0x0010 CD3
0x0020 CD4
0x0040 CD5

(EDITED)
If a BIF is located in HD0, then it must use the BIFF format. Files located in the CD? directories generally use the BIFC format (which is a compressed version of the BIFF format) but the regular BIFF format also works.

The BIF file names are relative paths to the BIF file locations. That is to say, if a file is located in HD0, then the full path to the file is created by concatinating the value of the HD0 key from the baldur.ini file with the file name from the BIF entry. The same is true for the CD? locations.

One word of warning: HD0 is used for more than find the BIF files listed in the chitin.key file. There are several other game resources that are accessed using that path. So if you wanted to move BIF files that are in the HD0 directory and have the game find them, you would have to modify the BIF entries in the chitin.key file to use a paths relative to HD0 to find the new locations of these files, e.g. if you move the HD0 BIF files to C:\Program Files\Black Isle\BG2Data\, and your game directory is C:\Program Files\Black Isle\BG2, you're entries would have to be changed from this:

data\SomeBiff.bif

to this:

..\BG2Data\data\SomeBiff.bif

In the case of the CD? BIF files, the CD? keys in the baldur.ini file are only used to find BIF files in the chitin.key file, so you could just move the CD? directories from your game directory to the BG2Data directory and modify the baldur.ini file to use this path.

I attempted moving all BIF files that are under the HD0 data directory into a new directory CD1\data (which is listed in the baldur.ini file but not used) but at some point this caused the game to ask for "CD 1" in the D drive. It could be that some of the files in the HD0 directory have to stay there to function properly.
I gotta get rid of this friggin idiotic signature...

#24 CamDawg

CamDawg

    ALL GLORY TO THE HYPNOTOAD

  • Modder
  • 1505 posts

Posted 13 March 2004 - 07:13 AM

Is the updated binary available anywhere?

Why is this Hypnotoad video so popu... ALL GLORY TO THE HYPNOTOAD.
____
The Gibberlings Three - Home of IE Mods

The BG2 Fixpack - All the fixes of Baldurdash, plus a few hundred more. Now available, with more fixes being added in every release.


#25 FredSRichardson

FredSRichardson

    WeiDU Meddler

  • Member
  • 258 posts

Posted 13 March 2004 - 06:31 PM

I'm sorry, I haven't had a chance to work on this yet. I'll let you know as soon as I get on out there. (I'll post to this thread)
I gotta get rid of this friggin idiotic signature...

#26 igi

igi

    IESDP Guardian

  • Administrator
  • 1065 posts

Posted 28 March 2004 - 04:37 PM

Heres a (possibly) simpler way, resulting in each clone installation being about 60mb (including the 34mb from the override folder).


How to Create a Minimal BG2 Clone for Modding

1) Complete a full install of BG2:SoA (and install the latest SoA patch, if ToB is not to be installed)
2) Complete a full install of BG2:ToB (if required) (and install the latest TOB patch)
3) Make new directory, e.g. "clone1"
4) Copy the following to "clone1"
Directories
  • \characters
  • \override
  • \portraits
  • \save
  • \scripts
  • \sounds
Files
  • baldur.ico
  • baldur.ini
  • bgconfig.exe
  • bgdxtest.exe
  • bggltest.exe
  • BGMain.exe
  • Chitin.key
  • dialog.tlk
  • Keymap.ini
5) Edit bgmain.exe at 0x00705E04, from "hd0:\dialog.tlk" to ".\dialog.tlk..."
"2E5C6469616C6F672E746C6B00000000" to "6864303A5C6469616C6F672E746C6B00"

------------------------------------------------------------------------------------------------

How it works
The common files are stored in the initial install directory.
The core files (unique to each clone) are copied into each clone dir.
The .exe patch is to tell the .exe to search for the dialog in the local dir, as opposed to the \data dir.

This has the usual downsides:

I dont know how it will affect games which place new biffs in the chiten.key (likely all clones will be affected, since theres only 1 chiten.key). Same goes for new music (though this can easily be altered, by .exe patching the music entry from hd0:\music to .\music).

The registry entry only points to the initial install. So this will be the one runby the autorun feature, and wil be the one listed under add/remove (hence we dont need the uninstall files in our unique copied data).

I havent extensively tested this method. It's not been tested at all on non-english versions of the game. I suspect it would work fine, as long as the right offset is changed for the dialog.tlk reference.

Anyway, I hope it works, and helps.
Any questions, just ask.

/igi
ps. I know it involves .exe patching (generally bad), but weidu is capable of this, andit only needs to be done once (once the patch is done, the .exe looks in the local dir. So you can copy that .exe into another clone dir, and it will look in there). This could be distributed as a weidu component maybe, if we get enough game version offsets.

Visit the IESDP


#27 FredSRichardson

FredSRichardson

    WeiDU Meddler

  • Member
  • 258 posts

Posted 29 March 2004 - 05:26 AM

Hi,

This looks like a nice solution. Are you sure that each clone directory will use their own local override directory? I thought the HD0 key in baldur.ini was used for that.

Otherwise, if that works, and if music can be patched, then this is a pretty ideal solution. I'll have to try it out.

I agree that WeiDU can be used for any of the above methods (after all, bg1tutu and iwg2 modify the chitin.key file and the .exe binary).

The other caveats are common to all of these strategies, but that's great that you spelled them out.

Thanks, I'll have to try this out some time soon,

-Fred
I gotta get rid of this friggin idiotic signature...

#28 igi

igi

    IESDP Guardian

  • Administrator
  • 1065 posts

Posted 29 March 2004 - 05:55 AM

Lo,
I'm pretty sure that each clone will use a local override dir, yes.
And I am also pretty sure the music location can be patched.
NB. For non english versions, you of course need to alter the location of the dialogf.tlk file too.

Visit the IESDP


#29 Idobek

Idobek

    Pocket Plane Gibberling

  • Member
  • 429 posts

Posted 29 March 2004 - 06:11 AM

I searched the exe for '\override' it only turns up once - as '.\override' not 'hd0:\override'.

This should do the job on a patched ToB exe:
BEGIN ~Multiple Install BGMain Hack~

COPY_EXISTING ~BGMain.exe~ ~BGMain.exe~
   WRITE_ASCII 0x00705e04 ~.\dialog~
   WRITE_ASCII 0x00705e0c ~.tlk~
   WRITE_LONG  0x00705e10 0x00000000
   WRITE_ASCII 0x00705e14 ~.\dialog~
   WRITE_ASCII 0x00705e1c ~f.tlk~
   WRITE_LONG  0x00705e21 0x00000000
   WRITE_ASCII 0x007069b4 ~.\music~
   WRITE_LONG  0x007069bb 0x00000000