IWD1tutu

[FredSRichardson]

NOTE: There is an "official" IWD1Tutu forum here




GENERAL INFO

I thought I'd start updating the top of a new thread with general info on how this little project is going.  This may include tons of minute details that don't mean much to anyone but me, but it will at least give a sense of something being attempted here, and if anyone wants to chime in with a solution, that's always welcome.

PROJECTILE GHOULS

unspiration I started playing IWD1 again after a very long time and realized something.  In relation to BG2, IWD1 has something quite different to offer.  NPC's with inter-party banter and associated quests dissappear, but that empty void is filled with a obsesive attention to detail that I find compelling.  I have to admit that I fell in love with Dorn's Deep and the Severed Hand all over again, the story line behind these areas as well as the artwork itself pulled me in.  I suspect that there are only a few other people who share my enthusiasm for this particular game.

For me, IWD2 is a somewhat different story.  Um, and yet it isn't.  Actually, in some ways it's too much of a rehash of the same story.  They recycled pieces like Kuldahar, The Dragon's Eye and the Severed Hand giving the game a very "derivative" feel to it.  The story line is "okay", but various things draw away from it like the "tic tac toe" Barbarian boulder puzzle, or the long and tedious "Battle Square" arena.  I believe that the real achievement of IWD2 is the revamped Infinity Engine, which proved to be the very last of it's kind, and now supported the D&D 3E rule set (more or less).

Not long ago (in a not-so-distant galaxy), Wes Weimer put a substantial amount of effort into trying to port BG2 to IWD2 (IWG2), but this project was impeded by the vast difference between the two game engines (and IMO their design philosophies).  Others were able to apply the results of Wes' efforts to port BG1 to the BG2 (BG1tutu). 

This thread is about the possibility for another project that's only just in it's infancy: porting IWD1 to IWD2 (IWD1tutu?).

I thought I'd try to do a "forward/backward" approach to this.  The "forward" part being the porting IWD1 into IWD2 and the "backward" part being the application of IWD2's conventions to IWD1.  So I was hoping to be able to play IWD1 with the look and feel of IWD2.  Unfortunately there's a large amount of stuff that falls between the two directions.  Messy dialog and script convertions loom in this foggy convergence.


Observations
There's a lot that's similar between IWD1 and IWD2.  Just playing the two games, you see the same monsters and many of the same items.  Looking a bit further into the games, you see other things, details like the "bit flags" used in scripts or variable and file names.  One of the first things I noticed is how clean the IWD2 name space for CRE and ITM resources.  CRE prefixed with 10 are all in chapter 1, 20 are in chapter 2 and so on.  The IWG2 source code completley munges variable and resource names during conversion so that they don't conflict with what's already a part of IWD2 (for better or worse).

CURRENT STATE
So far, not much.  I'm struggling to get one area converted over.  I have the area, but it crashes the machine.  I've been going through it with IESDP, and checking iwg2 code, and it's forcing me to go into the iwg2 source in greater and greater detail.  I'm close to this first step at least.

[FredSRichardson]

Alright, I got an area to load.  I gave up on AR1000 and went with AR1015.  You know the one where you have to kill those little beetles?  Well, it was hilarious watching these beetles kill my entire party.  Hmm, think we need to a bit of fine tuning... 

[Grim Squeaker]

Surely the name should be IWD1tutu, in a similar way to BG1tutu?   IWD2tutu would imply is converting IWD2 to itself.

[FredSRichardson]

Gah!  Of all the places to put a typo I had to pick the topic title.  I take it there's no way to edit that?
Hah, fixed it, thanks!

[Andyr]

Nice work. So the area you've converted so far, was it manually to get a feel for it (looking in the IWG2 code to see what it changes) or using the tweaked IWG code itself directly?

[FredSRichardson]

