DavidW

Hmmm, good point. I'll look at it.

What bug is this fixing? Hundreds of creatures are assigned NO_CLASS; there's absolutely no reason to think this is unintentional on the developers' part; changing it fixes no bug that I can see, and risks disrupting some script. It's somewhat more plausible that the assignments of CLASS=0 are errors, but there too I don't see any actual bug being fixed, and there too there is a risk of disrupting a script. Freeing up space in class.ids might be helpful for some megamod install, but that doesn't make it a bug.

(TL;DR: leave IWDEE alone. Change BG2EE to GENERAL=MONSTER, RACE=SHAMBLING_MOUND, CLASS=NO_CLASS. Change BPSHAMB from BGEE to RACE=SHAMBLING_MOUND, CLASS=NO_CLASS, and either (a) change BPSHAMB to GENERAL=PLANT and give it bplant.itm, or (b) leave its GENERAL unchanged.) OK, on the specific question here: 1) For reasons I've already given, I attach basically zero weight to consistency between the games, absent demonstrated developer intent to achieve consistency. 2) There is no actual overlap between any of the three games here. The BG2EE shambling mounds present in BGEE/SoD are unused in the unmodded game (one of them is summoned by a trap in Watcher's Keep, one of them is used by a BG2-only magic item.) 3) The GENERAL, RACE and CLASS categories are not lore descriptions visible in-game to the player; they are technical categories used by spells and scripting. What matters is that they are assigned to produce the right in-game effects. (Nothing observable would change if you text-swapped 'MONSTER' for 'MISCELLANEOUS_ANIMATE_ENTITY' in the game, for instance.) With that said, looking game-by-game: (i) In IWDEE, shambling mounds are GENERAL=MONSTER, RACE=SHAMBLING_MOUND, CLASS=NO_CLASS. That's a slight tweak from oIWD, where they're RACE=MYCONID. I assume that's a deliberate change so that shambling mounds (which are plant creatures but not fungus creatures) are not affected by the undead-or-fungus targeting of the Sunbeam spell. In any case I don't see any bug here, so no need for change. (ii) In SoD, the SoD-added shambling mounds are GENERAL=PLANT, RACE=SHAMBLING_MOUND, class=None. I don't see any problem there, nor anything that needs fixing. It's slightly odd that they have class=None rather than class=NO_CLASS, but that's either (a) harmless, or (b) actually targeted by some bit of scripting in SoD, in which case changing it would be disastrous. In any case, there's no need to change it, so there is a need not to change it. (The decision to add a new GENERAL category to SoD, incidentally, is not one I would have made, since I think it's a bit dangerous, but obviously they did make it.) The BPSHAMB shambling mound is GENERAL=MONSTER, RACE=ELEMENTAL, CLASS=ELEMENTAL_EARTH. Note that this is fairly good evidence that Beamdog (as of the original EEs, not as of SoD) thought shambling mounds ought to be categorized as MONSTER, since this creature is clearly adjusted from the oBG2 shambling mound. It is probably harmless either to leave or to change the RACE/CLASS entries (I don't see any scripting sensitive to it - some scripts check race=ELEMENTAL but they're not used by creatures that will encounter BPSHAMB). If it would please people's aesthetic sensitivities to change BPSHAMB to RACE=SHAMBLING_MOUND, CLASS=NO_CLASS, go for it. After SoD, Beamdog roll out sensitivity to the 'plant' GENERAL category into their scripting for NPCs. The concrete effect of changing the GENERAl category for BPSHAMB from 'MONSTER' to 'PLANT' is that various NPCs will change their targeting. Imoen, for instance, will not cast Confusion on PLANTs. Now, BDSHAMB is actually immune to confusion via the 'bplant' item, but BPSHAMB is not. My feeling is that it is reasonable to suppose the devs intended this to apply to plants in general, and so to change BPSHAMB to PLANT and give it bplant.itm. But we should do both or neither. This is an example of my (3) above: what matters here is not whether 'PLANT' feels a better 'fit' than MONSTER, but whether 'PLANT' actually interfaces correctly with AI and spell targeting. (iii) in BG2EE, shambling mounds are GENERAL=GIANTHUMANOID, RACE=ELEMENTAL, CLASS=ELEMENTAL_EARTH. Several things are sensitive to ELEMENTAL in BG2EE, and shambling mounds clearly aren't intended to be elementals, so this should be changed (it might as well be to RACE=SHAMBLING_MOUND, CLASS=NO_CLASS). No creature in BG2EE is assigned general=PLANT, of course. In oBG2, the category doesn't even exist. In oBG2 terms the clear category for Shambling Mounds would be MONSTER, and I think it's reasonable to see GIANTHUMANOID as a mistake. So the oBG2 fixpack ought to change it to MONSTER. Moving to the EE, the PLANT general type exists in BG2EE scripting only through AI scripts imported from SoD, which as it stands do nothing. And quite a number of scripts in BG2EE reference the MONSTER type. I think it is actively dangerous from a scripting POV (to say nothing of what it might do to mods) to shift shamblers over to the PLANT category in BG2EE. And it's pretty clearly not developer intent. From a resource perspective, the only place (afaict) that the game references plants is the Horrid Wilting spell, which has an unimplemented -2 save penalty to plants. But we can implement that keyed to RACE=SHAMBLING_MOUND and RACE=MYCONID. We don't need something as sweeping as a new GENERAL to address something as specific as a single-spell save penalty.

Leaving aside SoD (which I don't know so well), the baseline games fairly consistently use only 5 GENERAL values: Humanoid, GiantHumanoid, Animal, Undead, Monster. The first four of those are tied to specific in-game resources (though I can't offhand think of one tied to GiantHumanoid, to be fair... but I think there's one somewhere). You can interpret the fifth as 'miscellaneous': if something isn't affected by Charm Person, Charm Animal, or Hold Undead (and isn't a giant humanoid!) it's a monster.

So: the underlying design assumptions of the Fixpack are absolutely up for debate but the design assumption we're currently using (following the BG2 fixpack) is: developer intent, i.e. something is a bug if it is not working the way (we can reasonably surmise that) the developers of the game wanted it to work. I'll use umber hulks as an example again. In PnP,, they have a gaze attack that causes confusion. In BG2, Bioware implemented this by getting them to cast HULK_CONFUSION, a single-target confusion spell, once per round. In IWD, Black Isle implemented it by getting them to cast the self-targeted spell INNATE_UMBER_HULK_GAZE, which is basically an aura effect that causes any creature coming in close proximity to the Umber Hulk to be targeted by confusion. Both of these are perfectly defensible implementations of a PnP mechanic within the limitations of the Infinity Engine, but more importantly, there's no reason to think either is working other than as-intended by the respective developer teams. So I wouldn't say that either of them should be adjusted by a bugfix. When the Enhanced Editions come out, we now have the same studio working on both games. And Beamdog could have had an explicit design goal to unify the mechanics of the two games so as to work the same way. If they did, but umber hulks were missed out, arguably one or other implementations would count as a bug. But it is completely clear that Beamdog made no adjustments to IWD mechanics simply in order to conform to BG2, or vice versa. (That's obvious just by looking at the files, but I can also speak from experience as one of the people involved in IWDEE.) So: mismatches between how a creature functions in IWDEE and in BG2EE aren't bugs, by the developer-intent definition of 'bug'. It is perhaps worth stressing here how widespread and sweeping the differences are between the rule systems in IWDEE and BG2EE. Many, many spells operate differently; many classes have different abilities; mage opposition schools are different; all manner of creatures, from beholders to umber hulks to salamanders to liches, function quite differently. It's far deeper than just artwork: these are fundamentally different implementations of AD&D (or an AD&D/3e hybrid) on the infinity engine. There are perfectly good mods to be made that take IWD rules and port them to BG2, or vice versa. (Indeed, IWDification, which I co-authored, is one such mod.) But they'd be mods, not components of a fixpack.

COPY_EXISTING "slaver1.cre" override LPF ADD_CRE_ITEM_FLAGS STR_VAR item_to_change=CHAN04 flags=UNDROPPABLE END

I don't think consistency between the games - especially between IWD and the two BG games - is an appropriate design goal for a FP. They're different games, and (at least if we're talking about content that's come through unmodified from the pre-EE games) they had different developers. Insofar as those teams made different judgement calls about how to implement D&D concepts, there's no reason to standardize them. (Similarly, umber hulks and beholders are implemented very differently in IWD from BG2. But that's not a bug.)

Are you David? Didn't think so. Still, I suppose I've noticed it now.

I think it’s reasonable, at least for dragons. The idea of improved invisibility is that after you’ve attacked, enemies know roughly but not precisely where you are. Dragons have such good senses that they know that even before you attack, as Bilbo Baggins could testify. It’s not a perfect argument, I concede: after all, dragons can also target you with single-target spells.

The bears summoned by Conjure Animals (bearposu.cre) have cbear as a script (this is normally only for non-summoned bears) and lack the standard bdsum00 summons script). (Compare beargrsu.cre).

The IWDEE version of Unholy Blight is described as giving -2 to saves, attack rolls, and damage rolls. The actual spell grants -2 to saves, attack rolls, and AC. I'm inclined to think that the description (which goes back to oIWD) is correct and the spell should be changed to fit. The BGxEE version of Unholy Blight describes itself as giving -2 to 'all rolls' but doesn't reduce damage. That's more borderline. The IWDEE version displays the string 'weakened' but doesn't display an icon, contra the normal principle that any effect on the character is labelled by an icon. There is, however, no 'weakened' icon iirc. One could use the 'enfeebled' icon, or clone that icon to a new 'weakened' icon. The BGxEE version neither displays a string nor provides an icon: it just silently weakens the character. Incidentally, I think extant FP code already rebuilds BGxEE's Unholy Blight to work IWD-style rather than through a pile of 177s, so any fixes here need to go after that.

OK, checking it out: the t-add_spl_itm_header function at that link is broken, and doesn't calculate offsets correctly. Try this as a demonstration: CREATE itm dwtest LPF t-add_spl_itm_header INT_VAR t-atk_type = 3 END //LPF ADD_ITEM_EFFECT END If you look at the file in Near Infinity, you'll see that the first effect index in the new ability header is 114 rather than zero. If you uncomment the ADD_ITEM_EFFECT line you'll get an install-time error.

One thought: ADD_ITEM_EFFECT by default only adds to header type 3 (magic). Any chance your item doesn't use that header type?

SCS does something roughly like this, at least with Mislead. The teleport field is an interesting extra twist though.

Energy Blades (eneblade.itm) do slashing damage, but the spell description (and, in BG2EE, the item description) says they should do missile damage.

Test it on your party members.

It works fine for me with the default no projectile; code here. DEFINE_PATCH_FUNCTION weapon_damage_by_class INT_VAR header=0 // the weapon header to which the effect is applied probability1=100 // the probabilities for the effect to be applied probability2=0 STR_VAR class="" // the class which gets the effect (from class.ids) spell="" // a spell which is cast on the target on a successful hit, but only if the wielder is the correct class BEGIN LPF ADD_ITEM_EFFECT INT_VAR type=99 header probability1 probability2 opcode=326 target=1 timing=1 parameter1=IDS_OF_SYMBOL (class "%class%") parameter2=105 STR_VAR resource="%spell%" END END CREATE spl dw-dagg INNER_PATCH_SAVE ab_data "" BEGIN // add new ability INSERT_BYTES 0x0 0x28 WRITE_BYTE 0x0 1 WRITE_SHORT 0x2 4 WRITE_BYTE 0xc 1 WRITE_SHORT 0x22 1 WRITE_SHORT 0x24 1 WRITE_SHORT 0x26 1 // projectile = None END WRITE_SHORT 0x68 1 WRITE_LONG 0x6a 0x9a INSERT_BYTES 0x72 0x28 WRITE_ASCII 0x72 "%ab_data%" LPF ADD_SPELL_EFFECT INT_VAR opcode=12 // damage target=2 timing=1 parameter2=0x10000*0x10 // piercing parameter1=5 // base damage dicenumber=1 // variable damage dicesize=4 END COPY_EXISTING "dagg01.itm" "override/dw-dagg.itm" LPF weapon_damage_by_class STR_VAR class=MAGE spell=dw-dagg END

This works, I think. 326 on the weapon, to cast a spell carrying the intended payload, gated to only work if the caster is the requisite class. (#326 targets the original target even with target=self, but it does its 326 check on 'self'.) /* This function modifies the current item (assumed to be a weapon) so that its attacks have an additional effect if the wielder has a specific class. */ DEFINE_PATCH_FUNCTION weapon_damage_by_class INT_VAR header=0 // the weapon header to which the effect is applied probability1=100 // the probabilities for the effect to be applied probability2=0 STR_VAR class="" // the class which gets the effect (from class.ids) spell="" // a spell which is cast on the target on a successful hit, but only if the wielder is the correct class BEGIN LPF ADD_ITEM_EFFECT INT_VAR type=99 header probability1 probability2 opcode=326 target=1 timing=1 parameter1=IDS_OF_SYMBOL (class "%class%") parameter2=105 STR_VAR resource="%spell%" END END /* Example: this daggger casts Magic Missile on-hit, but only if the wielder is a mage. */ COPY_EXISTING "dagg01.itm" "override/dw-dagg.itm" LPF weapon_damage_by_class STR_VAR class=MAGE spell=SPWI112 END You just need to supply a spell that does however-much extra damage you want.

The actual list of 'cast previously' spells is in caster_shared/prebuff.2da. I can see the case for scripts treating remove fear as a prebuff. (But yes, conceptually I was thinking of it as an in-battle counterspell.)

I’d be inclined to, yes.

Things like that are almost always leftover relics from a copy/paste.

That goes back to oBG2, and I agree: surely a bug in both cases. (FWIW there is no listed difference in the PnP material: both creatures are listed as immune to illusions.)

As I say, I think it’s bad pedagogy. I meant ‘faster to code’ (and easier to read). (If WEIDU supported non-procedural function calls, it would be different.)

I should look more carefully then. (You link to it in my immutability thread and say there that it's an implementation of my method: I took you at your word ) It's not wrong: the link I give connects to the github page. (I prefer the biggdu link because you can get more conveniently at the changelog and readme.) I think that's overkill: indeed VARIABLE_IS_SET needs to be used with caution (I wouldn't normally put it in a library function, for instance) but in many applications it's in practice safe, and it's significantly faster. (As for the guide, I don't want to discuss functions at that point in the guide since they haven't been introduced yet, and I don't want to have people having to rely on my function library in it.)

Perfectly fair.