Luke

OK, so what do you suggest...? I mean, here we go again. Every time you see Immunity to Hold, you'll find both immunity to op175 and to op109... Intended...? I don't think so... Again, the fact that op162 removes both opcodes might play a role here... PnP Free Action specifically lists both Hold and Paralysis, so I think it's fine for it to protect against both... But what about CC, the various Rages, etc...? Yes, this is weird... I'd personally remove the Cure Stun opcode simply because Stun has nothing to do with "hindrances to movement"... I mean, if you're stunned, you cannot move, sure... but that's not because something is physically/chemically preventing you from moving: it is because you got a blow to the mind (either physically or magically...) Yes, I'm interested... And I don't see why it cannot be part of this fixpack... I mean, I know that there will be some gameplay changes... But the fact that the devs did not properly distinguish between op109 and op175 does qualify as a bug, right...? What do you think @CamDawg...?

Exactly! As a matter of fact, all those Hold Person/Animal/Monster spells are flagged as "Primary Type: ENCHANTER" (except for Hold Undead, which is flagged as "Primary Type: NECROMANCER" and uses op185...) As already said, this is also @kjeron's thought... And that's probably why on EE games mindless creatures (Lemures, Slimes, Golems, etc...) and creatures that do not have a "real" mind (Undead, Plants, etc...) are innately immune to op175... If we'll end up considering op175 as a mind attack, then things like CC, BARBARIAN_RAGE, MINSC_BERSERK, BERSERKER_RAGE, etc... should only protect against op175 (the immunity to op109 should be removed...) If we'll end up considering op175 as a mind attack, then Undead Hunters should only be immune to op109 (since that's what undead use! – the immunity to op175 should be removed...) Similarly, Inquisitors should only be immune to op175. Kit description states "Immune to hold and charm" (a light version of CC...?)... And since Charm is definitely a mind attack, then I'd consider that Hold as op175 – the immunity to op109 should be removed...

In any case, modders should always use "TriggerOverride()", right...?

I see, so basically op175 is very similar to a Force Power (from Star Wars )... Having said that, should things like BARBARIAN_RAGE, CLERIC_CHAOTIC_COMMANDS, etc... block both of them or just one...? This does sound like a bug. Basilisks (f.i. "basill1.itm") should only apply op134 (Petrification) and not also op109 (Paralyze)... If that's indeed the case, then also things like "spcl415.spl" (snares) should use op185...?

Courtesy of @jmerry: The 2.6 patch updated fireshields in several ways, one of which was to route the retaliation damage through a new projectile. This has an unintended side effect; if one creature with a fireshield up hits another, damage bounces back and forth every tick until either one of the creatures is dead or they're out of range of each other. This component fixes that issue, reverting "dueling fireshields" to the older behavior of delivering exactly one hit each way.

OK, I'll wait for it... Additionally, what about asking @Lava to make two brand new custom portrait icons for op109 and op185 (in so doing, "icon=13|Held" would be unique to op175...)?

Sorry, but it's still not clear to me if there's a real difference between the two (I know that internally they're actually the same thing, except for the special field of op109, but...)? If I want to make a new SPL/ITM file that imposes immobility (without physically preventing you from moving – so as to exclude op185), should I use op109 or op175...? As already said, kjeron managed to provide a clear distinction between the two. However, according to the original game files, it's not clear to me if that's indeed the intended behavior or not... In particular, the fact that creature immunity doesn't normally affect op175 makes me think that's not the intended behavior...

Thanks for sharing, I'll add it to the IESDP...

Thanks for confirming it, I'll add it to the IESDP...

OK, fine. I've never considered it as a "magical chasm that can magically pull in its targets"... On reflection, it makes sense though...

I agree with you and @subtledoctor: petrification should be left out. Moreover, GENERAL=UNDEAD and RACE=GOLEM should probably be immune to op209 (Power word, kill)...

Fine. As far as this is concerned, guess you can copy/paste what you've already done in BG2FP and expand that list with EE resources...?

Chill Touch should correctly affect UNDEAD without permanently removing their immunity to Panic (see here). The Grease spell (in particular "spwi101b.spl" and "spwi101c.spl") should apply the GREASE stat. As you can see, those two subspells are not applying the aforementioned stat, nor the GREASE spell state. This might confuse both later patches and AI. As a result, I suggest replacing op215 with op158 (param2=1|custom overlay; resource="greaseb" on "spwi101b" and resource="greasec" on "spwi101c"). The Grease spell (in particular "spwi101b.spl" and "spwi101c.spl") should not interfere with deflection/reflection/trap. Since this spell is supposed to be an AoE spell, the `power level` of the effects in those two subspells should be 0 (this issue also affects Wall of Moonlight, see here for further details...) SPL files flagged as GENERALIST There are a lot of SPL files (f.i. "spin192.spl", "umbergaz.spl", "#beltyn.spl", "firau1d6.spl", "spin188.spl", etc...) that are currently flagged as GENERALIST (Header @ 0x25). They should not have "Primary Type: 9|Generalist" (nothing should, unless it grants no save): this results in specialist save modifiers for Trueclass/Generalist creatures! They should have "Primary Type: 0|None" (unless they're subspells such as "#beltyn.spl", which should have "Primary Type: 7|NECROMANCER" to match its parent "spwi422.spl"...)

I agree. I'd also add: flying creatures (RACE=DRAGON, RACE=WYVERN, RACE=HARPY, etc...) magically levitating creatures (RACE=DEMILICH, RACE=BEHOLDER, GENERAL=WEAPON – Mordenkainen's Sword, etc...) incorporeal creatures (RACE=SPECTRE, RACE=SHADOW, RACE=MIST, CLASS=SPECTRAL_TROLL, etc..) special cases such as RACE=SLIME...

It is probably worth mentioning that also manually pausing the game can cause all those issues (of course, it's much less noticeable and reproducible, but it can happen...)

I'll report here what I've already said in the PM

To be precise, this should be slightly better WITH_SCOPE BEGIN ACTION_BASH_FOR "%MOD_FOLDER%/fixes" ".*\.tpc" BEGIN WITH_SCOPE BEGIN INCLUDE "%BASH_FOR_FILESPEC%" END END END In so doing, you'll forget about BASH_FOR_DIRECTORY, BASH_FOR_FILESPEC, BASH_FOR_FILE, BASH_FOR_RES, BASH_FOR_EXT, BASH_FOR_SIZE when exiting from ACTION_BASH_FOR (I know you would not probably use them outside of an ACTION_BASH_FOR instruction, but just in case...) Also, to speed up inclusions, I'd use tph as file extension (not sure if that "tpc" is a typo or not...) I agree. I agree (ditto for all the other IDS files). Alternatively, if you decide not to follow SFO's protocol, I strongly suggest to use LOOKUP_IDS_SYMBOL_OF_INT, IDS_OF_SYMBOL, etc... So for instance WRITE_BYTE 0x272 2 // bad WRITE_BYTE 0x272 (IDS_OF_SYMBOL ("RACE" "ELF")) // good

I agree. Additionally, all flying (f.i. RACE=HARPY, RACE=WYVERN, RACE=DRAGON, etc...) and magically levitating (RACE=DEMILICH, GENERAL=WEAPON – Mordenkainen's Sword) creatures should be completely immune to it... As far as this particular case is concerned, I'd suggest following the IWD architecture (op324 on the SPL file) instead of the BG architecture (op101 on the creatures skin or on the CRE files itself). I mean, I can see why certain demons should be vulnerable to Poison... But should, say, certain DRAGONs be vulnerable to ground-based attacks...?

There's also an incorrect usage of op337 (Remove effects by opcode): since the spell should affect small creatures that are supposed to be immune to Sleep (for instance ordinary skeletons and/or ghouls), a 0-second op337 effect removing immunity to op39 is applied just before op39 itself... However, op337 always acts as permanent! As a result, casting this spell on an UNDEAD/GOLEM/etc. will permanently remove their immunity to Sleep (op39)... And that would be incorrect of course... I too agree with using op185 here...

Here is another issue that can be easily fixed with a new spellstate. As you know, the script trigger SpellCastOnMe() returns false in case of SPL/ITM files whose Ability Target (Extended Header @ 0xC) is 4 (Any point within range). As a result, Nishruus and Hakeashars cannot be killed by Dispel Magic (since all such spells have an Ability Target of 4). In particular, the following script block is completely useless If we add a new spell state, we can simply patch all such spells with a subspell (applied by op326) that can actually kill them (via op13 for instance...) On reflection, in this case it is probably easier to add a new SPECIFIC (@ 0x274) value... In so doing, we can simply patch all Dispel Magic spells with an additional op177 effect (resource=DESTSELF) targeting the new SPECIFIC value...

I think it is worth mentioning that this issue is also relevant for removal spells. Suppose a Bonebat ("bdbonbat.cre") paralyzes (via "bdbonbat.itm") your character and you decide to cast CLERIC_REMOVE_PARALYSIS. The spell will certainly remove the main effect (op109) along with the Held portrait icon... but the expiry sound will still play (even if nothing has actually ended!). However, this issue cannot be solved with spellstates: in this case we just need to make sure all these resources are properly removed via op321 effects...

Exactly. Spellstates should also solve the issue with CLERIC_CHAOTIC_COMMANDS protecting against CLERIC_EARTHQUAKE and the like... There is no need for alternate Sleep opcode (at least in principle...) I've already tried fixing this issue without using spellstates... As you can see, it's quite a mess and can't be fully automated... On top of that, there are some limitations too... Indeed. The fact that there is not a real distinction between paralyzation (109) and hold (175) (let's not consider op185 which is a special case) is probably because op162 (used by spells such as CLERIC_REMOVE_PARALYSIS and CLERIC_FREE_ACTION) removes both of them... Having said that, we really should draw a distinction between the two... I mean, why having two separate opcodes then...?

this one can actually be avoided since we have the LEVEL_DRAIN_IMMUNITY stat (can be set via op282...) Related: we should also take into account all those items/spells that "drain" attributes via something like op44 – Strength bonus (f.i. "shadowwp.itm")... This is certainly another good reason for expanding "splstate.ids". So basically instead of checking for GENERAL/RACE/CLASS/etc... you would just use !CheckSpellState(scstarget,IMMUNITY_TO_HOLD) // So as to avoid special cases such as the Chromatic Demon And similarly, things like CLERIC_HOLD_PERSON would become On an unmodded game, there should be 122 free slots (123 on BGEE since it lacks `118 HARDINESS`...) Of course mods that make resources from scratch should adapt to the new system, otherwise the so called stray effects would still fire and there would not be any feedback string (the so called STRREF_FEEDBACK_IMMUNE_RESOURCE from op324...) 206 can block SPL and EFF V2 files (provided that `Parent Resource Type` @ 0x90 is set to `1|Spell`; moreover, the `Resource` field of opcode #206 and the `Parent Resource` field @ 0x94 of the EFF file must be the same string). It will also fire a string in the combat log upon triggering (however, the string is not firing as of v2.6, regression @Galactygon @Bubb ...?) 318 can block SPL/ITM/EFF V2 files (regardless of the value of `Parent Resource Type` @ 0x90; moreover, the `Resource` field of opcode #318 and the `Parent Resource` field @ 0x94 of the EFF file must be the same string), However, unlike op206, it won't display a string upon triggering (op324 is functionally identical to op318 except that will display STRREF_FEEDBACK_IMMUNE_RESOURCE upon triggering). So to sum up: in case of ITM files, you need either 318 or 324; in case of SPL files, it doesn't really matter (unless you want to display a feedback string...)

I agree, that's why I asked... As stated later in the first post, it is the other way round, i.e.: make sure dialogs/scripts use the correct symbolic references (regardless of how they are spelled...) What does 'syntax errors' mean in this case?

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... As I've already said, Elementals are vulnerable to everything... Except for a bunch of BG2 elementals, i.e.: ("ohbeai01.cre", "ohbeea01.cre", "ohbefi01.cre") that wear "ohbetrai.itm" (immunity to Hold, Paralyze, Poison, Disease, Sleep, Stun, Power Word Stun, all Insect Plague spells, all cure/cause wounds spells, Intelligence bonus). Moreover, they're immune to all Web attacks (this one is attached directly on the CRE file). The Elemental Princes Zaamal Rul and Sunnis, which are immune to Poison, Hold, Paralyze, Stun, Power Word Stun, Petrification (directly attached to the CRE files), Poison (via "elemprin.itm"). The Elemental Prince Chan, which is immune to just Poison (via "elemprin.itm"), and thus differ from the other princes (bug...?) "gorair0[1-2].cre": immunity to Charm creature, Reset morale, Panic, Silence, Stone to flesh, Petrification, Entangle overlay, Morale break (directly attached to the CRE files). Now, again: developer intent or not...? I mean, I think we should do something in this case...? Elementals are not supposed to be "squishy" creatures after all... Again, SoD resources that apply, say, Disease, tend to have op318/324 effects targeting RACE=ELEMENTAL, so this is mainly an issue for vanilla content...