Mostly using heavily hacked iwg2 code, I then ran DLTCP (I think it's called) to check the area (I had to fix the exit transitions or something).

AR1000.ARE from iwd1 is giving me troubles.  That's the one I've been trying to convert over, but loading it just crashes the game.

I need to do a lot to the iwg2 source.  I'd like to make it so that similar things are mapped to similar things.  iwg2 takes the approach of converting every single resource over which isn't really needed.  though it does force me to fix item conversions.

Many things are buggy, I'll keep you posted when I see a bit more light a the end of the tunnle

[Avenger_teambg]

What might give crashes:
1. tileset not extracted
2. ambient sounds not extracted
3. other missing resources

[FredSRichardson]

AR1000.ARE seems to work.  I even had the main dude come up to me and talk (the guy who normally invites you on the initial quest).

This is still really rough.  I think much can be simplified.

[FredSRichardson]

Some IWG2 code questions I'm mulling over:

* Do I really need to convert all the variables, script and CRE's to a new name space?  I shouldn't be running any old scripts so this seems too paranoid to me, and then there's major issues if I forget to move some variable/scriptname to the different name space.

* Area names are mapped to AR0000 and incremented by 1, whereas IWD1 and IWD2 use chapter numbers in the first decimal place after "AR" (e.g. AR1### for chapter 1)..  Is it really important to avoid over-writing the existing ARE name space?  I'd like to leave it unchanged or maybe use letters 'A', 'B' etc in the chapter position (e.g. ARA### for chapter 1).

* I'm assuming both of the previous things are done to preserve both games, but I'd like to avoid trying to do this.  That is, when you install IWD1tutu, then you won't be able to play IWD2 with that game installation.  The obvious work around for this is to make copies of the override, CHITIN.KEY, and Dialog.tlk before installation.

* There's a lot of Action/Trigger mapping that I don't fully understand, and there are new unmapped triggers and actions in IWD1.  I thought I'd do a profle of these in both games and compare how they're used (ones that are never used but exist in the IDS file are likely not to work).

* ITM/CRE mapping.  Many ITM's don't need to be converted but can just be mapped.  I'm going to add that some time soon.

[Grim Squeaker]

With the areas, surely its best to just rename the prefix like in Tutu.  So AR1### becomes, say, FR1### or IW1###.

[FredSRichardson]

Thanks Grim, I've been meaning to take a look at the BG1tutu code anyway.

Off hand, why is it so important to preserve the old name space?  I only ask because it seems like more of a hassle than it's worth.

[Grim Squeaker]

I think basically so you aren't overwriting the old files.  Also, it makes browsing files kind of confusing where some of them have been overwritten and others not
e.g.

AR0100-0105 New IWD1 files
AR0106 Old IWD2 file

That kind of thing makes it confusing.  But mainly I think its because you don't want to have to overwrite stuff where you don't have to.

[FredSRichardson]

Hmm.. I see you point.  I think that Wes may have tried to change the area naming from AR#### to some other prefix but I don't think it worked in IWD2 for some reason.  I see the code for doing this for the bg1 -> bg2 conversion using FR#### so I think he tried that.

The name re-mangling stuff worries me.  Things would be more likely to work without it.  IWG2 currently mangels all the variable, script, CRE and ITM names.

[Grim Squeaker]

Personally, I think Tutu is a much better template for some of the conversion than IWG.  While IWD tells you how the IWD2 engine works, Tutu is a successful conversion that works properly.  My advice is to look at Tutu, and then try and adapt code to fit the specs of IWD2.

[FredSRichardson]

Well, I think I have to look at both. my understanding is that tutu is based on iwg2, so there should be a lot in common, but there should also be a few bug fixes in tutu that I could benefit from.

But the differences between bg2 and iwd2 are dramatic, and I doubt I'll be able to use much of what's in tutu.  iwg2 still has the hooks that deal with some of the differences in file formats, it has trigger/action "conversions" and non-trivial CRE conversions (assigning feats and what-not) that I need.  It gets even hairier with Effect and spell conversions.

Anyway, it will be interesting to look at tutu, and I will, but I don't think I'll be able to use much of what's there (unfortunately).

[FredSRichardson]

Just a quick update: mappings seem to work great with the current "rules" system in iwg2, so I can use the iwd2 goblins, items, etc so long as I create a mapping file (I tested this out in AR1000 and it works great).

I think I'll want to make this a bit more sophisticated and add some of the team-work scripts in iwd2.  More on this later.

[FredSRichardson]

Bried update:

* Items are well under way:
** More item mapping.  I have to see what the automatic item conversion will do to items I can't map (I can probably just hand fix those, map them and stuff them in override).
** I have a lot of depencies listings generated and also descriptions of items by type including melee/droppable/displayable info.  I created a listing for the rndtres.2da in both iwd1 and iwd2 so I can map those.

* Spells are going to need a lot of work, haven't gotten to those yet.

* I'm not sure about effects mapping.  This probably mostly effects spell/item conversions (I'm hoping to map instead of convert).

* CRE mapping is easy in some places but will be quite difficult in others.

[Borsook]

for practical balance reasons (i.e. move to 3e) a lot of cres will have to be redone completly. Anyway it's good to see you're making progress.

[FredSRichardson]

for practical balance reasons (i.e. move to 3e) a lot of cres will have to be redone completly. Anyway it's good to see you're making progress.

Yes!  I agree completely.  I don't hold a lot of faith in a general translation of CRE's in general.  The good news is that most of them can be mapped to existing resources, but most likely a bunch will have to be hand tweaked.

I'm also holding out for the possibility of improving the general cre conversions rules, but I don't hold a lot of stock in this idea.

[FredSRichardson]

Arrgh, another piece of trouble.  CRE's in iwd1 have 3 fields for death variables, whereas iwd2 has room for 1.  It looks like these actually get used in places like AR8008.  I'll have to see if there's an easy work-around, or how frequently this gets used.

[Andyr]

I think the creature mapping and balancing was one of the more tedious parts of IWG2--I remember in the later versions Weimer made, there were several balancing attempts/suggestions made.

I didn't realise about the multiple death variables... intriguing.

[FredSRichardson]

Yes, Weimer made a valiant attempt at converting creatures over.  There are a few odd details to this I'm trying to sort through  (I'm going over the feat mapping now).

