FredSRichardson

Another status update. I have the music part worked out, though it makes the game slightly incompatible with the original IWD2 (one of the sound file names is hard-coded). I could also handle this by making a seperate binary which has it's advantages (I can probably change the start-up screen). The next stumbling block I've hit has to do with mutate_cre. This routine is frought with a lot of problems. They stem from the original approach which is to convert the 2E based IWD1 CRE's to 3E based IWD2 CRE's. The routine has many clever things for handling this including the way statistics are scaled and feats and class abilities are added to re-build a character from the ground up. Unfortunately, there are several places where this is prone to fail (I'll list them later when I've gone through it again). One particular place of failure is the spell-book conversion. If not enough spells are memorized, then the routine slelects from a "random_spell" table, but the same table is used for all classes! Some of these spells aren't even in LISTSPLL.2DA which breaks things. I'm a bit torn on exactly what to do. I'd like mutate_cre to still do some heavy lifting, so one thought I had was to make a predefined "spell table build-up" chart for each class (RGR,BRD,DRD,PAL,SOR,WIZ,etc). This might have you add the same spell more than once when you get more slots at a given level. What I'm not sure about is if the CRE's scripts will make use of these spells anyway. So I need to look into this. Another thing I've thought about is that a CRE could have a spec for it's stats, classes, levels, spell-book, etc. These could then override whatever mutate_cre would try to do. One thing I haven't checked is to see how a cleric is converted (how is the domain and type picked, just based on alignment?) It would probably be best if this stuff was specified outside of the code (i.e. by a rules file).

I promise to get back to this stuff guys. I just took a bit of a break from all this for a while

Okay, thanks! The Sahuagin in IWD1 look very different than the ones in BG2, I wonder if they're somewhat more "compatible" with IWD2 (there are so many things that seem "similar" between the two games).

Yee Haa! I got the first bit of sunshine working. The syntax is this: ~GOBEHQ1.CRE~ < ~10GOBEC.CRE~ ADD_SOURCE_ITEM (~FISH.ITM~, 0, 0, 0, 0) > Which basically means "in place of GOBEHQ1 in IWD1, I want to use 10GOBEC, but also add the item FISH from IWD1 to his inventory". This works, though it's pretty inefficient for adding many items (basically I keep allocating new buffers since OCaml doesn't seem to offer a "realloc" type of buffer resizing, grrr...). I'll probably fix this by figuring out what's going to be added up front and then creating a single new buffer to do it in, but this works for now. The real significance though is that it's pretty easy to add new "mod" types of routines to the code. The other ones I'm thinking about are SET_ATTR(12,18,14,3,9,10), SET_HP(42), SET_LVL("Fighter", 8). Adding spells and other things may be neccesary (changing colors, animation?). The basic idea I have is to find "close matches" in IWD2 for as many creatures as possible in IWD1, and adjust them to get a closer fit. I'm wondering if the Sahuagin in HOW are going to be a problem. I saw a note from Wes that the animation for these was problematic in IWD2 (haven't tried this out).

Just thought I'd break silence with a quick update. Not much to report right now. I'm going through a heavy coding phase at work so it's hard to get excited about more coding when I get home, but that should change pretty soon -Fred

The fact that IWD1 has no EFF files is a wonderful thing. The EFF conversion routines are amon the hairest things I've seen. [EDIT] Oops, I spoke to fast. Plenty of effects to deal with in the SPL files (and probably in ITM files as well).

Okay, that's not a bug after all. It looks like Actors scripts set the AREA_HOSTILE flag and the area scripts just make sure to reset the "TOWNIE_DEAD" variable to 0. TOWNIE_DEAD seems to always be stored in the 2nd script name at offset 0x27e so I'll always save the variable from that location in the auxillary script name slot in IWD2's CRE struct. This will reduce the number of special cases that need to be dealt with (the 3rd script name variable is only used in certain places).

