Jump to content


DavidWallace

Member Since 07 Aug 2006
Offline Last Active Jul 02 2021 01:23 PM

Posts I've Made

In Topic: A release

05 August 2020 - 06:18 AM

So what they actually did, was they brought the IWD into the BGEE engine via BG2, just like DavidW did with his mod. As it was their actual pre-alpha.

That's nearly right. I actually wrote the IWDEE alpha from scratch (it's not been publicly released) but it was very heavily based on v7 of IWD-in-BG2. The main differences were
(i) I took out all the hacky conversions of opcodes and projectiles, because I knew Beamdog would be able to sort those out at the engine level (that's where 318/321/324 come from, they're replicating very powerful IWD opcodes not in vanilla BG2).
(ii) I did a systematic remapping of strref entries. IWD-in-BG2 followed the TUTU/EET strategy of just appending the whole tlk file onto the BG2 tlk file, but that's ugly and bloated for a standalone game. For IWDEE, I wrote code to map the 3000-odd lines in BG2 used by non-game-specific resources (spell descriptions, etc) into unused strings at the end of the IWD tlk. If you compare IWD and IWDEE, their tlks are virtually identical up to 35,000 or so.

In Topic: A release

05 August 2020 - 06:12 AM

Jarno is right: it wouldn't have been viable. The BG2 engine has enormous amounts of functionality that the IWD engine lacks. The IWD engine is basically the BG1 engine with new opcodes (and, I think, less party support), whereas the BG2 engine is a significant expansion of the BG engine's functionality. For instance, PRO files and CLAB files are new as of BG2: in BG1 and IWD, projectiles and class abilities are hardcoded. And of course IWD doesn't have kits.

 

BG1TUTU is a *relatively* straightforward conversion because practically all the functionality of the BG1 engine is replicated in the BG2 engine - you just need a careful, systematic mapping of resources and tlk entries. IWD-in-BG2 is much less straightforward but it's possible - the extra work is mostly un-hardcoding the hardcoding content and hacking around the various new opcodes and the like. (And about a hundred other small-to-medium things, because the IWD engine evolved in lots of small ways from the BG2 engine, but I won't bore you with them - the point is, most of them could be worked around).

 

BG2-in-IWD wouldn't have been possible at all: far too much is missing. BG2-in-IWD2 (Weimer's 'Icewind Gate' project) wasn't quite so obviously impossible, because the IWD2 engine is much more powerful than the BG2 engine and incorporates much of its functionality, but it turned out not to be viable. IWD2-in-BG2 is probably viable (particularly given EE functionality) if you don't mind back-converting the rule system from 3e to 2e, but hasn't been done yet. (Beamdog obviously don't want to take a liberty as drastic as dropping the 3e system, which I think is why they haven't taken that route.)


In Topic: Detectable Spells

02 August 2020 - 07:17 AM

This is a fairly belated comment, because I mostly did it a year ago, but I've coded a new version of Detectable Spells (v4.0.1). You can download it from the SCS github repo (it's not in the most recent live release of SCS). Just put ds.tph somewhere in your mod folder structure, INCLUDE it, and then run the 'detectable_spells' function. It works on the EE games (though it's not all that sensitive to IWD) and on the classic ToB engine, with or without ToBEx.

 

This was a recode from scratch so I can't that easily describe fine-grained changes, but I think it's pretty solid (it's been loose in SCS and Ascension for a year or more without any bug being traceable to it). 

 

One of the main changes in this version is that it's radically easier to add detection effects to new spells, over and above the baseline ones included in ds.tph itself. But the use cases for that are relatively niche so ask me if you want them. (At the G3 version of this thread, for preference - I don't read this forum very often these days.)