Creature mapping is basically giving up on creature conversion and saying "For GOBOBOW.CRE in IWD1, I'll use 00GOBAR.CRE in IWD2".  For the most part this works, with the notable exception of when one of those other 2 death variables are used.  I believe the default death variable in both iwd1 and iwd2 is the actor name.

BTW: the extra death variable thing is IWD1 specific, so there's no reason you'd see that in BG2.

[FredSRichardson]

Okay, I'm noticing that when I load one of my new areas, the IWD2 game looks slightly glitched.  I remember noticing this when playing around with iwg2.  I'm wondering if IWG2 is a bit pickier about it's area file (TIS geometry maybe?).

[FredSRichardson]

The glitched look is (I think) a red herring.  I noticed it loading a regular IWD2 area.

I decided to look and see how often the death variables are used in scripts.  I made a table of all CRE's and there death variables (sometimes as many as 3 are set), and I've put together a simple parser in perl for actions/trigger (I know WeiDU already does this, but it's actually easier for me to throw together the perl code than to figure out how to do it in WeiDU).  An initial grep showed a small number of hits.

I found one situation in a DLG where a SetGlobal is used as a trigger (but isn't defined as one, hmmm...):

In Accalia's dialog (DACCALIA.DLG), you have this trigger:

Code: [Select]

IF ~SetGlobal("Jered_Stone","GLOBAL", 1)~ THEN REPLY #259 /* ~What's Everard like?~ */ GOTO 16
I'm not sure what the engine does here.  I know it has to compile the small script (it exists as BAF code in the DLG file), and I believe I've reached this block before in the dialog.  It's a mystery.

[Andyr]

I think it's a typo.

That dialogue option is available as response 37, which goes to the same place as the one you reported, but has that the SetGlobal set as an action rather than a trigger. So you can get there without using that incorrect trigger. Perhaps they just added a working version of the reply rather than fix the broken one at some point?