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...)

23 hours ago, kjeron said:

Whirlwind won't function correctly regardless of what's done to it right now.

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...)

23 hours ago, kjeron said:

#cofear, spin132, spin139, and spin161 have nothing that stacks, which leads me to believe op206 is there to prevent a creature from being affected too often (for balance reasons).

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...)

23 hours ago, kjeron said:

Writhing Fog is the same issue in BG1/2, no clue why Beamdog implemented it that way, as it came with the Shaman class, not the original game.

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...)

23 hours ago, kjeron said:

Produce Fire is setup that way so that any creature entering the area over the next round takes the damage.  Changing it to a single repetition may as well remove the frequency entirely.

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...)

23 hours ago, kjeron said:

Walls (rectangular AoEs) automatically trigger every tick, their frequency only determines the overall duration.  While you can make them respect their frequency, it would make far too easy for creatures to safely run through them between triggers.

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...?

On 5/27/2022 at 1:26 AM, CamDawg said:

... but the spinny-head animation would remain.

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...

17 hours ago, jmerry said:

and a Grease overlay (158)

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...

13 hours ago, kjeron said:

That doesn't sound like a paralysis effect at all though.  Should probably be treated same as the Bigby's spells.

I agree. It should use op185...

18 minutes ago, DavidW said:

Things like that are almost always leftover relics from a copy/paste.

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...

23 hours ago, DavidW said:

That goes back to oBG2, and I agree: surely a bug in both cases. (FWIW there is no listed difference in the PnP material: both creatures are listed as immune to illusions.)

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:

1. unless I'm missing something, PnP states nothing about them being able to cast such spells
2. 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...?

4 hours ago, DavidW said:

I think that's overkill: ... (As for the guide, I don't want to discuss functions at that point in the guide since they haven't been introduced yet, and I don't want to have people having to rely on my function library in it.)

As you wish.

Having said that, I think it's worth at least mentioning it...

4 hours ago, DavidW said:

... and it's significantly faster.

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

// might be a problem if there exists a variable named "myarray_Melissan"
ACTION_IF VARIABLE_IS_SET $myarray("Melissan") BEGIN
	PRINT "Melissan’s value is set"
END

// safe approach
LAF array_contains
	STR_VAR array="myarray"
			key="Melissan"
	RET value
END
ACTION_IF value BEGIN
	PRINT "Melissan’s value is set"
END

On 6/6/2022 at 3:44 AM, kjeron said:

Power on the subspell for opcodes 220/221.

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...?

16 hours ago, DavidW said:

Just take the documentation from IWDEE (which actually mentions the energy damage). Then we get all languages simultaneously. There is code in the FP to autoextract a string from all the different tlk files in a game - hang on a sec and I'll run it for that string.

Thanks, but I don't think we should use the documentation from IWDEE as is, mainly because:

1. 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...
2. 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)..."

8 minutes ago, CamDawg said:

When in doubt, err on the side of no changes.

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...?

1 minute ago, DavidW said:

It's not being ignored. It's present on the subspell.

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...

5 minutes ago, CamDawg said:

The upshot of all of this is that we should simply update BG/BG2's Summon Nishruu description to include the bit about draining items, since it's the intended behavior.

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...)

24 minutes ago, DavidW said:

I suspect something as subtle as those opcodes probably should be treated manually anyway, but noted.

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...

24 minutes ago, DavidW said:

The obvious disadvantage is that it means all effects need to have the same min/max level

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...

38 minutes ago, DavidW said:

Does type do anything relevant here?

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...

40 minutes ago, DavidW said:

This is sensible.

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...

53 minutes ago, DavidW said:

It's a subspell - when can its icon be seen?

Yes, you're right. As I said, it's totally optional and harmless, up to you...

22 hours ago, DavidW said:

(and let me know if you find bugs; one of the reasons I code this way is so that the nastier bugs stay in central places and can be fixed centrally).

• 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...?

18 hours ago, DavidW said:

In practice it's probably safe in the context of a FP...

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...

18 hours ago, DavidW said:

(But persuade me otherwise, I could be missing something.)

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

// make the edits (keep power, probabilities, saving throws, dicenumber, dicesize)
LPF ALTER_EFFECT INT_VAR match_opcode=998 opcode=146 timing=1 duration=0 parameter1=0 parameter2=1 special=0 STR_VAR resource="%subspell%" END

// overwrite probabilities, saving throws, dicenumber, dicesize, resist_dispel
WRITE_LONG 0x24+fx_off 0
WRITE_LONG 0x28+fx_off 0
WRITE_BYTE 0x12+fx_off 100
WRITE_BYTE 0x13+fx_off 0
WRITE_LONG 0x1c+fx_off 0 // dicenumber
WRITE_LONG 0x20+fx_off 0 // dicesize
WRITE_BYTE 0xd+fx_off (THIS == BIT0 ? BIT0 | BIT1 : THIS) // resist_dispel

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)

9 hours ago, kjeron said:

I would also include opcodes 229/230, except using separate subspells already breaks them.

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...

4 hours ago, DavidW said:

The third is a new spell (and so needs to be unique, with a modder prefix - and in my case a modder subprefix so I don't worry about overwriting SCS!).

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

?

4 hours ago, DavidW said:

Probabilities and saving throws remain on the parent item; everything else gets moved to the subspell.

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...)

15 hours ago, jmerry said:

Though maybe more than just those three - inquisitor Dispel Magic should work just as well as the mage and priest versions.

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

16 hours ago, RoyalProtector said:

I think aTweaks restores that vulnerability too. Or was it CDTweaks? One of them... just so you know.

aTweaks.

15 hours ago, jmerry said:

There are some cases in which the current implementation can work. An AI script casting Dispel/Remove Magic with the nishruu as target will do it, because scripts override the spell's own targeting rules. Alternately, including Dispel/Remove Magic and a creature-targeted spell in a sequencer gives you a sequencer ability that targets a creature, and that can kill a nishruu if you target it.

Yeah, you're right.

The problem is when the player casts those spells directly...

14 hours ago, CamDawg said:

Yes, this should be fixed.

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...?