---- Daily Update I've hacked out a bunch of things that were needed for the BG2 conversion, but don't seem neccesary for this conversion. I want to start off with as few changes as possible. I've been looking into creature mapping/conversion a bit more. I'm thinking about how to handle those 2 auxillary "script name" variables in IWD1's CRE structure. I can go about this a few different ways. In many cases, the two auxillary variables contain these two variables: Townie_Dead Kill_Innocent Kill_Innocent is only used in the DLG with vexing thoughts to see if you've "done as he's asked" (i.e. killed an innocent). Townie_Dead is strange, most areas have this script segment: IF !Global("TOWNIE_DEAD","GLOBAL",0) THEN RESPONSE #100 SetGlobal("TOWNIE_HOSTILE","MYAREA",0) SetGlobal("TOWNIE_DEAD","GLOBAL",0) Continue() END What's odd is that this is the only place where I see TOWNIE_DEAD, and it appears to be a no-op. Is this a bug? Shouldn't TOWNIE_HOSTILE be set to 1? Anyway, if this isn't a bug, then I don't have to do anything for these variable But if it is a bug, then one possible fix is to identify each actor that has a CRE with the TOWNIE_DEAD script name and create a script block using those names: IF Global("TOWNIE_HOSTILE","MYAREA",0) Or(3) Dead("Townie1") Dead("Townie2") Dead("Townie3") THEN RESPONSE #100 SetGlobal("TOWNIE_HOSTILE","MYAREA",1) Continue(); END I'm still struggling with the iwg2.ml code. It's pretty hairy in some parts. Fortunately, I believe that there's a lot I can get rid of. That may be the next thing I do (a lot of code is commented out).

Oh wait, for my total conversion stuff, mapping thing into the random item table's great. But I think what you suggest is better in general since you can handle random items from a script without having to do any area editing each time you want to change something.

On the off chance that someone else might find them useful, I thought I'd mention any unique utilities I'm using for this project: NIDigGen: I've hacked together a command line addition to NearInfinity that fills in a small nitch for me somewhere between DLTCEP and WeiDU (and of course NearInfinity). My primary need was for a command line utility with text format output that I could process in various ways with Perl scripts (or any other text utility). I'll have to wait and see what the best way is for me to distribute this NI "enhancement". Here's the "usage" info for the utility: frichard@comp:/> nidiggen Usage: NIDigGen [-e -f -u -a -l TYP] <chitin-key> <out-dir> <res-name> ... -e Export the resource(s) to <out-dir> -f Load the resource(s) from the specified file(s) -u Include unknown fields in text output -a Include hex offsets in text output -l TYP List all resouces of type TYP and exit frichard@comp:/>

Grog, is it possible just to add new entries to RNDTRES.2DA? It seems like one could add any number of additional lines and create new items for each entry point like: Add to RNDTRES.2DA: MYRND 00mace02 00mstr02 00dagg02 00hamm02 00halb02 Then create an item MYRND.ITM (you could just copy an existing one like RT02_M.ITM).

Yes, that's exactly right. For PC's, the spell selection (and aquirement) will be just like IWD2. One issue is working out the distribution of available spell scrolls. I'd like to keep this balanced, but not be too meager with the scrolls either. The tricky part comes in when converting BCS and CRE files. The spell books of the CRE's and spell casting script actions all have to mapped to spell that exist in IWD2. It may be neccesary to re-think the enemy mage AI scripting for the conversion to be really satisfying. So actually there are a few "add ons" that I've been thinking about for this project. Some of them may be neccesary and other might just be "nice touches": * Consistent IWD2 style "team" scripting: the IWD2 scripts almost compulsively maintain team association for every actor in an area. I think the mechanism is a nice on in that the PC can't abuse the fog-of-war to pick off on monster at a time. Instead, seeing one member of a team causes the whole team to come over an attack. I think the bioware developers would also place some team members further away so that they would appear at different times giving the effect of monsters joining into the battle at different times. Re-placing actors may be beyond the scope of this project (unless I can automate it some how). The team scripting is very easy to implement (and you see an early versions of it in the IWD1 scripts). Each monster usually get 2 team scripts (one to assign the team and the other to join the team when the fighting begins). There are scripts for up to 20 teams, each is prefixed with "00T##" (e.g. "00T01" for team 1) and for each team there are 13 scripts with extensions "A", "DET", "E", "ET", "EV", "EVT", "M", "N", "R", "S", "T", "V", "VT". These scripts basically do the following in different ways: -Make sure the team bit is set for the creature. -Set the variable "TEAM_#" when a team members sees an enemy. -Decides when the team member should go hostile (some combination of hit, attacked or pickpocketed). Of cours set "TEAM_#" when this happens. -Checks variable "TEAM_#", and goes hostile when that's set (if they're not already hostil), and moves to nearest enemy. I'm not sure about the nuances between the different version of these. Most monsters use 2 of them: "00T##M.BCS" (team movement) and "00T##T.BCS" (team assignment and update). Team management scripting is also done in the unique NPC script files, and TEAM_0 (which may be the default) is used for the neutral "townie" types. * IWD2 style enemy AI scripting: team scripting is sort of part of this, but the mage AI may be worked out better than any automatic conversion of the IWD1 AI. * Consistent 3E conversion rules: The existing iwg2 code has a sophisticated conversion routine that I think could be adapted nicely apply the 3E rule set (Andyr and Grog have both pointed me to a nice set of online 3E reference sites). As I said, I'm going to try to map creatures from IWD1 to existing resources in IWD2, but this won't always be possible, but there will be an overwhelming number of creatures that can't be mapped, and those need to be converted.

