18 replies to this topic

[Ascension64]

Custom Contingency Trigger Check Delay has morphed!
To allow auras to work without affecting blade barrier and other stuff, Cast Spell On Condition effect opcode is now customisable via the param2 high word to have a custom trigger check delay. param2 high = 0 is default behaviour (100 ticks delay between checks).

-----210 Cast Spell On Condition Mod [M]
Modifies the cast spell on condition effect to allow customisation of how often the condition is checked
Note: using too many conditional spells with low values for trigger check period may slow the game down
The default trigger check value is 100

Description
#232 (0x0E8) Spell Effect: Cast Spell on Condition [232]
Parameter #1: Target
Parameter #2 Low: Condition
Parameter #2 High: Trigger Check Period
Description:
Casts the spell specified by the resource field on the target specified by the 'Target' field, when the condition from the 'Condition' field is true. The conditions are akin to various triggers.
The trigger check period field specifies how often (in ticks) the condition is checked. If set to 0, the trigger check period is 100 ticks (game default).

Known values for 'Target' are:
0 Effect Target
1 LastHitter
2 NearestEnemyOf
3 Nearest

Known values for 'Condition' are:
0 HitBy()
1 See(NearestEnemyOf())
2 HPPercentLT(Myself 50)
3 HPPercentLT(Myself 25)
4 HPPercentLT(Myself 10)
5 StateCheck(Myself,STATE_HELPLESS) i.e. unconscious
6 StateCheck(Myself,STATE_POISONED) i.e. poisoned
7 AttackedBy('Target')
8 PersonalSpaceDistance('Target',4)
9 PersonalSpaceDistance('Target',10)
10 Unknown - every round
11 TookDamage()

A non-zero Parameter 3 Low value activates the portrait icon, immediately triggers the HitBy() trigger, and prevents purging of the conditional spell after the condition is true.
Parameter 3 High is reserved for internal use (specifies that Parameter 4 has been set).
Parameter 4 is reserved for internal use (set to the game time when the effect is first applied).

Options:
-0: disabled
-1: enabled

[the bigg]

While you're there, I'm sure that DavidW would appreciate if there was a way for the player to use 'out of stoneskins' and 'out of PFMW' as triggers; yo could for instance do it via a 2da with four columns (MODE ID VALUE STRINGREF), used as follows:

Switch MODE
case 0: See(NearestEnemyOf()) CheckStat(Myself,VALUE,ID)
case 1: See(NearestEnemyOf()) CheckStatGT(Myself,VALUE,ID)
case 2: See(NearestEnemyOf()) CheckStatLT(Myself,VALUE,ID)

and STRINGREF is the TLK reference that is shown in the Contingency menu.

[Galactygon]

A non-zero Parameter 3 Low value activates the portrait icon, immediately triggers the HitBy() trigger, and prevents purging of the conditional spell after the condition is true.

I don't see any use for this. Unless it's used internally with contingencies, I think this can be reserved for more customization.

While you're there, I'm sure that DavidW would appreciate if there was a way for the player to use 'out of stoneskins' and 'out of PFMW' as triggers; yo could for instance do it via a 2da with four columns (MODE ID VALUE STRINGREF), used as follows:

Switch MODE
case 0: See(NearestEnemyOf()) CheckStat(Myself,VALUE,ID)
case 1: See(NearestEnemyOf()) CheckStatGT(Myself,VALUE,ID)
case 2: See(NearestEnemyOf()) CheckStatLT(Myself,VALUE,ID)

and STRINGREF is the TLK reference that is shown in the Contingency menu.

I second this request. I'd keep this seperate from opcode 232 though, as opcode 232 draws from a wider condition list than (chain) Contingency.

This opcode has a great deal of potential, because you can stimulate "IF" blocks. I'll add a few more conditions to the request list:
SpellCastOnMe() // It would be most optimal to read the effect list of the spell to be cast before the target is hit by the spell. It would then be possible to influence saving throws, damage tolls, etc. of the said spell without resorting to mass patching.
SpellCastOnMeRES() // Might require use of 2nd resource key
SpellCastOnMeFrom2daList() // The 2nd resource key points to a 2da file that has a list of spell RESs. A combination of the preceding two requests.
AttackedByBeforeToHitRoll(), except the effect list in the spell is read before the attack roll is rolled. This can be used to simulate PS:T's Guardian Mantle (attackers need to save vs spells at -4 in order to hit the caster) or a more flexible way to achieve AC vs creature type or saving throw vs creature type.
AttackedByButMissed() // Can't give a better name for this, applies the effect after the attacker missed
AttackedByButImmune() // Attacked by a weapontype the effect target is immune to.
PersonalSpaceDistance('Target',PARAMETER3_LOW)

