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

[subtledoctor]

1 hour ago, Luke said:

It'd be much much easier if EE mods adapted to the new splstate system, there would be lots of benefits...

There are so many mods that are not "EE mods" but work on the EE games, and are not maintained. You could of course make something separate from the FixPack that implements this, and mods could conditionally support it by checking if your thing is installed. But TBH I just read the last page of this thread and I'm fairly conversant with this kind of thing, and I'm still not entirely clear on exactly what I would change in my mods. So I would expect uptake to be pretty low. Of course you could still do it, and simply limit yourself to the smaller universe of mods that support this system. But I would venture that the vast majority of players would rather have more mods available to them, and will suffer the occasional small glitch in exchange for it.

Why not make a separate mod that is meant to be installed last, which converts everything to use spellstates? Kind of the way Klatu's "Standardize ______" or the old lolfixer stuff is designed.

[Bubb]

9 hours ago, Luke said:

For @Bubb: apparently, EFF files applied by op283 can bypass / ignore op101. Bug or Feature...? Something else to know about it...?

I can't tell you if it's intended, but of all the opcodes that use EFF files:

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

You might be able to abuse the bugged op182; if you supply an empty ITM resref it should apply 100% of the time.

[polytope]

Quite possibly an oversight, but it's a good bug if so as it lets us use opcodes on creatures who'd normally be unaffected in specific cases where they should be. That said, for balance reasons, Earthquake's unconsciousness duration should probably be nerfed if we decide it's a physical knockdown that works on sleep immune creatures; because it otherwise effectively works as a mass save-or-die with a very harsh penalty of -6.

[Luke]

16 hours ago, subtledoctor said:

Why not make a separate mod that is meant to be installed last, which converts everything to use spellstates? Kind of the way Klatu's "Standardize ______" or the old lolfixer stuff is designed.

As I've already said, it might be problematic to tell if an op39 effect is, say, Unconsciousness or Knockdown, especially considering mod-added assets... Anyway, we now have an alternative method which is mods friendly...

15 hours ago, Bubb said:

You might be able to abuse the bugged op182; if you supply an empty ITM resref it should apply 100% of the time.

2 hours ago, polytope said:

Quite possibly an oversight, but it's a good bug if so as it lets us use opcodes on creatures who'd normally be unaffected in specific cases where they should be.

Yes, I think that for the time being we should rely on this bug... Just note that the various "Cure" opcodes only consider EFF files applied by op177, so in case the effect needs to be cured (CLERIC_FALSE_DAWN...?), you need to use op321 targeting the resref applying the op182 effect...

2 hours ago, polytope said:

That said, for balance reasons, Earthquake's unconsciousness duration should probably be nerfed if we decide it's a physical knockdown that works on sleep immune creatures; because it otherwise effectively works as a mass save-or-die with a very harsh penalty of -6.

Something like a 3-second unconsciousness each time the Damage opcode triggers...? That is:

• immediately after the spell is cast
• after 12 seconds
• after 24 seconds

Also, I would do the same with Shake Screen (it's currently applied via op272, and that means it's subjected to Haste / Slow... It does not make any sense to me... I'd apply 3 separate op269 effects...) and Play Sound (for some reason they are applied one second before the Damage opcodes...)

Finally, if it's gonna work on sleep immune creatures, then flying creatures and magically levitating creatures (Demilich, Mordenkainen's Sword, etc...) should definitely be immune to it (just add a 324 RACE check to all relevant SPL/ITM files...)

Edited July 30, 2022 by Luke

[subtledoctor]

14 minutes ago, Luke said:

it might be problematic to tell if an op39 effect is, say, Unconsciousness or Knockdown

Honestly: if the duration of the op39 effect is <13 seconds, call it knockdown; if it’s >12 seconds, call it sleep. 

[Luke]

5 hours ago, subtledoctor said:

Honestly: if the duration of the op39 effect is <13 seconds, call it knockdown; if it’s >12 seconds, call it sleep. 

Huh, I thought that knockdown was supposed to last much less, something like one round at best... In any case, abusing the bugged op182 is probably the best option as of now...

7 hours ago, polytope said:

...if we decide it's a physical knockdown that works on sleep immune creatures...

Now that I think of it, also attacks such as "Stinking Cloud" should work on sleep immune creatures (as well as any creature protected by "Chaotic Commands" and friends...)

