Talk:Magic Effect

Tapering

Can someone explain this more? A graph or an example of how these work would be much appreciated --- Fowl 22:40, 10 February 2012 (EST)

I've messed around with these a bit and from what I can tell:
Taper Duration-just a straight addition to the duration of the spell the effect is attached to
Weight-I think is just a straight multiplier for the magnitude specified in the spell the effect is attached to
Curve-not sure what the equation/graph would actually look like, but the higher the number, the more sharply the damage tapers off
edit: I tried a negative number in the curve field (like a -2) and ended up with a dead actor with -10000 ish hp.
Cscottydont 04:17, 19 February 2012 (EST)

I figured out the formula. Graphs possibly to come. --Evil4Zerggin 20:17, 7 April 2012 (EDT)

Damage formula incorrect

There's a problem with the second formula - it doesn't include the Taper Time (elapsed seconds), so it always gives the same result.

--EpF (talk) 2014-08-30T10:34:36 (EDT)

Works on beneficial effects?

Also, are there other factors that affect tapering? I've been experimenting with a fortify AttackDamageMult effect, using both Value Modifier and Peak Value Modifier archetypes with Recover flagged and using GetAv AttackDamageMult shows no change using the following values:

• Effect Magnitude: 10
• Taper Weight: 0.5
• Taper Duration: 10
• Taper Curve: 2

I set up a spreadsheet with the formula to check it and it should show wildly different values at each second interval, but it just sticks at the +10 initial magnitude for the entire duration.

I get the same results using those values on a compeletely different AV like HeavyArmor and SpeedMult.

Can anyone confirm that tapering works on beneficial effects and, if so, what conditions are required?

--EpF (talk) 2014-08-30T10:34:36 (EDT)

Flags

The page says "No Recast: Not used. ". This is untrue as the magic effects attached to the master level destruction spells have this checkbox checked. Anyone have any idea what this does, or if it just does nothing?
Cscottydont 07:58, 19 February 2012 (EST)

It's possible that "Not used" simply means "not used by the game engine", i.e. the flag does nothing anymore. It may have worked at some point in development, which could explain why it's ticked on some spells.

Do you notice any differences in a spell depending on whether or not this flag is checked?

-- Cipscis 08:13, 19 February 2012 (EST)

That makes sense. It has no apparent effect on the player/spells cast by the player. Unsure of the effects on other Actors.

--Cscottydont 09:14, 4 March 2012 (EST)

Checking "No Recast" makes it so that a second application of the effect from the same source will dispel the previous version. So if you cast, say, an armor spell with No Recast checked, then cast the same spell again, the second cast will overwrite the first and your armor will not increase again. However, you could use the same magic effect for a DIFFERENT armor spell, and the two spells would stack. Lofgren (talk) 2016-12-30T09:55:55 (EST)

I found a bug in CK in the "Magic Effect" dialog. When I enable "No Magnitude" flag and select "Assoc. Item 1" - "NONE", save my ESP file, and open it again in CK, "Assoc. Item 1" becomes "Health". And in the game, on the Skills Window, my Magic Effect increases Health by one point for my char.

Solution - uncheck the "No Magnitude" flag, "Assoc. Item 1" won't become "Health".

P.S. Sorry for my english.

Figured something out re: No Recast: for Constant Effect magic effects, "No Recast" appears to mean the difference between an effect being renewed every second and replaced every second, at least as far as the hit shader is concerned. Setting the flag means that shaders will never fade or use alpha amplitude, because they are always reset every time the constant effect is "applied." DavidJCobb (talk) 2017-05-31T23:15:42 (EDT)

Effect Archetypes

Accum. Magnitude

