DavidW

Vanilla BG2 uses opcode 50 for cosmetic effects but BG2EE uses opcode 61. Since you want all the effects to be patched to target=2 (unless you've added something else yourself?) you may as well leave out the match_opcode. If you don't say anything, ALTER_EFFECT matches everything. It's also a bit easier to use IDS_OF_SYMBOL to check if an entry is in spell.ids rather than using a regexp, like so: PATCH_IF IDS_OF_SYMBOL (spell CLERIC_IRONSKIN)>=0 BEGIN ... END

[not bug/no action]

(I'm assuming a general framework for thinking about opcodes 109, 175 and 185 which I laid out here.) This one is a stretch. I'll put it out there, but if it's too much for a fixpack, fair enough. Certain attack spells - specifically Implosion and the Bigby's Hand spells - physically confine the target in a damaging region and play an animation to show that. But if the creature is really huge - dragons are the obvious example - this looks stupid, because the animation is far too small to cover them. This is something the BG2 designers are often quite alive to - dragons don't use Globe of Invulnerability, for instance, and they have their own bespoke versions of Spell Turning and Stoneskin precisely because the animations for those spells are too small for dragons. But they didn't get caught in this case (these are all ToB additions, and probably got less playtesting). In addition, the immobilizing effect doesn't work on dragons, as they're immune to the relevant opcode (changing to 185, as I've suggested elsewhere, for these spells doesn't work, as they're immune to 185 too) so that they can just wander out of the animation, which looks even sillier. Left to myself, I would grant really large creatures straight immunity to these effects, via a 318 conditioned on their circle size. (I advocated something similar here for Otiluke's Resilient Sphere, but that's just cosmetic. This obviously does have an in-game effect.)

(I'm assuming a general framework for thinking about opcodes 109, 175 and 185 which I laid out here.) In classic BG2, the Hand spells freeze the target rigid with a no-save Hold effect (opcode 175) and then wrap an animated hand around them and inflict damage. In the EE, the Hold effect has been replaced with a Sleep effect. This changes the spell's tactical usefulness (different creatures are immune to the two effects), doesn't really match the description, and frankly looks a bit stupid (your character drops to the bottom of the hand and lies there, rather than being trapped in it). I suggest reverting to a Hold opcode. My only hesitancy is that this was quite clearly a deliberate change in the spell by Beamdog, and I'd ideally like to know why they did it before just concluding it's wrong: maybe it's working around some other awkwardness. Maybe Cam or someone knows? Although classic BG2 uses 175, I'm going to suggest we use 185: according to the general system for 109/175/185, that's the right opcode for an affect that prevents the character moving through physical barriers rather than paralysis. (Crushing Hand is more like Otiluke's Resilient Sphere than Hold Person). That's doubly necessary if we don't follow my suggestion here and revert the mass roll-out of 175 immunity in the EEs (come to think of it, maybe that's what's driving the change, though if so it's confused).

(I'm assuming a general framework for thinking about opcodes 109, 175 and 185 which I laid out here.) According to the original logic of paralyze/hold opcodes worked out in BG1, 'Hold Undead' should be implemented with opcode 175, using IDS to gate it to require GENERAL=UNDEAD. (This is the same pattern used in Hold Person and Hold Animal.) But Hold Undead is only implemented in BG2, and Bioware chose to use opcode 185 instead; that decision has persisted in the fixpack and into EE. I think this just reflects the fact that by BG2, Bioware was losing track a bit of the delicate system they'd built in BG1. It's *mostly* just me disliking inelegance, but it does have some consequences: if an undead character uses Free Action, Chaotic Commands or similar, they will not be protected from Hold Undead. I'm not sure if any enemy is scripted to use those effects, but in BG2EE there is a party-joinable undead character. *Probably* no-one is scripted to use Hold Undead on her, but... And of course there will be lots of ways this could happens in modded games. It also means that undead beholders can be affected by Hold Undead but ordinary beholders can't be affected by Hold Monster, which is a little weird and surely unintentional. (I don't think beholders should be immune to hold at all, but if they are it doesn't seem to make sense for undead beholders to lose that immunity.) I suggest shifting to 175 as the BG1 designers would have wanted. (This does assume we make the changes I suggest here and revert the EE addition of 175-immunity to ring95.)

(I'm assuming a general framework for thinking about opcodes 109, 175 and 185 which I laid out here.) The classic games are *very* sparing about granting creatures immunity to opcode 175. In BG1 it's *exclusively* for spells and items that grant Hold protection. BG2 extends it to some boss monsters (for whom hold effects can break scripting) and to dragons, beholders and kuo-toa (the last two don't make sense to me and I'll probably remove it in SCS but I'm not sure I can justify that in a fixpack). The EEs extend 175 very profligately. I haven't worked out their precise algorithm but I suspect that pretty much anything immune to 109 is now immune to 175. (Undead are immune to it, for instance.) That goes against the design architecture of original BG1, where 175 uses IDS targeting to avoid affecting certain sorts of creatures, and I don't see any good reason for it (note that the FP doesn't do it). The in-game effects aren't *all* that serious, but it does mean that Hold Monster doesn't affect many creatures (e.g. undead) that it used to affect, contrary to what happened in the classic games. It's possible there's some logic here that I'm missing (I'd welcome Cam's inside insight) but I strongly suspect that Beamdog had just lost track of what the intended logic of 109/175 was and thought they were just being careful. I suggest we strip out the extra 175s except where there's a clearly good reason and return to classic behavior.

(I'm assuming a general framework for thinking about opcodes 109, 175 and 185 which I laid out here) Actually, Otiluke's Resilient Sphere doesn't affect dragons and those bosses, except cosmetically: they're immune to opcode 185. But the cosmetic effects - the animation, in particular - still play, and the MGI animation looks silly on a dragon (and doesn't make sense, given it isn't actually affected by it.) I suggest we give DRAGRING 206 immunity to Otiluke's Resilient Sphere. (It's obviously not worth a spellstate.) I am also tempted to use 318 to prevent the sphere from affecting really large creatures in general, but maybe that's a bridge too far?

(I'm assuming a general framework for thinking about opcodes 109, 175 and 185 which I laid out here). Barbarian Rage makes you immune to paralysis, which is implemented (all the way back to vanilla BG2) by granting immunity to opcodes 109, 175, and 185. The first two are fine and harmless, but 185 is a special opcode used for physically immobilising effects and scripted (cutscene) effects. Immunity to 185 lets raging barbarians ignore Otiluke's Resilient Sphere (while still being surrounded by the graphic: presumably they bump the sphere into foes to attack them). It also means they can ignore the scripted paralysis effect in Hell (You no sell my soul, CHARNAME! Me raging!) We should just delete this: it's pretty clearly unintended and provides evidence that by ToB the design team was losing track of what their various paralyzing opcodes were for.

(I'm assuming a general framework for thinking about opcodes 109, 175 and 185 which I laid out here). Implosion immobilizes creatures by trapping them in a fiery chasm. It implements this with opcode 175 (Hold Creature). That means that Chaotic Commands and Free Action protect you from the immobilisation effect of Implosion. I submit this is a mistake: obviously so for Chaotic Commands (mental serenity does not help you climb out of a fiery chasm) and I suggest also for Free Action (it doesn't give you the ability to fly, walk through walls, or escape from Otiluke's Resilient Sphere: I think it protects you from things that affect your movement directly, not physical barriers). It also looks silly cosmetically: if you can walk out of the fiery chasm, then it just stays there for six seconds looking pretty, and not affecting anyone else who wanders into it. And from a balance point of view, Implosion isn't all that powerful, and 1 round of guaranteed hold that can't be countered is an improvement, though for a fixpack I don't think that's a major consideration. (This is, incidentally, a BD change. Bioware used 109, which meant that undead weren't caught in the chasm. BD's change is clearly for the better but I think it's still not working as intended. I think there is fairly good evidence that BD had lost track of the 175/185 distinction so that their choice of 175 over 185 doesn't indicate developer intent.) I suggest this is a case where we should use opcode 185, which is supposed to represent physical immobilizing effects and which almost nothing is immune to.

(I'm assuming a general framework for thinking about opcodes 109, 175 and 185 which I laid out here) Quite a lot of creatures are supposed to be immune to Web, but Web implements opcode 109 and so often that leads to immunity to opcode 109. This isn't necessary (Web doesn't need to apply 109 in the EE, since 157, Web Effect, also applies a hold effect) and unnecessarily grants various creatures immunity to paralysis from other sources. A non-exhaustive list of creatures I think this applies to: - Kuo-Toa (immune to Web in PnP) - Wyverns (large enough to rip through a web, and to look silly if the web overlay plays on them) It actually doesn't apply to spiders and ettercaps, who get the ANTIWEB item: that *used* to implement 109 immunity, but in EE it instead gives immunity to the web *projectile*. That's ingenious but doesn't quite work: there are single-target web effects, like SPIN683, that don't use that projectile. In addition, ANTIWEB is carried by several Dryads: in BG1, the Hamadryad, DRYADHA; in BG2, the summoned Hamadryad and several BD nymphs. It's pretty clear that the BG2 fey only have ANTIWEB because they're clones of DRYADHA. What's less clear is why she has it. (There's no in-game or AD&D reason given.) My guess is that it was intended to be proof against Entangle (which DRYADHA casts and will entangle herself in), but I'm not sure (and BG1's spellcasting AI is systematically awful so it's hard to infer reliably that way). My suggestions: (1) Remove the 109 effect from Web spells (2) Remove immunity from 109 (and associated immunities to strings, icons etc) from Kuo-Toa, Beholders, Wyverns, and anything else we find that is being given 109 immunity as an accidental corollary of web immunity (3) Use IWD 318 tricks, applied to Web spells, to immunize anything with RACE=SPIDER, RACE=KUO_TOA, RACE=ETTERCAP, or circle size>[whatever size makes the web overlay look silly]. (Yes, I know I said here that we shouldn't import any of the IWD architecture into BG; this is an exception. A foolish consistency is the (Chill) hobgoblin of little minds. And I think this is better than burning a spell slot, which would be the other systematic way.) (4) *Slightly more tentatively*, remove Antiweb from fey. (5) *Even more tentatively*, replace the fey antiweb item with an immunity-to-entangle item.

I've just spent a couple of hours trying to understand the intended uses of opcodes 109 ('Paralyzation'), 175 ('Hold Creature'), and 185 ('Hold Creature 2'), all of which are pretty much functionally identical afaict - they all impose immobility and script-stopping, gated by an IDS check. Mostly I was looking at unmodded, unfixpacked, vanilla BG1 and BG2, where the original intention is clearer. (IWD is another matter and I haven't really looked at it yet.) Here I think is the underlying logic. (Summary: 109 represents innate paralyzing effects, though it also unnecessarily doubles up representing Web; 175 represents Hold spells; 185 represents things that fix you in place through some external mechanism.) 109 is used almost exclusively by items that cause paralysis, such as the undroppable weapons used by ghouls and carrion crawlers. The IDS check is rarely functional: you're affected by a 109 unless you have explicit protection from it. It is almost always associated with the 'Paralyzed' string. Many classes of monster - dragons and undead, for instance - are immune to it; you also get immunity to it from Free Action, Chaotic Commands, et al. Complicating matters, though, 109 is *also* used by Web spells, both in BG1 and BG2 (the 'mimic glue' effect in BG2 also uses it). This is actually unnecessary, at least in EE: the web effect (opcode 157) is invariably associated with Web, and it imposes the paralyzation condition all by itself. However, it's clear that Bioware *didn't know that* and thought 157 was cosmetic (and they may have been right: I'm not sure whether this is EE behavior). There are quite a number of places in BG1 and BG2 where it is fairly clear that creatures are given 109 immunity because they are supposed to be unaffected by webs. (It's fairly clear for wyverns, which have no obvious lore reason not to be affected by paralysis (and are big enough to look stupid when Web Effect Overlay plays over them) and have an item that blocks 109, 157, and Entanglement effects; it's equally clear for Kuo-Toa, who get similar immunities to implement their PnP slipperiness trait; it's probably true for Beholders, who can presumably float above webs but have no obvious canon reason to get paralysis immunity.) 175 is used pretty much exclusively by paralyzing spells, almost always labelled 'Hold' (Tanar'ri paralysis is an exception) and is almost always associated with the 'Held' string. Creature immunity doesn't normally affect it: you get immunity to it through situational things like Free Action. 185 is used *very* rarely, and very few things are immune to it. In vanilla BG1, *nothing* is immune to it, and the *only* spell or item which uses it is Otiluke's Resilient Sphere. I think the underlying idea is that 185 represents things that physically prevent you from moving, but through some external barrier rather than directly slowing or freezing you. (On this basis, players should never be immune to 185, and probably only minhp1 items should grant it, to avoid the usual scripting problems. In BG2, however, I think the logic of this breaks down quite badly: boss monsters get immunity to 185, but it gets granted by some items/spells that really shouldn't grant it (some but not all fixed in FP or EE). I think the designers kind of lost track of what they'd intended. They also use 185 to double up as a cutscene can't-be-blocked effect (e.g. HELL_HOLD), but that is (or should be!) harmless since players shouldn't be protected from 185 anyway. I think the designers lose track of this general scheme a bit in BG2, and slightly more in the Enhanced Editions, but I think it's probably what we should be running with. I'm going to post a bunch of suggested bugfixes that rely on this architecture.

I was being selective given that splstate slots are an at-least-somewhat-scarce resource.(I did an automated trawl through all the 101 effects in BG2EE.) In this case, only one spell in BG2 gives immunity to op44, and its existing implementation looks fine without a spellstate. On reflection, they're not as good as I thought. SCS needs to distinguish between protections that are immediately obvious (e.g. don't charm undead) and protections that you can only discover through trial and error (e.g. don't charm people wearing Helms of Charm Protection). So I take back the 'AI advantages' point, although I'm still attracted to the overall elegance of the scheme. That's incredibly clever. I think I agree that it's too hacky to use in a FP, but the very fact that it can be done takes the pressure of splstate.2da and makes me somewhat more relaxed about grabbing a bunch of spellstates for FP.

Doing a quick automated audit in BG2, I think there would indeed need to be about 20 spellstates to implement that method of doing effect blocking: charm (6) haste(16) fear (23,24,106) unconscious (39,217) slow (40,210) stun (45) death (55,206) blindness (74) feeblemind (76) disease (78) deafness (80) fatigue (93) hold (109,175,185) confusion (128) petrification (134) polymorph (135) imprisonment (211) maze (213) energy drain (216) disintegrate (238) I am actually tempted - there are significant AI advantages - but it does rather depend on how much mods are using up splstate.ids - cf my other thread.

It would be good to know how severe the demands on spellstates actually are. There are 256 slots available, of which the vanilla game uses 133, leaving 123 free. My mods (mostly SCS, but also some upcoming projects) use maybe 30-40 of those. Does anyone have an impression of what other mods do? If actually the extant mods only use 50-60 in total, we could borrow a bunch for FP with impunity (which would simplify immunities); if there's real pressure on splstate.2da, of course we shouldn't. (It would be *really* nice if BD were willing to extend splstate to 2 bits in 2.7)

I think there are two factors here. (1) What feature of a creature actually codes its immunity to some effect? (2) Given an answer to (1), how do we implement that immunity? I'll use charm immunity for undead as an example. In BG2, what makes an undead creature immune to Charm is that it has ring95. In IWD, what makes it immune is that it has GENERAL=UNDEAD. In other words, in IWD it's immune simply because it's undead; in BG2 the fact that it's undead only matters through the developer's decision to give the creature ring95. Internal to the logic of BG2, undead aren't charm-proofed; only ring95-holders are. As I said in the earlier mail thread, these are two fundamentally different choices of immunity architecture, embedded *very* deeply into the respective games. There are defensible arguments for either, but I think it's a really bad idea to try rewriting the architecture of any of the games to this degree. I suspect Cam's compelling example of the Chromatic Demon would just be the tip of the iceberg. But even holding the architecture fixed, there are still substantive questions about how it is implemented. In the IWd architecture, there's not much choice: there is no way to attach effects to a RACE or GENERAL setting, so the only available implementation is to tell each appropriate spell and item to ignore creatures of that RACE or GENERAL, using 318/324. This is basically what IWDEE already does. It's more complicated on the BG2 architecture. There are 3 options: (i) Use 101 on the immunity item (ring95 in our example) to block the core effect, and then add a bunch of string/animation immunities to block associated strings/animations. (ii) For each spell/effect that implements the blocked effect (e.g. Charm), add that spell to the immunity item via 206. (Or 318; I don't think it matters.) (iii) Get the immunity item to set a spellstate (say, BLOCKS_CHARM), and then edit all spells/items that inflict the blocked event so as to add a 318/324 block keyed to that spellstate. Importantly, these are not mutually exclusive. I'm going to argue that we should always *at least* use (i) when it's viable. The absolutely-most-important feature of an immunity-to-charm option is that it blocks the charm opcodes. Secondarily, it needs to block the clearly-visible signatures of charm: the displayed 'Charmed'/'Dominated' strings, the icons, and the SPNWCHRM animation. Blocking other effects (e.g. sounds) is a very distant third. It is way too dangerous to rely on (ii) and (iii) to block the charm opcodes: even in the unmodded game I'd be nervous, but mods add vast numbers of new items and spells and there is no way to enforce that those mod items/spells add 206 to the immunity items *or* 318/324 to themselves. Blocking the relevant opcodes direct is the only safe option. BUT there is a perfectly good case for ALSO blocking the core spells directly via either (ii) or (iii): it addresses the sound-effect issue and any other stray effects, and it's harmless to double up. In principle I think (iii) (new spellstate set by the immunity item, spells detect the spellstate and self-block) is better: it's more elegant, clutters up the spell less, and is resilient against mods that clone the spell. However, the cost in spellstates is way too high: we'd need 20 or more. So (reluctantly!) I think in practice using 206 on the immunity item is better. However, for immunity *spells* there is an spellstate available already: the spellstate set by DS. There is no reason why, e.g., Charm Person couldn't just self-block if it detects the CHAOTIC_COMMANDS spellstate. (We can't, unfortunately, add that spellstate to ring95, because both SoD and mods like SCS assume that CHAOTIC_COMMANDS marks the specific - and dispellable/breachable - spell, not just generic immunity.) I think that move is more elegant for spells than adding a bunch of 206s to the spell (though I'm not super-sold on this.) Cam raises two special cases - Cloudkill and Song of Kaudies - but I think they fit in this general logical framework. The underlying issue is that the game contains no resource to designate a spell as Poison / Sound. So the relevant effect needs to sit on the spell itself: that's much cleaner logic than just calling out the spells to each relevant item. Doing so for Cloudkill, as Cam says, is easy: just do a 318/324 keyed to poison resistance. I agree that Sound needs a new spellstate, IMMUNE_TO_SOUND; then what marks something as a Sound effect is just that it does a 318/324 self-block if it runs into IMMUNE_TO_SOUND. I think this is a satisfactory reason to use up one spellstate slot; in general I think using up the odd one is fine, I just would want to resist a systematic policy that uses up dozens. Summary: - For IWDEE creature immunities, I don't think we should do anything - For BG(2)EE creature immunities, we should maintain the existing 101 blocks but should also add a 206 block to probably any vanilla-game resource; certainly any vanilla-game resource with sound effects. - For spells that grant immunities, we should use their DS spellstates/stats to directly block any vanilla-game resource (or, again, any vanilla-game resource with a sound effect). That means that we should after all include basic DS in the fixpack. - We should follow Cam's suggestions for Cloudkill and Song of Kaudies.

I am very pro following the same framework as the BG2 fixpack. I don't think there is any better standard available for bugs than developer intent, and I think the BG2 fixpack both interpreted what that means sensibly and sets a good precedent. So this includes fixing things like KIT.IDS => ASSASIN // should be ASSASSIN (two S) GENDER.IDS => NIETHER // should be NEITHER ...? But that would require adjusting scripts/dialogs as well... These aren't syntax errors. Assigning 'ASSASIN' rather than 'ASSASSIN' as the ids name for kit 0x400a is a dumb choice and presumably happened because someone at Bioware couldn't spell 'assassin', but it's perfectly legal syntax and doesn't need changing. (And doing so would break dozens of mods.)

Sounds good to me.

A return character other than %WNL%, perhaps?

It shouldn't - or rather, it should only be adding entries if they're not already present - but I wouldn't swear 100% that there's not some obsolete bit of code somewhere that's doing it more crudely.

Unintentional, and I couldn't reproduce it, but it's not as if I tried that hard. I'll have another look next time I update.

Siege of Dragonspear, unmodded, I think any recent version. (But actually I reproduced it on a different dialog - AEEXTORT in BG2 - so I think you can try it on any dialog you like.

In BG1 I think it serves a purpose to leave a few around, given that there are some monsters that can't be harmed by nonmagical weapons (and given that there are few enough magic weapons that finding one is cool).

I assume because someone told me IR already introduced high-quality weapons.

SCS does exactly what your * suggests, i.e. the default magic +1 weapons become high-quality, but there's copy made of each of them and the copies are placed in hand-picked locations. (Well, that's what happens in BG1. In BG2 I don't bother with the hand-picked placements since there are so many +2 and better items anyway.)

Can you check the unidentified name? Most magic items will have the name of the nonmagical version in that field. (If they don't have a recognized unidentifiable name, you could use a secondary heuristic.)