In this particular case I would add 324 effects checking for STAT RESISTPOISON >= 100. Description speaks of "nauseous vapors", so I think it's perfectly fine for 100% Poison Resistance creatures to be immune to these attacks (as kjeron pointed out in some other thread...)

[polytope]

17 hours ago, subtledoctor said:

Honestly: if the duration of the op39 effect is <13 seconds, call it knockdown; if it’s >12 seconds, call it sleep. 

One notable exception: The priestly Command spell which is clearly mental rather than physical.

11 hours ago, Luke said:

Now that I think of it, also attacks such as "Stinking Cloud" should work on sleep immune creatures (as well as any creature protected by "Chaotic Commands" and friends...)

In this particular case I would add 324 effects checking for STAT RESISTPOISON >= 100. Description speaks of "nauseous vapors", so I think it's perfectly fine for 100% Poison Resistance creatures to be immune to these attacks (as kjeron pointed out in some other thread...)

Good idea, although, whilst protection from mind affecting magic shouldn't extend to Stinking Cloud I'm not sure that enraged berserkers and barbarians should be incapacitated by it (cf. pepper spray often failing to subdue sufficiently determined and furious or drugged attackers in the real world). Their rage associated immunities are a mess anyway and probably a subject for another time.

[DavidW]

Again, I think some of this is getting way outside the scope of a fixpack. I don’t see any in-game evidence that (e.g.) Chaotic Commands is not intended to protect from Stinking Cloud.

[polytope]

3 hours ago, DavidW said:

Again, I think some of this is getting way outside the scope of a fixpack.

As a compromise maybe it could be an optional, rather than core, component? I realize that your vote carries more weight than mine...

3 hours ago, DavidW said:

I don’t see any in-game evidence that (e.g.) Chaotic Commands is not intended to protect from Stinking Cloud.

Well, Stinking Cloud is an Evocation rather than an Enchantment like most mind-affecting spells... true Color Spray is Alteration, but the description suggests that it induces a daze resulting from the clashing colors rather than a direct transmutation type effect on the target. With Stinking Cloud on the other hand, the victims are described as "sent reeling" by "nauseous vapors", now, with a limited number of opcodes for the engine it's unsurprising that sometimes in-game effects that are completely conceptually different (Sleep, Stinking Cloud, Emotion:Hopelessness and Earthquake...) end up coded the same way, that was the entire problem with the False Dawn spell (which only worked on most vampires and the majority of liches, who lack RING95 and so are susceptible to confusion).

