Effect Immunities on the EE Engine (aka Taking Full Advantage of the EE Fixpack)

[kjeron]

1 hour ago, Galactygon said:

There's a different method not yet mentioned in this thread of using external child status .effs using a commonly-agreed list of msectypes instead of child status .spls which might even be viable in BG2o (non-EE). It would be less clutter-intensive for sure since you only need to create a number of .effs for different graphical effects (i.e. #hold01.eff, #hold02.eff, etc), rather than one child spell per spell. Also, you might not even need to farm out status removal into child removal spells since you can use opcode 221 instead

EFF files can only be removed via their own msectype if they are applied via op248/249/272.  When maintained via op177/283 this does not work in the EE's.

1 hour ago, Galactygon said:

Too bad opcode 321 doesn't (iirc) selectively dispel external .effs that have matching parent resource field (0x94) set - perhaps this can be changed in the future?

EFF files maintained via op177/283 can only be removed based on their opcode, no other field checks work (msectype, school, dispel, parent).

EFF's would be a far more ideal method, if removing them was easier.

Edited June 27, 2023 by kjeron

[Galactygon]

You are correct, my bad. I have remembered wrongly. Msectypes, mschools, and parent resource fields in the .effs are ignored for selective effect removal effects (opcodes 220, 221, 321). Perhaps @Bubb has investigated this before?

[Bubb]

Not sure if I follow the entire conversation, but I can elaborate on how the EFF opcodes work.

op177 - CGameEffectApplyEffect              - Checks for immunities to EFF         - Drives Effect
op182 - CGameEffectApplyEffectEquipItem     - Does not check for immunities to EFF - Drives Effect
op183 - CGameEffectApplyEffectEquipItemType - Does not check for immunities to EFF - Drives Effect
op248 - CGameEffectMeleeEffect              - Checks for immunities to EFF         - Adds Effect
op249 - CGameEffectRangeEffect              - Checks for immunities to EFF         - Adds Effect
op272 - CGameEffectRepeatingApplyEffect     - Checks for immunities to EFF         - Adds Effect
op283 - CGameEffectCurseApplyEffect         - Does not check for immunities to EFF - Drives Effect

"Driving" the effect means that the .EFF is never actually added to the creature. The driving opcode directly invokes the driven effect's ApplyEffect() function. This means that .EFF files applied via "driving" opcodes cannot be seen by other opcodes, (as they don't exist on the creature). There is one, and only one exception to this: op337 has special casing that considers op177's driven .EFF file.

op248, op249, and op272 add the .EFF to the target – normal rules should apply.

EEex can target driven effects of course. However, that's not a valid solution for the fixpack.

[kjeron]

4 hours ago, Bubb said:

There is one, and only one exception to this: op337 has special casing that considers op177's driven .EFF file.

All (or at least most) of the opcode-specific "Cure/Remove X" opcodes can see enough of the EFF file to remove the driving opcode. (2, 4, 11, 46, 47, 48, 64, 70, 75, 77, 79, 81, 116, 136, 160, 161, 162, 163, 164, 212, 224, 240, 242, 266, 270, 279).  Like op337, they all primarily look to match the EFF's opcode.  If they don't have the same exception, maybe theirs is coded elsewhere (them being original, not EE-exclusive like 337).

[Bubb]

Yes, they all use the same internal function that includes the op177-specific check. To my knowledge op337 is the only general-purpose opcode that includes the behavior – that's why I called it out. Probably should've mentioned the others. It's safe to say that when the engine goes to remove one / all instances of a specific opcode id, it will correctly handle op177.

[Galactygon]

What I'm referring to is how opcodes 220, 221, and 321 do not "look inside" driven EFFs and selectively remove them if the EFF's msectype, mschool, and parent resource fields are set. Whereas any immunity/bounce opcodes (i.e. 202-7, 223, 226-8, 318, 324), can selectively target and block or even bounce those EFFs without affecting other effects in the extended header not called via opcodes 177/283.

Edited June 29, 2023 by Galactygon

[Luke]

@Galactygon

I'm working on EEex and trying extending the op24 feature of bypassing / ignoring op101 to some other opcode (notably op39 and op128). I'm talking about the fact that op24 can bypass op101 if param2 is set to non-zero (this is relevant for IWD:EE Chill Touch, which is supposed to cause fear in undead, but undead are normally immune to op24...).  In so doing:

• special spells such as CLERIC_FALSE_DAWN can properly confuse Undead (that are normally immune to Confusion)
  • in addition, there is no need to update existing .spls / .itms that provide immunity to Confusion