Tried using the Accum. Magnitude Archetype on a Concentration type Magic Effect. My guess is its broken. The spell immediately set the targets health to 1 (or some other low number, I wasn't fast enough to console check it before they died) then immediately after that, killed the target.
Cscottydont 04:14, 19 February 2012 (EST)

This effect archetype is used by wards, it's certainly linked to the way they take time to charge up (hence the name accumulated magnitude). It probably needs WardPower as an associated effect to work.--Tang Un 12:57, 7 March 2012 (EST)

Peak Value Modifier

I've noticed that enchantments stack but potions don't, despite both of them using Peak Value Modifier. Is it that the second AV has to be set for stacking not to occur? --Evil4Zerggin 23:14, 10 February 2012 (EST)

Peak Value Modifier seems to work the same as Value Modifier if Associated Item 2 is set to NONE. However the current description of Peak Value Modifier is completely wrong. Associated Item 2 does not take an Actor Value; it takes a Keyword. —Vinifera7 23:56, 23 February 2012 (EST)

I've never seen this, is there an example magic effect like this I can look at? --- Fowl 05:25, 27 February 2012 (EST)

I believe Vinifera7 is correct. Take a look at any of the Alchxxxx effects that use Peak Value Modifier. Evil4Zerggin's observation was correct. Associated Item 2 needs to be set to a keyword that multiple effects share for those effects not to stack.

--Cscottydont 09:31, 4 March 2012 (EST)

Think I've figured it out. If two PVMs have the same keyword set, they are exclusive of each other, and only the bigger value will be active, while the lesser will get canceled. See OakArmor and StoneArmor for examples. Kdansky 13:14, 29 February 2012 (EST)

Correction, I just found an example which worked differently: If you have a +250 FortifyHealth (ValueMod) effect, and a -100 RavageHealth (ValueMod), you'll end up with +150 (as expected). If you recast that spell, you end up with two of each (+300, as expected). But if you change the Fortify effect into PeakVM and put its own keyword in, you'll end up with (surprise) +150, no matter how often you cast it. And weirdly enough, only one Fortify Effect is in your active effects list, but all the Ravage effects are there, though only one applies its modifiers. Weird? Kdansky 13:30, 29 February 2012 (EST)

Demoralize and Turn Undead

I can't find any difference in their function. They both modify confidence and aside from the conditions on the magic effects they seem to be technically the same. --- Fowl 18:18, 22 February 2012 (EST)

They are the same as far as I can see too. Just the conditions.

After doing some testing on both of these archetypes yesterday I uncovered new information (and updated the page accordingly). 1) Demoralize and Turn Undead, when cast on an ally prior to combat, will not actually cause the ally to flee UNTIL combat begins. Then, and only then, will they start fleeing. If you try casting, say, Fear on your ally outside of combat, they will simply stand there. 2) There actually is a notable difference between the two archetypes, in that the Turn Undead Archetype is hard-coded to not function if the target does not have the ActorTypeUndead keyword, even if the effect's condition checks would otherwise allow for the effect to affect the target. I found this out when trying to get the Turn Lesser Undead spell to work on the summonable undead horse Arvak. By default, Arvak is bugged in that it does not have the ActorTypeUndead keyword and instead has the ActorTypeDaedra keyword. Trying to cast the spell on him results in him "resisting" it. Forcibly altering the spell's effect conditions to render him able to be affected by it but without actually putting the ActorTypeUndead keyword on him results in the spell not being "resisted" and instead simply nothing happens at all; the effect is not applied, no hit shader appears, nothing. It is as if the game engine cancels/rejects the effect before it can even begin. Only when the ActorTypeUndead keyword is placed on Arvak does he then get turned by the spell. Demoralize, on the other hand, worked on Arvak regardless. So, there you have it. SkylerModder (talk) 2018-07-06T19:33:04 (EDT)

Banish

Reverse-engineering indicates that Banish is a subclass of Demoralize. If the target actor is successfully banished on effect start, then the active effect sets its own magnitude to zero. Otherwise, the effect behaves the same as a Value Modifier on effect start (given that Demoralize is itself a subclass of Value Modifier), attempting to reduce the target actor value to zero. DavidJCobb (talk) 00:27, 28 July 2026 (EDT)

Disguise

