Luke

A recent discussion about blanking the CLASS value of Shambling Mounds made me realize that there are two ways to achieve that: CLASS=0 CLASS=0xFF (255) But that is bad because as kjeron said, 0 is an hardcoded value that stands for 'Any CLASS value' (i.e., no particular class)... So why adding a new entry in the first place...? On top of that, this new entry is not referenced in any scripts/dialogues/op318/324/326. The same holds for "NO_RACE". As a result, I suggest changing all RACE=(255|NO_RACE) CRE files to RACE=0 all CLASS=(255|NO_CLASS) CRE files to CLASS=0 After that, the "NO_CLASS" and "NO_RACE" entries should be removed to free up space.

Yeah, I too agree that at least GENERAL/RACE/CLASS/SEX/GENDER values should be the same across all games, that is to say: GENERAL=PLANT RACE=SHAMBLING_MOUND CLASS=NO_CLASS GENDER=0 (or NIETHER) SEX=0 (or NIETHER) I mean, these are not generic monsters after all... More importantly, they're not ELEMENTALs (as @CamDawg said, this is relevant for Rangers whose favored enemy is ELEMENTAL and items such as Ring of Earth Control / the Staff of Earth...)

Ah, yes: the "Bounce from walls" flag is not compatible with ability target 4... I'm unsure about original intent here... Guess I'll leave things as they are then (though I'll make sure that trailing op206 effect is not blocked by Seven Eyes...) I see, I did not think about 'balance reasons' (I thought they should reapply every time you fail the save...) Guess I'll leave things as they are then (though I'll make sure that trailing op206/318 effect is not blocked by Seven Eyes...) Anyway, if that's indeed for 'balance reasons', then the op206 effect in "#cofear" should bypass MR, should not be dispellable and should grant no save (so that you are subjected to it only once per 3 rounds...) Yeah, you are right: it's coded in the same way in BG1/2. Having said that, I think this spell should use op321 (in place of op206) and all limited effects (Slow) should have a duration of 7 (i.e., the smallest integer value strictly greater that 100 ticks...) I see. Guess I'll leave things as they are then (though I'll make sure that trailing op206 effect is not blocked by Seven Eyes...) I see. Guess I'll leave things as they are then... Having said that, in all cases my main concern is about multiple castings. Does a trailing op206/318 effect interfere with multiple castings on the same target? Testing environment: attach op188 and op189 (Set to 0) as global (equipped) effects to an item and repeatedly cast them... Separately, let us discuss TRAP_DEATH_FOG (spwi030.spl) and WIZARD_DEATH_FOG (spwi614.spl) These two SPL files are basically the same thing but are coded differently. Can you confirm the trap is implemented better (simply because it does not use spell states...?) Can you confirm in both cases there are problems with multiple castings...? I mean, if the first instance is, say, at the fourth round (16 damage), then a second instance of the same spell would immediately start from 16 damage (4 and 8 would be skipped...) Anyway, I don't think there's a workaround here, right...?

So, I'd like to discuss all those trailing op206/318 effects (notably @kjeron). In particular, I suspect they are relic from the past to prevent stacking issues... But since nowadays we have op321, I think they should be removed... Thoughts...?

I think it is worth mentioning that a similar argument holds for (delayed, timing=4) sound effects (op174). If you're hit by, say, "bdbonbat.itm" (Sod, Bonebat attack), Remove Paralysis will certainly free you... But the delayed (ending) sound effect in "bdbonbat.itm" would still play (even if you are no longer paralyzed), and that would be incorrect...

The Grease Overlay has been changed to an ordinary Play Visual Effect (215) – this ability is not supposed to be a grease-based attack. As a result, it should not set the GREASE stat... I agree. It should use op185...

So, do you think we should remove them...? Like I said, the player can use them whereas the AI cannot (because they're not scripted to cast them)... Also, they do appear to be out of place for such creatures...

Fine, I'll make sure they're fully immune to Poison and can see invisible creatures... Separately, what can you tell me about their memorized spells (2x Magic Missile, 1x Stinking Cloud, 1x Melf's Acid Arrow, 1x Agannazar's Scorcher, 1x Ghost Armor, 1x Lightning Bolt)? Intended or not? I mean: unless I'm missing something, PnP states nothing about them being able to cast such spells more importantly, they're not scripted to cast them (see "nishrusu.bcs"), so it might be another copy/paste issue...

OK, some more undocumented inconsistencies. At least on BG:EE, the Nishruu is indeed immune to Poison (though not fully immune to it – it's just immune to the Poison opcode, but its actual Poison Resistance is not set to 100), whereas the Hakeashar is vulnerable to it As a result, I think the Hakeashar should be immune to Poison so as to match its weaker counterpart... At least on BG:EE, the Nishruu can see through invisibility, whereas the Hakeashar cannot. Intended or not...?

As you wish. Having said that, I think it's worth at least mentioning it... According to your own tests, the concern about performance is overrated...

@DavidW When talking about clearing arrays, you might want to share this function. That is: if possible, you should never use VARIABLE_IS_SET to check if an array element is set

Before I forget: if the parent file uses an AoE projectile, then `power` should be 0 on the child/subspell file (which is supposed to use the single-target projectile `#1|None`), otherwise those effects would be subjected to deflection/reflection/trap (and that would be incorrect). Right? Also, speaking of this: can you confirm that all hardcoded projectiles (those that have no resource to list, such as "Cone_Of_Fire") are Single-Target projectiles...?

Thanks, but I don't think we should use the documentation from IWDEE as is, mainly because: I'd like to state something more about energy damage – i.e., something like (emphasis is mine): "The nishruu is completely immune to energy damage (all but magic and poison damage),..." Now that I think of it, they should probably be immune to poison damage, but that's a separate issue... I'd like to clearly state that they can be killed by Dispel/Remove Magic – i.e., something like (emphasis is mine): "The nishruu is completely immune to magic (except for Dispel/Remove Magic)..."

OK. I'll document it then... In particular, they're immune to all but magic damage and poison damage (since these two damage types cannot be set in the CRE file itself...)

@CamDawg I've just noticed these creatures are also immune to elemental damage (acid, cold, fire, etc...). Is this intended...? I mean, if such damage comes from a spell, then yes (in any case, this is already achieved by having 100% magic resistance...) But should they be immune to something such as a Bullet of Fire +1...?

Yeah, what a mess. Well, let's say that I can't understand why "all effects need to have the same min/max level" is a disadvantage...

OK, will do.

Yes, this should be fixed (otherwise why having a separate RACE.IDS entry...?) I'd also standardize their immunities and attack to the SoD variant (simply because it appears to be the most accurate variant...)

To be precise, the problem is only relevant for op229/230... As @kjeron stated, those opcodes would only remove effects on the main / parent file (the one containing the op146 effect...) As a result, SPL/ITM files that apply op229/230 should also apply op321 effects targeting these subspells if necessary... Anyway, not a base game issue... Why should you ignore min/max level in the first place...? I mean, the only case in which you should ignore min/max level is when your "extract" list contains all those opcodes that do not treat those fields as min/max level, that is: op12, op17, op18, op331, etc... But unless we're dealing with very specific cases, you should not extract such opcodes into subspells... As a result, I think that all extracted opcodes should indeed share the same min/max level... That's at least what I would do... It is certainly relevant if the subspell scales with level... In any case, there should be no harm in inheriting it... That's at least what I would do... Just to clarify: it is related to op220/221. If the subspell inherits `power` but not `primary/secondary type`, then those opcodes would remove nothing... Yes, you're right. As I said, it's totally optional and harmless, up to you...

This should be WRITE_LONG This should be WRITE_BYTE Alternatively, leave it at zero/default (unlike ITM files, this field should be irrelevant for SPL files...)

OK, here is another inconsistency: on BG games (and according to spell description), only the Hakeashar is supposed to drain both item charges and spell charges, whereas on IWD both creatures are supposed to drain both item charges and spell charges. Should the BG Nishruu description be updated to state that this creature drains item charges...? Or is it correct that this creature on BG games is only supposed to drain spell charges...?

Yes, this is exactly what I intended to say. Also, since all of this is going to be included in v2.7 (hopefully), then a non-prefixed naming scheme should be safe enough... Having said that, if a prefix is really needed, then yes, I too would suggest something like <modder_prefix>fp... Pretty much what @kjeron said. On top of it, leave also dicenumber (Maximum Level) and dicesize (Minimum Level) on the parent file, so that all checks are on the parent file (only `power` should be on both the parent and the child file). Similarly, `resist_dispel` should only be on the parent file. In particular, if the extracted effects are coded as `resist_dispel=1` (Dispellable / Not bypass MR), then make sure the effects on the subspell are coded as `resist_dispel=3` (Dispellable / Bypass MR). To sum up Finally: if the parent file is a SPL file, then make sure the subspell inherits its type (Header @ 0x1C) if the parent file is a SPL file, then make sure the subspell inherits both its primary type (Header @ 0x25) and secondary type (Header @ 0x27) if the parent file is an ITM file, then make sure the subspell inherits both its primary type (Extended Header @ 0x17) and secondary type (Extended Header @ 0x19) (bonus, optional) make sure the subspell inherits the parent's icon (Extended Header @ 0x4) This is because those opcodes would only consider the resource the op146 is on, right...? But that would be a problem because the real effects are on the SPL cast by that op146 effect... How bad is this in practice...? I mean, as far as the base game is concerned, we only have op230 effects targeting SPELLPROTECTIONS... And SPELLPROTECTIONS are not supposed to cast subspells, so everything should be fine... The problem is when some other mod uses a different value... (this is something that should be noted in the final docs...)

Thanks for sharing. Besides immunities, this is also useful for dealing with the "7eyes.2da" issue I'm working on. I was trying to make the extraction/permutation universal (that is, without manually listing the effects to extract / permute), but that's not possible. I mean, if a SPL/ITM applies both, say, Stun and Slow (with the same probabilities, saves, power, etc...), there's no way to know (a priori!) if a given op215 effect (play visual effect) is associated with Stun or Slow (undecidable problem...?) Anyway, since the mod is supposed to be installed first, then I think it's fine to have a hardcoded list of effects... Is this really necessary...? What would be the problem with the following naming scheme itm ability subspell extract deva 0 deva 4,5,6 ohbdeva 0 ohbdeva 0,1,2 spermel 0 spermel1 11,12,13 spermel 0 spermel2 1,10 wand12 0 wand12a 5,15 wand12 0 wand12b 3,4,14 note the interweaving of the last two ? I would also leave power, dicenumber (Maximum Level) and dicesize (Minimum Level) on the parent file... And consequently, the extracted blocks should need the same power, dicenumber (Maximum Level) and dicesize (Minimum Level) data (along with probabilities and saving throw...)

As well as Yeslick's own Dispel Magic innate ability ("spin112.spl")...

aTweaks. Yeah, you're right. The problem is when the player casts those spells directly... Should I make them vulnerable to just those 3 SPLs or should I include all SPL/ITM files that use op58 (f.i. Arrow of Dispelling, Golden Axe +1, ANTI_MAGIC_ZONE, "RAVAG01.ITM", etc...)? Guess the latter...?