NOTE: I don't like to read a long-winded expose of something that can be summarized succinctly with only a few words. But ironically I have a hard time writing with same kind of brevity and clarity I know I would appreciate as a reader. What I will try to do is make a summary here of what's going on. Summary * Resource Mapping: - ITM that are the same in both games will be "mapped" instead of converted (this uses a "rules" file in IWG2). - Some items are close enough to be mapped. Like "High Quality" weapons in IWD1 can be mapped to "Masterwork" ones in IWD2. Other mapping decisions can be more of a stretch (e.g. elemental damage resistance potions in IWD1 to "Potion of Minor Elemental Barrier" in IWD2). - Some CRE's can also be mapped, unless a "death variable" is being used for something. IWD1 CRE structures have room for 3 death variables (see Scripting below). - A large number of resources can't be mapped, and those will have to be converted automatically or edited by hand. * Resource Conversion: - Versions: IWG2 handles versioning between BG2 and IWD2, but IWD1 has some unique versions as well (see table below). I've already dealt with CRE's, but I'll have to be sure to deal with GAM files (and undo the STO conversion). - From 2E to 3E: The conversion of CRE (and ITM) resources from the 2E rules in BG2 and IWD1 to the 3E rules in IWD2 is a hard problem and IWG2 deals with it valiantly. But the results are not ideal, and I'm considering taking a less algorithmic approach and instead applying 3E rules directly from a D20 source. - Exceptions: there will be cases where resources can't be converted in any satisfactory way, and in those situations they'll have to be edited by hand (or I'll have to create a way of using auxillary files for specifying them). * Specific Resource Consideration: - Variety: IWD2 has a larger variety of weapon, armor and ammo types that can be found as treasure or in stores than IWD1 does. It will be important to make sure the variety is increased as part of this conversion since this can be a limiting factor in player character builds. - Random Drops: These are determined by the RNDTRES.2DA file. The version of this file in each game has some desireable characteristics. The IWD1 version determines a few important random rewards, whereas the version in IWD2 has a larger variety of small rewards. * Unknown Resources: I'm not sure if I have to deal with these resources in any special way. The appear to be game engine specific: - INI files in IWD1 and IWD2 (not in BG2) - SRC files in IWD2 (I think these are just the Bioware "World Editor" info files) * Scripting: - BCS Triggers/Actions: most of the triggers and actions map over directly from one game to the other. Some code fragments that work well in IWD1 may be a disaster in IWD2. The differences between coding styles in each game give some hint of this. - Team scripting: Team scripting is very consistent in IWD2, but not so much in IWD1, I've been worried that Team scripting may be neccesary for things to run smoothly. The good news is that it may not be too hard to add this in. - Death Variables: As mentioned above, CRE's in IWD1 can have up to 2 auxillary death variables, and in some cases both of these get used. I'm almost certain IWD2 only has room for 1 auxillary death variable (I spent some time verifying this). * Resource type and version for BG2, IWD1 and IWD2: BG2 IWD1 WD2 ARE V1.0 V1.0 V9.1 BAM(C) V1 V1 V1 CHU(I) V1 V1 V1 CRE V1.0 V9.0 V2.2 DLG V1.0 V1.0 V1.0 EFF V2.0 N/A N/A GAM V2.0 V1.1 V2.0 INI N/A UNK UNK ITM V1 V1 V2.0 MOS(C) V1 V1 V1 PLT V1 V1 N/A PRO V1.0 N/A N/A SCC N/A UNK N/A SPL V1 V1 V2.0 SRC N/A N/A UNK STO V1.0 V9.0 V9.0 VVC V1.0 N/A N/A WED V1.3 V1.3 V1.3 WFX V1.0 N/A N/A WM(A)P V1.0 V1.0 V1.0 I think these are not explicitly "versioned" but appear to be in all 3 games (and I think are the same): 2DA BMP BCS IDS TIS WAV --------------------------------------------------------------------------------------- VERBOSE NOTES: One note I made early on is that the two games (IWD1 and IWD2) are remarkably similar in a few specific ways. Both games use "bit field" type variables for BCS/BAF scripts (presumably so that could support a large number of boolean flags). Looking at the two games, it easy to see that a lot of what is in IWD1 was significantly cleaned up in IWD2. The scripting relies much less on "Death Variables" and uses explicit actor names instead (which is easier to track), and "team work" scripting uses new SetTeamBit/GetTeamBit action/triggers making the whole implementation much easier to follow. If would be wonderful to clean up IWD1 so that it can benefit from some of these new changes, but I don't know if that will be possible. The games both have many items and monsters in common, many of which use the same icons or animation so that they look uncanily familar in the game. (IMO, there was a bit too much that was familiar in IWD2 which dampened my appreciation of the game a bit). While IWG2 took the philosophy of converting every resource in BG2 over to IWD2, I've decided to only convert things when it's absolutely neccesary, and to consider doing this by hand in some specific cases. As an example, I've been able to map a large number of items from IWD1 over to IWD2, but this does leave some items left over that require a bit of thought. Some things are pretty easy mappings, like replacing the "high quality" weapons with their "masterwork" counter-parts, then there are slightly more arbitrary things like I was considering replacing the fire/cold resistance potions with potions of minor elemental barrier (there is no exact mapping, and it would be nice to use these new spell-like potions), then there are items like the mage daggers which grant extra spell slots that probably have to be replaced with something completely different (I didn't see any slot granting items in IWD2, so there may be an implementation issue). The items which will actually require work to recreate are the ones that will be missed by people who have played through IWD1 before like the "of the hand" items are the special axe you find near the entrance of Dorn's Deep. Ideally I'd like to preserve the flavor of IWD1 by keeping the items that help give the game it's character, and at the same time represent more fully the new types of items that allow the player to experience some of the new aspects of the IWD2 engine (I noticed that the weapon selection in the original IWD1 is pretty minimal, and spell scrolls need to be made more available at some point). Another specific area which I struggled with a bit is the topic of random items. The random items in IWD2 represent a larger variety weapon types in the game, but in IWD2 all of the random items (with a few exceptions) are non-unique weapon or ammo or gems and non-magical jewelry. IWD1 on the other hand puts a few important (to the player) items in there random items table to mix things up a bit. I think I decided that it would be best to combine both approaches: allow the broader variety of weapon and ammo types in the IWD2 tables, but also include entries for random items that are special or unique. The next topic is creatures. IWG2 has a very impressive creature conversion system, but it isn't really useable (the monsters it generates are way to powerful). The code appears to include all the conditions for assigning classes, feats and skill points and adjusting the various bonuses that result from these (as well as checking the prerequisites for them). I thought I'd try to take a different approach and see if it's possible to use the 3E rules explictly and assign stats/feats/skills based on Race and HD. This would be a very good initial cut that could be improved on by adapting some of the IWD creatures to use sub-races and multi-classes where it seems like it would be appropriate. Script conversion is a bit of a mystery to me. I've only begun to identify the things I know will be a prolblem like death variables. IWD1 actually uses 3 death variables that are stored in each CRE. One is the Actor name from the area where the creature is instantiated, and two other exist in their own fields in the CRE structure. IWD2 appears to have only 2 death/scripting variables (the actor name and one field in the CRE structure). Leaving he Actor name variable aside, the other variables have the property that they're incremented every time a creature dies. IWD1 takes advantage of this to figure out if you've completed a quest (you've cleared all he monsters when the death variale is greater than some number). It appears as though IWD2 tries not to use the death variables but instead will create an if statement for each Actor in question to see if they are dead (I personally think this is easier to follow as you don't have to examine the CRE file to figure out what's going on). I think the dialogs will convert over without a problem. Magic user conversions are going to require some thought. Most spells can be mapped to counter parts, and I think I can fudge the rest. The important thing is to make sure the enemy AI will be sufficiently manacing with the resulting spell table.