Reverse-engineering (by the maintainers of CommonLibSSE along with some of my own findings) suggests that this Magic Effect is actually quite functional, except that it always behaves as if the player were the caster. Simply put, the player assumes the identity of the effect's target actor. The internal data for the player includes a ref handle for their "assumed identity," and some of the game's combat internals check this assumed identity. I haven't tracked down nearly everything, and digging into this isn't a huge priority for me, but behaviors I've seen include:

• PlayerCharacter::IsInFaction overrides the virtual Actor::IsInFaction member function: if the player has an assumed identity, then faction checks are run against that identity instead.
• The effect creates a DisguiseEffect::DetectionChecker, a subclass of DetectionCollector (itself a subclass of DetectionListener). Further RE is required to determine this object's precise behavior.

On effect start, the player's assumed identity is set to the target actor, which has the side effect of forcibly stopping combat between the player and the target; the effect then forces the target to update their combat state. On effect finish, if the player's assumed identity is still the target actor, then the assumed identity is wholly cleared. (This does mean that multiple Disguise effects will not stack cleanly. If Alice uses Spell X to disguise as Bella for sixty seconds, and at the exact same time uses Spell Y to disguise as Camille for twenty seconds, then after the latter disguise ends, Alice will no longer be disguised as anyone, but will still have Spell X's effect active for another forty seconds.)

The effect has an internal state value. Whenever the effect re-processes conditions, it checks if this state value is anything other than "normal" (the other possibilities are "initializing," "waiting," and "fail"); if so, the effect forces the game to act as though the conditions were not met, thus deactivating the effect. Presumably, this is used in combination with the DetectionChecker to cause the disguise to fail under certain circumstances. DavidJCobb (talk) 01:31, 9 June 2025 (EDT)

Light

Reverse-engineering indicates that an actor can only have a single Light-archetype effect active at a time, and the total number of magic lights that can exist in the game world is limited by the iMagicLightMaxCount Game Setting. DavidJCobb (talk) 00:27, 28 July 2026 (EDT)

Open

I can't get this to work. It's as if doors and containers aren't affected by magic. Can anyone confirm this? ~ Dwarfmp 03:47, 29 February 2012 (EST)

Confirmed: Tested this with both an 'Apply Combat hit spell' and regular spell. Seems that natively, doors and containers do not recognize a magic impact. Might have to alter or extend their scripts through a new one to change this? ~Blackcompany

Or surround your door/container with a trigger box, then attach your OnHit script event to that trigger's reference. --HawkFest (talk) 08:58, 3 December 2012 (EST)

Confirmed via reverse-engineering that the Open archetype does still have code to forcibly unlock the target ref. However, to the best of my understanding, Magic Effects can't actually be applied to arbitrary refs anymore; only actors. DavidJCobb (talk) 01:31, 9 June 2025 (EDT)

Spawn Hazard

Reverse-engineering suggests that when the Magic Effect finishes, it'll tell the spawned Hazard to destroy itself as soon as possible. The spawned Hazard's remaining lifetime is set to fHazardMaxWaitTime to ensure that it goes away even if it has e.g. a long de-spawn animation. Haven't confirmed this all experimentally, though. DavidJCobb (talk) 01:31, 9 June 2025 (EDT)

Spawn Scripted Ref

This is labeled "Not used," but in fact it is used by the Throw Voice shout. I can't find any other indication of how this effect works in the CK. Lofgren (talk) 2013-11-16T10:58:19 (EST)

Confirmed via reverse-engineering that Script and Spawn Scripted Ref have identical behavior under the hood. Both effects accept a legacy script (as in, the Script forms that existed pre-Papyrus) as parameters and will try to run said script at appropriate times. Since the Creation Kit can't define legacy script forms anymore, these two archetypes are effectively no-ops. DavidJCobb (talk) 01:31, 9 June 2025 (EDT)

Known Bugs and Crashes

-Equipping Aimed, Fire and Forget spells near a Skeleton actor will crash the game if the Base Effect of the spell lacks casting/projectile information. Confirmed with 4 repeatable CTD's, without warnings or errors. Fixed by adding projectile information to Base Effect. Unable to reproduce crash by equipping spell near NPC or Animal actors, or even using it on them. Only happened with Skeletons and was corrected by re-adding projectile information to spell.

Script

I've found a very specific bug. Self targeting area of effect magic effects of script or stagger archetypes (have not tested with other archetypes) that are used in a lesser power do not have a working AoE unless paired with another AoE magic effect of value modifier archetype (have not tested with other archetypes).

Doing any of these will make it work:

1. Change the magic effect so it has no area (no longer an AoE magic effect).
2. Change the magic effect to the value modifier archetype.
3. Change the magic effect to target actor or target area delivery type.
4. Change the lesser power using it from a lesser power to a spell.
5. Add a second magic effect to the lesser power with an area of effect. (The first effect's AOE is limited to the second effect's.)

--Fg109 19:35, 1 April 2012 (EDT)

Disabling "push away"-effect on dead targets

Is it possible to disable this "push away"-effect caused by projectiles from a spell on dead targets/actors? I already tried the flags "No Hit Effect", "No Hit Event", "No Magnitude", "No Area" and "Painless", but it changed nothing. I also exclude dead actors in the conditions, but it also changed nothing. Is there no way to disable this? --Kahmul 12:23, 25 April 2012 (EDT)

4 years old, I know.. but I think when an actor is dead, they are in "ragdoll" mode. So one would probably have to use ForceRemoveRagdollFromWorld - ObjectReference.

Sounds

I haven't tested this for all of the sound entries, but the Release entry only plays the first .wav in the Sound Description set, rather than choosing one randomly as you would expect. —Vinifera7 (talk) 22:11, 25 August 2012 (EDT)

Base Cost and Skill Usage Mult

I've removed a note stating that Base Cost and Skill Usage Mult had no effect on custom effects because in my testing, they worked fine. What I did was to create a brand new effect and then manually select all the same settings as the Clairvoyance effect, then assign the new effect to the Clairvoyance spell instead of the old one. Modifying Base Cost and Skill Usage Mult worked as expected—increasing Base Cost made the spell cost go up and increasing Skill Usage Mult made the skill increase faster.

One might argue that copying an existing spell's values as a test means I didn't actually create a custom effect, despite it being new, but I think that actually proves the point: if using existing values in a new effect fails to reproduce the problem, then the problem lies somewhere else (i.e., not choosing the correct values to make things work right) or the problem only occurs under very specific conditions, which would need to be investigated and documented. – Robin Hood  (talk) 2013-11-05T00:54:04 (EST)

I have also used these for custom effects with no problems. -- egocarib (talk) 2015-02-13T21:54:38 (EST)

I had put that note there as I wasn't the only one that reported this problem. However, testing it again just now.. it "magically"(haha) works.--Terra Nova2 (talk) 2015-02-14T14:24:47 (EST)

"FX Persist" flag and "On Hit" sound effect problem:

I've just discovered a peculiar quirk of the "FX Persist" flag in my testing of an effect: When the flag is enabled it causes the effect's "On Hit" sound effect to not play. I tested this with a blank ("Script" archetype, no scripts attached) Fire-and-Forget spell effect targeted at Self. --Lobotomy

Area Of Effect Types

I am noticing issues getting certain value modifiers to apply via AOE.

> Value Modifier, Fire and Forget, Self, DamageResist, Recover, Area 300 This is working as expected. When cast, myself and anyone nearby gets the damage resist buff of X for Y seconds.

> Value Modifier, Fire and Forget, Self, Health, Area 300 This is not working as expected. When cast, I get the X health for Y seconds, but not the actor next to me.

I am not sure if the documentation surrounding AOEs is enough, or if they are kind of glitchy or what. --Darkconsole (talk) 2015-02-12T21:01:58 (EST)

Check out the Grand Healing spell.--Terra Nova2 (talk) 2015-02-13T06:14:39 (EST)

Image Space Mod

Constant Effect, Ability type spells do not seem to have their magic effects trigger imagespace mods when they active/inactive based on their conditions. I have a spell with 3 magic effects, which swap out based on how much health you have. The effects swap and I can validate that the proper value modifier is applied at the proper time, but none of the imagespace mods kick in - i was hoping to make the screen progressively darker/redder/contrastier the closer to death you are. --Darkconsole (talk) 2015-07-15T22:40:15 (EDT)

Keyword Dispelling does not work on same-spell recast?:

Something I've encountered while working on fixing a vanilla spell is that apparently the keyword-based dispelling of a spell does not work if the effects in question are from the same spell being cast.

Consider the following scenario: You have a spell with 3 effects, A, B, and C. All three effects have the same keyword. A has the dispel keywords box checked so it handles dispelling keywords. C is only applied if the spell is dual-cast, so normally only A and B are active on the target. So say you then cast the spell on the target. Only A and B are active. Then you dual-cast the same spell on the target again. What happens? A, B, and C are all active. Then you cast the spell normally on the target yet again. What happens? A, B, and C are all still active, but C has a lower duration than A and B because C was never dispelled at all even though it has the necessary keyword for dispelling.

I'm doing more testing, but it seems to be that keyword-based dispelling is only for OTHER spells than the one the effect belongs to.

SkylerModder (talk) 2018-08-23T17:16:00 (EDT)

"Dispel with Keywords" is not a toggle; it acts before the spell is applied. It's also incorrectly/misleadingly worded in the main page at present. The current language says:

If the box is checked, then the list of Keywords indicates Keywords to dispel. If a Spell that is currently active on the target has any Magic Effect that matches any of the Keywords in the list, the Spell will be dispelled when this Magic Effect is applied.

Per testing by Dodoshian in the r/skyrimmods Discord, when you're re-casting a spell that has "Dispel with Keywords", it dispels the current spell and re-applies it. The example being tested was shrine blessings that use the MagicBlessing keyword. Shrine blessing effects dispel the MagicBlessing keyword, but nothing else gives their spell the MagicBlessing effect. Therefore MagicBlessing has to come from this same set of keywords, meaning "Dispel with Keywords" actually means: "I have these keywords, but I'm the only one allowed to use them so dispel anything that uses them first." When you cast a spell like a shrine blessing again, the old blessing is removed and the new cast is applied, which refreshes effects that have a limited duration.

The names of the two exclusive checkboxes in Creation Kit are misleading, which is why the wiki's text was also misleading.

Lummox JR (talk) 12:03, 31 August 2026 (EDT)

Reverse engineering

The internal class hierarchy for active effects is as follows. Indentation denotes subclass relationships.

• ActiveEffect
  • BoundItemEffect
  • CloakEffect
  • CommandEffect
    • ReanimateEffect
  • CommandSummonedEffect
  • ConcussionEffect
  • CureEffect
  • DetectLifeEffect
  • DisguiseEffect
  • DispelEffect
  • EtherealizationEffect
  • GuideEffect
  • LightEffect
  • LockEffect
  • OpenEffect
  • ScriptEffect
    • ScriptedRefEffect
    • SlowTimeEffect
  • SoulTrapEffect
  • SpawnHazardEffect
  • StaggerEffect
    • DisarmEffect
  • SummonCreatureEffect
  • TelekinesisEffect
  • ValueModifierEffect
    • AbsorbEffect
    • AccumulatingValueModifierEffect
    • DarknessEffect
    • DualValueModifierEffect
      • EnhanceWeaponEffect
    • GrabActorEffect
    • InvisibilityEffect
    • NightEyeEffect
    • ParalysisEffect
    • PeakValueModifierEffect
    • TargetValueModifierEffect
      • CalmEffect
      • DemoralizeEffect
        • BanishEffect
        • TurnUndeadEffect
      • FrenzyEffect
      • RallyEffect
    • ValueAndConditionsEffect
  • VampireLordEffect
  • WerewolfEffect
  • WerewolfFeedEffect

Some general notes:

• ActiveEffect defines its behavior using virtual member functions, including start, update, and stop behaviors. (The "update" behavior is run per frame and receives the frame time, measured in seconds, as an argument.)
• Most subclasses override the update handler to advance skill EXP by the frame time. A few don't, however:
  • Handler overridden but skill EXP not granted
    • BoundItemEffect
    • CloakEffect (I think)
    • CommandEffect
    • DisarmEffect
    • EtherealizationEffect (override is itself a no-op)
    • GuideEffect (override is itself a no-op)
    • LightEffect
    • ScriptEffect
    • SoulTrapEffect
    • SummonCreatureEffect
  • Handler not overridden (so skill EXP de facto not granted)
    • CommandSummonedEffect
    • ConcussionEffect (this archetype is a no-op in general)
    • CureEffect
    • DisguiseEffect
    • DispelEffect
    • LockEffect
    • OpenEffect
    • SpawnHazardEffect
    • VampireLordEffect
    • WerewolfEffect

Some specific notes:

• ConcussionEffect doesn't appear to override any of the functions on ActiveEffect, so it's basically a no-op archetype.
• DisarmEffect
  • On start, it attempts to disarm the target. If so, it forces its own magnitude to 1, invokes the StaggerEffect start behavior, and then forces its own duration to 10 seconds. Otherwise, it has no other start behavior. This would all have the effect of guaranteeing a stagger when disarming, and depending on whether and how the effect stacks, it may prevent a target from being spammed with successful disarms.
• EtherealizationEffect works by changing the target actor's "ghost" flag on start and on stop, i.e. basically the same as SetGhost - Actor.
• LockEffect and OpenEffect are the "Lock" and "Unlock" archetypes. The former locks the target container, treating the magnitude as the lock level; the latter unlocks the target container if its lock level is less than the magnitude. However, since only actors can be MagicTargets now, these effects can't actually be applied to a lockable container, so they can't do anything.
• ReanimateEffect
  • I need to look much more closely at this, but I saw a call to the internal actor-kill function in its stop handler, suggesting that this kills the reanimated actor (if they aren't already dead) when dispelled.
• SoulTrapEffect
  • On update, it checks whether the caster or target are dead. If either actor is dead, the effect dispels itself immediately.
  • On stop, it attempts to trap the target's soul, calling the same underlying engine function as TrapSoul - Actor.
• StaggerEffect
  • On start, it calculates the effective magnitude (with taper settings, etc., applied) and attempts to stagger the target.
  • No other behaviors appear to be overridden; after the effect has started, the archetype does nothing.
• ValueAndConditionsEffect ("Value and Parts")
  • Apparently a Fallout leftover used for Stimpaks. It modifies target actor value by the effective magnitude times the fMagicVACPartTargetedMult game setting; it then modifies each of the PerceptionCondition, EnduranceCondition, LeftAttackCondition, RightAttackCondition, LeftMobilityCondition, RightMobilityCondition, and BrainCondition actor values by the effective magnitude times the fMagicVACNoPartTargetedMult game setting.
• WerewolfFeedEffect
  • On start, it checks whether its target is an actor; if so, it flags the target as having been eaten (using a setter that only works if the target is dead). Either way, it then dispels itself immediately.

DavidJCobb (talk) 01:17, 28 July 2026 (EDT)

When the factory functions for effect archetypes are registered, they can be registered alongside a function that checks if the effect is legal. ReanimateEffect is registered with a function that disallows reanimation if the target is alive, in bleedout, decapitated, or is (not has?) an ash pile. It also seems to compare the levels of the caster and target, or the magnitude, somehow. DavidJCobb (talk) 01:32, 28 July 2026 (EDT)

Cloak effects update at an interval controlled by the INI setting [General]fCloakEffectUpdateInterval, measured in seconds. DavidJCobb (talk) 18:04, 23 August 2026 (EDT)

I think the game only does ward absorption of incoming spells when those spells are flagged as "hostile." DavidJCobb (talk) 19:34, 23 August 2026 (EDT)