Another example, the Web spell has a 109 paralyze opcode tacked in (because the 157 opcode for hold + overlay looks bad on some creatures), however, things which immunize you from hold + paralysis (like Arbane's sword) aren't necessarily protective against Web, nor should they be.

[subtledoctor]

On 8/5/2022 at 2:08 AM, DavidW said:

don’t see any in-game evidence that (e.g.) Chaotic Commands is not intended to protect from Stinking Cloud.

Chaotic Commands protects your mind, and Stinking Cloud doesn’t affect the mind?

[DavidW]

Fair enough; looking at the in-game descriptions, the case isn't quite as clear as I'd thought.

[DavidW]

OK, looking more closely I'm persuaded there's a systematic issue here; apologies for initial skepticism. I'll post my notes in a separate thread.

[Luke]

@CamDawg

As part of my latest pull request, I coded up a function that automatically rearranges / extracts effects into subspells (if needed).

I did that to address the "7eyes.2da" mechanics (engine quirk), but it is also relevant for this topic and the one about curing stuff.

Point is that you can also run it as a sort of "last mod" to ensure that everything (that is, a modded override folder) is compatible with this new EE implementation.

It currently patches all resources that apply (based on IWD:EE "7eyes.2da"):

• Op3 (Berserk)
• Op5 (Charm creature)
• Op12 (Damage)
  • All types but STUNNING and MAGIC
• Op24 (Panic)
• Op25 (Poison)
• Op45 (Stun)
• Op74 (Blindness)
• Op76 (Feeblemind)
• Op80 (Deafness)
• Op109 (Paralyzed)
• Op128 (Confusion)
• Op134 (Petrification)
• Op175 (Hold creature)
• Op210 (Power word, Stun)

As I said, it can be easily tweaked to take into account other opcodes if needed...

[Luke]

@Galactygon

Did you perhaps manage to have a look at this issue? If so, what is your opinion?

[Galactygon]

I should've read this thread earlier, was busy with RL throughout 2022. Hopefully I'm not too late to the party.

The general principle of standardizing and externalizing opcode behavior is preferrable to how things used to be. I was unwilling to code this alone because of the potential to break a large number of mods. This should ideally be a community effort, supported by a critical number of mods. Also, there are several different methods as to how this could be done with their advantages and disadvantages and it's best to agree on a common way of doing things.

The method discussed here previously is replacing some item and spell status effects and their associated secondary effects i.e. status icon display, sounds, etc. with child spells and then using child spells for status removal which then goes through the list of status child spells with 321s. I think this is an improvement over the status quo since you can control opcode interaction more efficiently using child status and removal spells in a standard manner. This wasn't really viable in BG2o because child spells were not properly cast if the caster wasn't an active creature - i.e. if caster was a trap or if the caster was DestroySelf()-d or unsummoned(?) though this isn't an issue for on-hit effects. Also, you can't really remove these spells in BG2o selectively unless you use msectypes which then prevents these child status spells to have a second "main msectype" used by the parent spell. Though this isn't a big issue since msectype interaction is restricted to 10-OFFENSIVEDAMAGE reflection and removal of 1-SPELLPROTECTIONS & 3-ILLUSIONARYPROTECTIONS. A slight disadvantage as mentioned above is that you need to attune all 321 effects to all child status spells, spell by spell which can be a hassle when duplicating spells i.e. PnP Celestials duplicating spells to create at-will casting time 1 variants.

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 - though I guess it wouldn't hurt to externalize them to child removal spells anyway for the sake of standardization. In BG2o you could selectively block and remove msectypes of external .effs and still use a "main" msectype for the parent spell so it interacts with other effects normally i.e. have 10-OFFENSIVEDAMAGE used for the parent spell and something else for the .effs bundled in that spell. In the EEs, you can also use the parent resource field (0x94) of .effs and 318 to selectively block these effects i.e. use #hold for #hold01.eff, #hold02.eff, etc. Perhaps it's possible to selectively block them in BG2o with 206s as well? 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? @Bubb might be able to give a better answer whether it's easy to implement or not. What are the disadvantages of this method? The main disadvantage I can think of is using slots from the msectype.2da of which there are no more than 255. Minor disadvantages are hardcoded behaviors that come with msectypes: 1. strings are displayed when the msectype is removed so something suitable needs to be used in msectype.2da and 2. msectype protection plays the SPMAGGLO.vvc by the carrier of the effect. Though no.2 can be mitigated by using the parent resource trick possibly even in BG2o if 206 can be made to selectively block .effs based on that field.

I think the second method of using external .effs rather than .spls is the better and more robust method for the following reasons:

1. Less clutter among .spls in general. The child spell needs to have the same spell type (i.e. 1-Wizard) set as the parent spell so i.e. a priest uses CASTINGLEVELCLERIC not WIZARD if a child spell is nested inside the 7th level cleric Confusion spell. You avoid this completely with .effs which are located directly within the parent spell and do not have to account for different duration scenarios since .effs used in a .spl inherit their durations from the parent .spl.
2. You can have mods add additional effects i.e. some mod can create a #hold69.eff that uses the HOLD msectype and parent resource #hold without having to update the child removal spell.
3. splstates aren't necessary to selectively block external .effs since you use 206s targeted at some parent resource. Though it might still be a good idea to use splstates for the sake of scripting.
4. This method works in BG2o which means mods can be easily updated without having to consider two different scenarios (EE or not EE?), especially if 206 (as per the IESDP) can selectively block .effs based on parent resource. In that case you don't worry about SPMAGGLO.vvc playing at all. Also, you don't need to worry about nonactive casters i.e .traps being bugged by not applying those effects. I think this is the strongest argument for this method.

Whatever method is decided, I think the states should be differentiated even more i.e. Feeblemindedness and Spiritual Lock or the ever-lasting debate of Sleep vs. Unconsciousness. Then you can agree on more types of states that aren't bound to particular opcodes.

Edited June 27, 2023 by Galactygon