SSL scripting questions

[WanderingScholar]

Is this the correct way to format this type of change? From ReallyForceSpell to ApplySpell. 

Spoiler

RESPONSE #300
            RequireBlock(WithSI)
            ReallyForceSpellRES("dw#sw519",Myself)
            SetGlobal("ChainContingencyFired","LOCALS",1)
            DisplayStringHead(Myself,26328)
            ReallyForceSpell(Myself,protectionspell)
            ApplySpell(NearestEnemyOf(Myself),WIZARD_ABI_DALZIMS_HORRID_WILTING)
            ReallyForceSpell(Myself,WIZARD_SPELL_IMMUNITY_ABJURATION)
            Continue()

My goal is to see if I could get NPC chain contingencies with things like symbols and horrid wilting to target the nearest enemy. I'm wondering if this will cause a crash however, if the chain contingency fires with no one in sight? 

Thanks

[jmerry]

Those particular commands - ReallyForceSpell and ApplySpell - are part of the base BCS/BAF scripting language, rather than the extensions SSL adds like that "RequireBlock". Which means that you can reference the IESDP page on script actions for what they do.

Quote

This action causes the active creature to cast the specified spell at the target object. The spell need not currently be memorised by the caster, and will not be interrupted while being cast. The spell is cast instantly (i.e. with a casting time of 0). The caster must meet the level requirements of the spell. This action does not work in the script round where the active creature has died.

Quote

This action causes the active creature to cast the specified spell at the target object. The spell is applied instantly; no casting animation is played. The spell cannot be interrupted. For the RES version of the action, the spell name can not consist of only numbers, should be written in upper case and should be no more than 7 characters long. Both actions apply the spell at the lowest casting level (they will even use a level 0 ability if the spell has one, which other actions cannot do) and ignore its projectile (i.e. they use projectile #1|None) - the casting level of the originating creature is ignored. Note that for normal spellcasting the probability dice values for effects are rolled for each spell, whereas spells applied in the same scripting block by ApplySpell use a single dice value.

So, these two actions are functionally very similar. Both will cast the spell instantly, ignoring memorization. Also, the syntax is the same - target first, spell second. The differences are in the casting level and projectile; ReallyForceSpell uses the active creature's caster level (so a level 20 mage will get a 20d8 Horrid Wilting) and ApplySpell uses the minimum caster level and no projectile (so a level 20 mage will do 16d8 damage to the target with no AoE). I don't think ApplySpell is a good idea here.

As for targeting an enemy ... actions with no valid target shouldn't crash anything. Most likely, they just won't be executed. At worst, they might prevent any later actions in the same block from being executed. Still, you should include some form of "there's an enemy nearby" in the trigger conditions for a block like this that targets an enemy.

[WanderingScholar]

8 hours ago, jmerry said:

As for targeting an enemy ... actions with no valid target shouldn't crash anything. Most likely, they just won't be executed. At worst, they might prevent any later actions in the same block from being executed. Still, you should include some form of "there's an enemy nearby" in the trigger conditions for a block like this that targets an enemy.

Thanks for the insight. I was looking at the IESDP page when I found ApplySpell, but I somehow glossed over that ApplySpell uses minimum caster level. I was tired when looking at this. I definitely want to stick with ReallyForceSpell here. I just wasn't sure if I had it nested properly with the (). Of course, an example is given right there on the page. 

8 hours ago, jmerry said:

As for targeting an enemy ... actions with no valid target shouldn't crash anything. Most likely, they just won't be executed. At worst, they might prevent any later actions in the same block from being executed. Still, you should include some form of "there's an enemy nearby" in the trigger conditions for a block like this that targets an enemy.

Good to know. I just checked the compiled IF blocks for chain contingencies on the my game, and they have detection and range triggers so it should be fine.

[DavidW]

If we are talking SSL syntax, though, RequireBlock() functions like a trigger, not an action.

[WanderingScholar]

1 hour ago, DavidW said:

If we are talking SSL syntax, though, RequireBlock() functions like a trigger, not an action.

This also seemed peculiar to me.

In SCSv31 you have the chain contingencies laid out like this. It works fine so I don't question it. chaincont_core.ssl...

Spoiler

////////////////////////////////////////////////////////////////////////////////////////////
////    Chain contingencies fire
////
////    This is just the action block; the trigger block is in the main dw#mage
////
////
////////////////////////////////////////////////////////////////////////////////////////////


THEN
        RESPONSE #200
            RequireBlock(WithSI)
            RequireBlock(UsingClones)
            ReallyForceSpellRES("dw#sw519",Myself)
            SetGlobal("ChainContingencyFired","LOCALS",1)
            DisplayStringHead(Myself,26328)
            ReallyForceSpell(Myself,WIZARD_SIMULACRUM)
            ReallyForceSpell(Myself,WIZARD_SPELL_IMMUNITY_DIVINATION)
            ReallyForceSpell(Myself,WIZARD_IMPROVED_INVISIBILITY)
            SetGlobal("contingency","LOCALS",1)
            DisplayString(Myself,25942)
            ReallyForceSpell(Myself,WIZARD_PROTECTION_FROM_MAGIC_WEAPONS)
            Continue()
        RESPONSE #100...

[DavidW]

probably I’m misremembering that it can be used that way. Good catch.