Welcome to the IWD1Tutu forum! I'll try to introduce this mod in the form of a FAQ. So, what is IWD1Tutu? IWD1Tutu is an attempt to convert the IWD1(HOW/ToTL) game so that it can be played on the IWD2 game engine. So, um, why would you want to make a mod like IWD1Tutu? My personal reasons for wanting to work on this mod admittedly stem more from what I don't know than what I do know. As a player, I grew to like the IWD2 game engine with it's nice interface features, and I grew to like their implementation of the 3E rule set. But I definitely lack the perspective of a seasoned modder who could possibly enumerate the many reasons not to favor the IWD2 game engine. The IWD games in general do not have the role playing dimension of say the Baldur's Gate series of games, and the game engine lacks the capacity for joinable NPC's and inter-party dialoging. But these features are not to be expected in the IWD series of games which focus more on the immersion into the depths of a single artfully depicted story line rather than offering a myriad of role playing possibilities. Hey, hasn't something like this been done before? What about BG1Tutu or IWG2? How about an IWD1 to BG2 conversion? Absolutely, yes! In fact, IWG2 is the origin of these other "total conversion" project (including IWD1Tutu), and this was formed when Wes Weimer got the idea to try and convert the BG2 game so it could be played with the IWD2 game engine. The task was fraught with difficulties as the two game engines are quite different. IWD2 can not handle joinable PC's or inter-party dialog very well and the conversion of the 2E rule to 3E was problematic. BG1Tutu was formed when Japheth decided to take the IWG2 code and adapt it so BG1 could be played using the BG2 engine. The project proved to be a great success, and many people (myself included) have enjoyed playing this new version of BG1. I've heard whispers here and there about an attempt to convert IWD1 to BG2. I have the impression that the differences between the two game engines proved to be insurmountable. (One specific example is that the SetBit/GetBit actions/triggers do not exist in the BG2 engine). This sounds great and I'm ready to install the mod, where do I begin? I'm afraid to say that there is no place to begin yet. This project is only at it's very beginning and there's not much there yet to work with. Oh, okay, well what will I need to play this full conversion whenever it happens to be ready? You will have to have Icewind Dale, Heart of Winter with the Tales of the Luremaster expansion installed (IWD1/HOW/LoTL) as well as Icewind Dale II (IWD2). Both should be installed with the "full" options so that resources are not loaded off the CD's when you play the games. The "total conversion" mod itself will be a WeiDU type of package that you can download and run after reading and following the directions quite carefully. How long do you think it will take for this mod to reach a point where I can play it? I honestly don't know. I'm not even completely sure this project will succeed. There are many little road blocks, and so far I've only been able to take care of a few of them. I'll certainly shoot up a flair when I start to see a little light at the end of the tunnel (even though that might not make any sense). So, how is this mod being created anyway? The mod is based entirely on Wes Weimer's "weimorph" which is distributed with the WeiDU source code. Weimorph is the original program used for the IWG2 mod. The code includes many hooks for adapting BG2 resources to IWD2, and includes some impressive conversion operations which have been very informative exercises for me to work through. Like IWG2, the mod is comprised of a driver program (which is adapted from weimorph) and a set of auxillary "rules" and configuration files which are used to specify such things as resource mappings and installation directories. Hey, how can I help? Wow, that's a question I always like to here! At the moment, I think I'm on my own until I can get a basic framework hacked together. Then a lot of things will need to be added on. I've been trying to keep notes as I continue along, but these aren't organized very well at the moment. Early on I think I could really benefit with the help of another WeiDU/Ocaml programmer, but I think the long term work will mostly be related to scripting and item creation, modification or adaptation. How's it going? Where are you at with this thing? I'll try to keep a status log on this forum and update it as often as I can. Stay tuned!