• Knockdown / Nausea can properly bypass / ignore Chaotic Commands and the like
  • In this case however the centralized spl file ("#cureslp") should not blindly use op2 (Cure sleep), since you are not supposed to cure / dispel neither Nausea nor Knockdown (unless I'm missing something...) Instead, it should apply a list of op321 effects targeting only Sleep / Unconsciousness (can be automated by checking for op39 whose param1 is 0...)

Can this be of some help...?

Edited June 29, 2023 by Luke

[Galactygon]

You don't need EEx for any of that. You can use opcode 183 to bypass undead resistance for Chill Touch (just found out!). Set parm2 to 0x10 to look for a ring, since undead have RING95.itm equipped. This and similar undead-centric effects should be possible to do for Fixpack.

Knockdown that bypasses 101 is trickier since you need to look for many item types (i.e. 0x1c, and other weapon types).

Edited June 29, 2023 by Galactygon

[Luke]

47 minutes ago, Galactygon said:

since undead have RING95.itm equipped.

What if immunities are defined as CRE effects...? Yes, most immunities are attached to special undroppable gear (see f.i. "ring95.itm"), but there might be cases (mods) where they are attached as CRE effects... op183 would not work in this case... Moreover, this solution sounds a bit hacky to me...

Having said that, you might opt for op182 (since in this case you can check specifically for "ring95" instead of any ring). However:

1. This opcode is bugged (see IESDP; fwiw, I've already fixed it in EEex)
2. there is still the issue of immunities directly attached to the CRE file

So to sum up, I think replicating op24 feature is a more elegant solution... Am I missing something? Yes, sure, that would mean that only Windows players would benefit from it, but at least it's something robust (hopefully)...

Edited June 29, 2023 by Luke

[kjeron]

1 hour ago, Galactygon said:

You don't need EEx for any of that. You can use opcode 183 to bypass undead resistance for Chill Touch (just found out!). Set parm2 to 0x10 to look for a ring, since undead have RING95.itm equipped. This and similar undead-centric effects should be possible to do for Fixpack.

Knockdown that bypasses 101 is trickier since you need to look for many item types (i.e. 0x1c, and other weapon types).

Or use op283 for the EFF, as it also ignores immunity.  Does it really matter that remove curse will remove it?

[Luke]

11 hours ago, kjeron said:

Does it really matter that remove curse will remove it?

Yes, it does...? I mean, you can abuse Remove Curse to remove effects that are not supposed to be removed ...

[polytope]

14 hours ago, kjeron said:

Or use op283 for the EFF, as it also ignores immunity.  Does it really matter that remove curse will remove it?

2 hours ago, Luke said:

Yes, it does...? I mean, you can abuse Remove Curse to remove effects that are not supposed to be removed ...

In my tests it almost never mattered for sleep/knockdown/unconsciousness which seems the most contentious (being that with EE opcode #24 can selectively bypass immunities in its own right).

If someone gets knocked down by a wing buffet/Dragon's Breath spell they'll be sent flying across the area, Remove Curse is a touch range spell with a casting time of 6 for priests, 4 for wizards, by the time you've walked your spellcaster over to them to remove it the knockdown has most probably worn off.

Stinking Cloud, on the other hand, if you want to use #283 as a sleep-immunity bypassing helplessness (I'm not so sure, besides Chaotic Commands I think plenty of sleep immune critters would also ignore a SC, so needs an additional #324 in the spell's feature block or a #206 in their cre file)... Removing Curse would change little, they'll need to save again next round if they're still in the cloud.

As for the longer duration disabling effect of Comet and Bigby's Crushing Hand, need to decide if we still want sleep or a sleep variant as the implementation, rather than stun/hold, as it once was.

Any arcane spellcaster, of course, can set a Contingency:Helpless -> Remove Curse, but it's quite situational and unpredictable.

Edited June 30, 2023 by polytope

[kjeron]

3 hours ago, Luke said:

Yes, it does...? I mean, you can abuse Remove Curse to remove effects that are not supposed to be removed ...

For chill touch and similar "Undead centric" effects though, how many enemies are going to cast Remove Curse, considering they cannot detect curses?

Hexxat would be the main issue IMO.

[Luke]

On 6/27/2023 at 10:57 PM, kjeron said:

EFF's would be a far more ideal method, if removing them was easier.

Before I forget (quoting your own thread):

• Opcode 337 (remove effects by opcode) would falter against these
• Opcode 198 (reflect specified effect) would falter against these
  • I know this opcode is (partially) bugged and rarely used (if we do not consider mods), but still worth mentioning...

[kjeron]

6 hours ago, Luke said:

Before I forget (quoting your own thread):

• Opcode 337 (remove effects by opcode) would falter against these
• Opcode 198 (reflect specified effect) would falter against these
  • I know this opcode is (partially) bugged and rarely used (if we do not consider mods), but still worth mentioning...

Op337 has since been fixed, it works fine in v2.6.6.0.

IIRC, the issue with op198, in relation to op177, is that it will reflect the EFF using the "Impact Projectile (0xa0)" specified in the EFF, not the spell's projectile, which would prevent the EFF from being shared by multiple spells.

Edited June 30, 2023 by kjeron