Jump to content

IWD-in-BG2 sourcecode

Recommended Posts

As a gesture towards being open-source, I thought I'd try to keep the actual sourcecode for IWD-in-BG2 somewhere accessible.


Unless you are seriously interested in how IWD-in-BG2 works, READ NO FURTHER. This version is not relevant even for people who want to help test the mod.


IWD-in-BG2 works like this. (It's not far off how BGTUTU works.)


1) start with a copy of BG2, with the IWD-in-BG2 folder as a subfolder.

2) run the get_iwd_resources batch file. Cam wrote this, and I've lightly modified it. It grabs all the IWD resources from an install of IWD and dumps them somewhere accessible. It also uses BGT voodoo I don't understand to convert the tilesets to be BG2-friendly.

3) run setup-iwd_in_bg2 as a weidu mod. (I haven't packaged a copy of weidu, so you need to add a local one) and install all components.


It's also helpful to think of setup-iwd_in_bg2 as having several components:


(a) the core contents of setup-iwd_in_bg2.tp2, which do most of the processing. The early part of this was based on Cam's version but most of it is mine.

(b) the convert_pro macro. This converts projectiles to the BG2 format. Nythrun wrote the core, I added various bells and whistles.

© the david_itm_spl macro. This converts the spells and items - it's based on Cam's original macro but it's been fairly heavily modified and expanded.


As well as actually running the conversion, setup-iwd_in_bg2 creates (via component 10000) a list of all IWD resources that are simply copied over, as well as where they're copied to and (in a few cases) what they're renamed to.


The actual version of IWD-in-BG2 I distribute is actually more like EasyTUTU than BG1TUTU. It contains a copy of every file modified by setup-iwd_in_bg2: that is, it contains the override directory (prior to that directory being biffed by component 5000 of setup-iwd_in_bg2), and the folders iwd_in_bg2/biff/X, where X=gen_cre, X=dv_cre, or X=cre_ini. It also contains the above list of files to copy over.


When the distributed version runs, it clones a new copy of BG2 and then copies over all required IWD resources, as specified in the list. Then it dumps the modified files into the relevant places. Finally, it runs those few components of setup-iwd_in_bg2 that aren't replicated by the above process (the most obvious one is the animation converter).


In any case, the sourcecode is here for anyone interested. I say again, REALLY only look if you want to poke around in the code. This is a copy of my local version; it isn't even tested as working elsewhere.


To generate the executable, you have to run the sourcecode version and install all components except 1000 and 5000. Then you need to use the results to update the executable. (It should be fairly self-explanatory from the executable how to do this; basically, copy over setup-iwd_in_bg2.tp2, override, gen_cre, and biff-file-list.2da.)



Unfortunately the sourcecode for versions 3, 5 and 6 is lost. (It's faintly possible someone other than me has a copy of the v5 sourcecode; let me know, if so. 3 and 5 are permanently lost as a consequence of bad backup habits on my part.) I can supply the sourcecode for version 4 on request; for versions 1 and 2 there is no distinction between sourcecode and executable.

Edited by CamDawg
fixed link
Link to comment

Is the v8 sourcecode available too?


I think I've narrowed down the conversion error that prevents some ambushes in the Severed Hand from triggering (by going through the relevant scripts and comparing their before/after versions with NearInfinity), and I'd like to take a stab at finding the offending line(s) in the converter source code and possibly coming up with a patch.

If that's alright with you, that is... :)

Link to comment

Don't bother, tbh. The v9 sourcecode is likely to be fairly substantially rewritten anyway, and our pattern for v8.x, like v7.x, is probably to produce after-installation patches instead of changing the underlying sourcecode. But I'd be keen to know what the actual problem is.

Link to comment

our pattern for v8.x, like v7.x, is probably to produce after-installation patches instead of changing the underlying sourcecode.


Even then, looking at the source might occasionally make it easier to track down bugs, as it makes it possible to quickly confirm that an observed problematic conversion pattern is indeed a general rule. But it's your call of course; Sorry if my request was inappropriate, I'm more accustomed to the open-source scene and am still adjusting to how things are done differently in the modding community... ;)


But I'd be keen to know what the actual problem is.


I posted my intermediate findings in the bug report thread.

Link to comment

It's totally appropriate, not a problem at all. And I'll post the sourcecode when I get a chance. (But at least *my* modding style requires that I basically keep track myself of any modifications to the source code, otherwise I just get confused.)


On patches rather than sourcecode changes for intermediate releases, this is mostly because compiling the sourcecode to produce the distributed mod is a complete nightmare (largely due to poor design choices in my original code way back when). It's not realistic for me to do that, and to upload the 20MB result, every time something gets changed.

Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...