Using SetNthEffectMagnitude and SetNthEffectDuration to create dynamic spells...

[gooser]

I need to 'configure' spells in-game by making calls to these two SKSE methods and wonder if it is good idea or not. The alternative is to assembly the combinations in CK and have a set of them to use...

 

If I configure a spell, cast it on Actor A, then later, modify it again, and cast it on Actor B, are there going to be conflicts? Will Actor A pickup the magnitude and/or duration changes made in preparation to cast it on Actor B?

 

Thanks!

[lordescobar666]

Theoretically it should work. MagicEffects are designed to be independent from Spells and the magnitude is not supposed to change as long as the magic effect lasts. So the optimal thing to do is to keep the magnitude local to the magic effect instance instead of using a costly reference to another object for querying (this assumes that Skyrim was developed by sane developers ).

 

The official way supported by CK for having different magnitudes is to define conditions in the spells effect item list. You can use script properties there and control the magnitude of effects this way.

[gooser]

Interesting - is the condition function "GetScriptVariable" ?

[lordescobar666]

I was referring to GetVMQuestVariable. An example of how it is used can be found here. There is also GetVMScriptVariable (GetVMQuestVariable seems to be used with Quest scripts and GetVMScriptVariable with ObjectReference scripts).

 

GetVMQuestVariable mentions in its documentation that it is for dialog conditions, but in other places it is also mentioned that it can be used to "conditionalize package stacks on actors, etc", so it will probably also for work for effect item conditions. Also the documentation of GetVMScriptVariable only says "conditions" without further specification (Myself I have only used GetVMQuestVariable in dialog conditions so far, which worked well).

[gooser]

Thanks for the tips. If I can accomplish the same thing using SKSE extended functions on the Spell script I'd rather do that...