A puzzle with Ardanis's spell shield fix and SCSII

[DavidW]

I'm probably just tired and missing something obvious, but I'm getting seriously puzzled and would welcome suggestions.

 

The backstory: SCSII has an option to make antimagic spells able to target improved-invisible creatures. The default way to do this is via ToBEx: if it's installed, the antimagic spells just have the "able to target improved-invisible" byte set to 1. And ToBEx is installed by default in SCSII, so for 99% of players everything is fine.

 

But SCSII also has a backup way of implementing it that doesn't require ToBEx (partly because I coded it before shipping ToBEx with SCSII occurred to me as an option). If ToBEx is disabled, either because you're on a system that doesn't support or because you've manually set it to be disabled in scsii.ini, the backup is installed instead. It works like this: you can target the antimagic spell at any point. An invisible creature is summoned at that point. The invisible creature casts a carbon copy of the original antimagic spell at the nearest enemy who's magically protected. Clunky, but it works.

 

Or at least, it worked in my testing. But it turns out it doesn't work when Ardanis's fix to Spell Shield is installed too. Ardanis's fix instructs each antimagic spell to cast two further spells: one is the original antimagic spell (which Spell Shield is set to block); the other takes down Spell Shield. I don't understand why this is.

 

To summarise, here are the spells after both Ardanis's fix and the SCSII backup antimagic are installed (for Spell Thrust, for definiteness).

 

spwi321.spl: a summoning spell that uses spwi321.eff to summon spwi321.cre, an invisible creature equipped with spwi321.bcs, telling it to cast spwi321d.spl at an appropriate target and then vanish

spwi321b.spl: the "payload": the original antimagic spell

spwi321c.spl: a spell that removes Spell Shield via sectype trickery

spwi321d.spl: a spell that casts spwi321b and spwi321c on the target

 

The summoned creature does appear to cast its spell: a projectile flies towards the target. But the projectile doesn't do anything.

 

If you change the spell choice in spwi321.bcs, the spell is cast normally (e.g., Cone of Cold damages the target).

 

If you don't install Ardanis's fix, things work fine.

 

If you copy spwi321d.spl right back over spwi321.spl, then Spell Thrust works exactly as it should normally, so it's not that my component is scrambling the spell.

 

Any thoughts? I'm completely perplexed.(You can reproduce the phenomenon by adding "Disable_ToBEx 1" to scsii/scsii.ini, and then installing components 1000 and 2019 of scsii)

[Galactygon]

Since Ardanis' spell attacks rely on embedded shell spells this means the invisible .cre has to exist (but can be dead) when the projectile hits the target. DestroySelf() ends the .cre's existance before the projectile hits the target, meaning it can't cast the shell spells that Ardanis' spell attacks rely on (which btw is reliable in all other situations).

 

You might think placing a Wait() is a solution, but I disagree. What if the spell was cast during a time stop, and you'd have 10 secs elapse between when the projectile is launched and when the projectile hits?

 

EDIT: If you're casting SPWI321D with your invisible .cre, then your best bet would be to place an instance of opcode 168 with a targettype of 9 (Self, post-projectile hit) and a delay of 1.

 

-Galactygon

[DavidW]

Since Ardanis' spell attacks rely on embedded shell spells this means the invisible .cre has to exist (but can be dead) when the projectile hits the target. DestroySelf() ends the .cre's existance before the projectile hits the target, meaning it can't cast the shell spells that Ardanis' spell attacks rely on (which btw is reliable in all other situations).

 

Brilliant. Many thanks.

 

You might think placing a Wait() is a solution, but I disagree. What if the spell was cast during a time stop, and you'd have 10 secs elapse between when the projectile is launched and when the projectile hits?

 

Well, I could work around with a longer Wait() (I don't really mind if this component is a bit kludgy, given it's only there as a backup for the occasional person who doesn't use ToBEx)... but your solution is more elegant in any case.

[phordicus]

you could use the new trigger override to see if the target creature had been hit yet and use that as the destroyself key.

[DavidW]

you could use the new trigger override to see if the target creature had been hit yet and use that as the destroyself key.

No need, Galactygon's suggestion works a charm.