I'll think of some more later.

-Galactygon

-Galactygon

[the bigg]

Yes, I remembered after posting that Contingency is a different effect, hence you'd have to decompile more code to do that. Of course, it looks like adding extra triggers to opcode 210 (as requested by Galc) is free.

Edited by the bigg, 02 February 2011 - 09:36 AM.

[DavidWallace]

While you're there, I'm sure that DavidW would appreciate if there was a way for the player to use 'out of stoneskins' and 'out of PFMW' as triggers

Only out of a sense of fair play. (i.e. I do this anyway for enemies, just as vanilla BG2 did, but I guess my conscience would be assuaged if players could do it to.)

[Ascension64]

A non-zero Parameter 3 Low value activates the portrait icon, immediately triggers the HitBy() trigger, and prevents purging of the conditional spell after the condition is true.

I don't see any use for this. Unless it's used internally with contingencies, I think this can be reserved for more customization.

This is vanilla code. Actually, vanilla uses the entire param3, I took the high part of the dword so I can toggle setting the game time, plus I tend to be a bit more florid with explanations than IESDP. This is actually important in distinguish item-based conditionals (which don't purge) and spell-based conditionals (which purge).

Contingency choices are already governed by CONTCOND.2DA and CONTTARG.2DA, although you can't extend it because the params are hard-coded. Yes, there is definitely room to expand.

Edited by Ascension64, 02 February 2011 - 11:29 PM.

[Galactygon]

I don't see any use for this. Unless it's used internally with contingencies, I think this can be reserved for more customization.

This is vanilla code. Actually, vanilla uses the entire param3, I took the high part of the dword so I can toggle setting the game time, plus I tend to be a bit more florid with explanations than IESDP. This is actually important in distinguish item-based conditionals (which don't purge) and spell-based conditionals (which purge).

I thought neither item- nor spell-based conditionals purge; in other words, the conditional continues to fire. Or maybe we talk of different things when we mean purge.

EDIT: quote bracketing

-Galactygon

Edited by Galactygon, 03 February 2011 - 02:56 AM.

[Ascension64]

Kind of. The effect makes a ConditionalSpell object that it stores in a list that is checked every <delay> AI updates. Normally in a contingency spell, when the condition in the ConditionalSpell is true, the spell is cast and the effect that made it is purged. If you simply used cast spell on condition (let's say Fire Shield Blue, which cannot set param3 because it's outside the ITM effect feature block), then when the condition in the ConditionalSpell is true, Fire Shield Blue isn't actually purged. Fire Shield Blue expires when its duration finishes, not when the condition fires. Does that make sense?

[Galactygon]

Kind of. The effect makes a ConditionalSpell object that it stores in a list that is checked every <delay> AI updates. Normally in a contingency spell, when the condition in the ConditionalSpell is true, the spell is cast and the effect that made it is purged. If you simply used cast spell on condition (let's say Fire Shield Blue, which cannot set param3 because it's outside the ITM effect feature block), then when the condition in the ConditionalSpell is true, Fire Shield Blue isn't actually purged. Fire Shield Blue expires when its duration finishes, not when the condition fires. Does that make sense?

Thanks, I understand. So then contingencies are stored via Conditional spell. Do you know what causes the string "You cannot have more than one contingency active at a time" to appear when using more than one instance of opcode 232? IIRC it also appears if the conditional .spl is cast a larger range than what's specified in the header.

It clearly does nothing, other than spam the text box.

-Galactygon

[Ascension64]

It's a hard-coded part of the effect if the parent resource is a SPL.

if (effect.nParentResourceType == 1 && //spell
	effect.rParentResource.IsNotEmpty()) {
	CSpellProtection* pSpellProt = IENew CSpellProtection();
	pSpellProt->rSpell = effect.rParentResource;
	pSpellProt->strrefMsg = creTarget.GetCurrentObject().EnemyAlly <= EA_CONTROLLEDCUTOFF ? 0x806C : -1;
	creTarget.cdsCurrent.m_SpellProtections.AddTail(pSpellProt);
}

If the opcode 232 parent resource type is a spell, a spell protection gets added against the parent resource. 0x806C is the strref you are mentioning. Only happens to controlled characters (neutral and enemy AI still have the restriction, but the strref is -1).

Edited by Ascension64, 03 February 2011 - 04:24 AM.

[Galactygon]

It's a hard-coded part of the effect if the parent resource is a SPL.

if (effect.nParentResourceType == 1 && //spell
	effect.rParentResource.IsNotEmpty()) {
	CSpellProtection* pSpellProt = IENew CSpellProtection();
	pSpellProt->rSpell = effect.rParentResource;
	pSpellProt->strrefMsg = creTarget.GetCurrentObject().EnemyAlly <= EA_CONTROLLEDCUTOFF ? 0x806C : -1;
	creTarget.cdsCurrent.m_SpellProtections.AddTail(pSpellProt);
}

If the opcode 232 parent resource type is a spell, a spell protection gets added against the parent resource. 0x806C is the strref you are mentioning. Only happens to controlled characters (neutral and enemy AI still have the restriction, but the strref is -1).

Aha. This solves the mystery why effects are not read after opcode 232. This also has consequences of aura-like spells and blade barriers to be non-refreshable while they're active.

The developers might have intended this to prevent the functioning of more than one contingency at a time. Making this protection kick in only if internally accessed via contingency would make this opcode more reliable. In that case, to prevent characters from taking damage from fireshield/blade barrier more than once, this opcode does need that "non-stacking" property you are deprecating. I'd think this is a fix rather than an extension.

-Galactygon

[Ascension64]

Huh? This is vanilla behaviour. Which part am I 'fixing'?

[Galactygon]

Huh? This is vanilla behaviour. Which part am I 'fixing'?

This opcode is going to prevent players from refreshing Blade Barrier/Fireshield spells before their durations run out, because protection from spell (206) is placed on them. There is no good reason to do this in this application, where the modder can apply protection from spell externally at the end of the effect list.

The developers must have known about this, since opcode 232 appears last in the effects list of all Blade Barrier/Fireshield spells except for Globe of Blades. The reason the rest of the effects are read in Globe of Blades has to do with the target type of opcode 232 being set to 2 (pre-target), and rest using 1 (self) as their target types. Setting the targettype to 1 for opcode 232 in Globe of Blades will prevent the rest of the effects from being read. There is another engine inconsistency I noticed: if the targettype in Globe of Blades' header is set to 5 (self), and I set the targettypes of all the effects to 2 (pre-target), only opcode 232 is read, even if it isn't first in the effect list.

The only use of this hardcoded feature is that it purges whenever the player cancels one of his/her contingency spells, so that (s)he may recast contingency.

Restricting this sort of behavior to contingency creation seems like a fix to me, but I'm fine with that being classified as an extension.

-Galactygon

[Ascension64]

Oh, I see. I think you are talking about a different aspect of this opcode, that I should remove this section of code quoted above as a 'fix'?

[Galactygon]

Oh, I see. I think you are talking about a different aspect of this opcode, that I should remove this section of code quoted above as a 'fix'?

Only if opcode 232 isn't accessed via contingency creation. It should still be there to prevent contingency spells from being recast and abused.

Deleting this will have a side effect: casting the same type of fireshield more than once will cause attacking creatures to be hit by the conditional spell more than once. In other words, multiple conditional spells will stack. This is where your idea of prevent effect stacking could jump in.

-Galactygon

[Turambar]

If the opcode 232 parent resource type is a spell, a spell protection gets added against the parent resource.

If I've understood correctly, the original game behaviour makes everyone immune from an aura spell, if the same is already running.
I hope what I'm saying is clear enough: would it be possible to change (hack) the code you quoted so that, if an aura spell is cast again before it's finished (eg, let's assume that blade barrier has duration 10, and I cast it twice, the second time 5 time-units [are they the same as script rounds, or what?] after the first one), the effects still don't stack, but the duration is updated (by setting it to the max between the remaining duration of the old spell and the total duration of the new one; in my case, the barrier will last for a total of 15 rounds, 5 from the first plus 10 - from the second - which 'overwrite' the remaining 5 units of the first spell)?
A component (drow item disintegration) from my mod relies on this (I temporarily changed it to opcode 282 due to the problems with the delay, which caused the game to lag really awfully, but that does not work as op232, and created some other problems), so I'm quite interested in how exactly this fix will work.

Edited by Turambar, 04 February 2011 - 08:56 AM.

[Ascension64]

Hold on, this spell protection only gets added when Param3 is set to 1, which isn't the case for all ITM and SPL feature blocks. Theoretically, it is entirely possible to cast two Fireshield Blue in vanilla at the moment and their effects stack. What is this behaviour in practice?

The Create Contingency opcode (after selecting a spell) generates the Cast Spell On Condition opcode with a Param3 set to 1.

Therefore, I don't think this is an issue.

Edited by Ascension64, 04 February 2011 - 01:11 PM.

[Galactygon]

Hold on, this spell protection only gets added when Param3 is set to 1, which isn't the case for all ITM and SPL feature blocks. Theoretically, it is entirely possible to cast two Fireshield Blue in vanilla at the moment and their effects stack. What is this behaviour in practice?

The spell protection always gets added, making the barrier/shield tests non-refreshable. I just tested this with Globe of Blades.

-Galactygon

[Ascension64]

I'll have a mull over this.