Ok, so here's what's been bugging me lately. I have a mod installed that adds abilities on a character that fortify abilities and/or skills. If I uninstall the mod will (or should) the value(s) from the abilities remain in a clean saved game?

If the mod has been uninstalled the effects of the mod should not remain on a character. If the perks have remained and you do not want them, Use the UOP options to reset your character.

The abilities, i.e. the actual spell records which show up in your active effects list, will go away unless they are CloneForms.

The modifications to your abilities and skills will not go away. Internally, spell effects (including abilities) aren't actually temporary; values are directly edited, and when the effect is removed (or expires, if it has a duration) they're edited back. If you just deactivate the mod, the game can no longer reference the effect so there's no way to remove it. Because of this, it's essential for any mod which adds constant effect abilities to have a clean-up mode which removes them. If you have Ability-based mods with no cleaning mode, the only safe fixes are to (1) console-remove the effect before deactivating the mod, or (2) console-fix your stats afterwards. Because of the complexities of how actor values are stored -- there are actually six discrete parts, and which part is edited depends on both the AV and the effect type -- it's safest to use option 1. (Someone is working on a mod to intelligently automate option 2, though. It hasn't been announced here yet AFAIK, so I'm not going to ruin the surprise by saying who.)

Edit: It should be noted that enchantments are an exception. If you equip enchanted armor/clothing from a mod and unload the mod, nothing bad happens.

Sorry, I am being stupid here.

I don't understand why removing a mod does not make the ability go away.
If you have an ability to fortify health by 10. You have a usual base actorvalue of x and a av of x + 10. If you remove the mod the ablity goes away and thus the av is again for both x. Why is this not the case? Is this a bug?
Or do you mean a scripted setav? Well, this is logical that the mod must do another setav to make the av as before the first setav.

You're thinking of spell effects like a set of index cards with numbers on them, that are added together when the total value is needed. Internally, it's not like that at all... in fact, abilities are pretty much the same thing as a scripted SetAV. Your base AV actually becomes X + 10 when that ability is added. Upon removal, Oblivion checks the ability definition and sees that it was a +10 effect, so it subtracts 10.

If you unload a mod, the ability becomes an invalid form; the game doesn't even know what magic effect was used, never mind the magnitude. It's marked as garbage data, discarded from your active effects list, and any changes it made are never reversed.

Okay, that clarifies it. Good to know.

Oh darnit.

Ok, thanks for the feedback. I will definitely keep the enchantments method in mind though.

EDIT: Ok it seems there is a second opinion on this matter. I'm retracting my request to have this locked for now.

This sounded wrong to me, so I just did a test and confirmed that this is not true. When you deactivate a mod that included an ability with fortify or drain effects and fire up a savegame, the ability is removed *and* the attribute is restored to what it should be, at least it does for the player. This works for both ability spells and token enchantments.

Note 'player.getAVMod max' will not include fortify/drain effects from abilities. GetAVForBaseActor seems identical to getBaseAV and will return the base with abilities applied.

I'm not entirely sure how it works under the hood. I think what it does is when the ability is added or token equipped, the actors attrs are changed and ActiveEffect records are added to the actor that include the magnitude. When the mod is deactivated, the original ability or enchantment record is an invalid form, but the ActiveEffect records are in the savegame, and are removed and the actor's attributes corrected.

This theory seems to be supported by my observations of what SetNthActiveEffectMagnitude does... it updates the ActiveEffect record magnitude *without* updating the actors attribute. Then when the mod is removed, the actors attributes are restored by the wrong updated magnitude. This makes SetNthActiveEffectMagnitude very dangerous and almost useless, unless perhaps you use it in conjunction with modAVMod to also apply the changes to the actor.

It also means that using things like SetNthEffectItemMagnitude to mess around with abilities and token enchantments will only change the effect when the ability is added or token equipped, and will have no effects or nasty side effects on actors that already have the ability or token equipped. Removing an ability or un-equipping a token will adjust the actors attributes by the ActiveEffect record magnitude from when it was applied, not whatever magnitude the ability/enchantment has at the time it is removed.

Hmmm...ok now I'm really confused.

To clarify, I started the topic because this issue had to deal with my mod http://www.gamesas.com/index.php?/topic/1125389-relz-class-advantages/page__p__16532170#entry16532170. My mod does add Fortify ability effects to the player character AND NPCs. From the time my mod was in development and through release, I swear that are reverted properly when Class Advantages was deactivated. It just so happens that I was looking into a bug report when I discovered that the stats from the effects no longer reverted properly after deactivation.

Pretty sure this is the case for the player, yes. GetAVForBaseActor has the advantage of not printing anything if the console is open when it's called, which is an increasingly annoying behavior now that we've got event triggers and many things can be tested from the console without having to return to GameMode for processing.

Anyway. My information is all secondhand rather than from personal testing, and in light of ABO's experiments it's likely I've misremembered something. However, my primary source is JRoush, and since he's successfully reverse-engineered and modified both magic effects and AV handlers, I consider him the definitive expert. I'm very certain that (1) there are circumstances where spell effects are not properly removed when a mod is unloaded, and (2) that some effects are applied differently to NPCs than to the PC so testing on one does not necessarily extend to the other. Seems I need a refresher on the details, though, and with direct access to the code it seems silly to spend hours anolyzing in-game behavior; so I'm gonna see if I can get JRoush in here to set us all straight!

Tejon is correct. When you remove a mod there is absolutely no guarantee that your savegame will even be playable afterward, much less "clean." The fact that you can get away with it so often is a testament to careful mod design and pure dumb luck.

Case in point: if you save a game while a mod-added magic item is active on a target, and then reload the game without that mod, the item will have disappeared. The actual effects of the magic - altered stats, summoned creatures, etc. - remain permanently.

There is an exception, though. When a savegame is loaded, the engine will recalculate the 'Max' component of the player's actor values. This is the component affected by some magic effects (Fortify,Drain,Paralysis,Feather,etc) from some kinds of magic items (Potions, Poisons, Enchantments, Spells, Powers, Lesser Powers, and Diseases). Any combination of those effects and magic items that is active only on the player is safe to remove. Abilities behave differently (they affect the Base AV component), so mod-added Abilities are not safe to remove. Other kinds of effects (e.g. summons or script effects) are not safe to remove. And nothing is safe to remove if it is active on someone or something other than the player.

@ABO - in principle, you are right. Information on Active Effects (including their magnitudes) is stored in the savegame. Unfortunately, there is not enough information for the game to accurately reverse "orphaned" active effects, so it simply ignores them. One of my goals with the Oblivion Magic Extender is to address this problem, which will render this entire thread moot. But that's for the future

This seems to slightly contradict my testing, which was admittedly only done on the player, and only using drain attribute abilities and enchantments. My tests seemed to show that drain attribute abilities from a mod that was removed *did* get correctly removed and the attribute restored. I will run my tests again to make sure, and also experiment with NPCs next.

I've just tried it (as I did before my original post, just to be sure), and the results confirm what I said above. Drain Attribute Abilities are not safe to remove.

You are correct... my mistake was I was using speed drains and also had RL installed which recalculates and sets attributes based on skills and applied abilities, so it was correcting for the removed drain abilities.

There is also a subtle difference between how the player and other actors are handled... token drains for removed mods are corrected on the player, but not on other actors. It seems that other actors treat both ability and token drains as "getAVMod max" changes which don't modify "getBaseAV ", but for the player ability drains don't show as "getAVMod max" changes and do modify "getBaseAV ". It also seems getBaseAV and getAVForBaseActor are identical for both the player and other actors with both ability and token drains applied. After the mod was removed, actors still had "getAVMod max" changes applied even though the effects had been removed.

It seems it would be possible to have a quest that constantly repairs actor stats for removed and buggy mods. It would iterate through nearby actors, iterating through their ActiveEffects to calculate what "getAVMod max" should be and setting it to that. It could also optionally repair "getAVMod script" and/or "getAVMod damage", though those are likely to interfere with other mods using modAV.

This would be possible for the Max modifier, assuming that nothing but known magic effects were altering it. Bear in mind that scripts can change it now too - for example, a scripted magic effect intended to imitate Paralysis might use "ModAVMod Paralysis Max 1". Such a script would be a Bad Idea - as we've seen it would fail on the player after a save/reload cycle - but the possibility is there. Basically, it boils down to your repair script taking sole "ownership" of the Max modifier for all affected AVs.

Changes to the Script modifier are, by definition, made by scripts and impossible to predict. Attempting to "repair" this would mean just setting it to zero, and there are already a http://www.gamesas.com/index.php?/topic/1139904-relz-stat-cleaner/ http://www.gamesas.com/index.php?/topic/1136566-relz-unofficial-oblivion-patch-320-unofficial-patch-supplementals/page__hl__uop that do that.

The Damage modifier, as it's name suggests, is intended only for effects that are not meant to be "undone", even when the mod that caused them is removed. Any attempt to alter this value would essentially be free and continuous healing of all your stats, which is not desirable.

Wow, those are not very good news (even though having accurate information is priceless). I understand now why I was always ending up with messed up stats, even though I always followed uninstallation instructions for the few mods that have some. It seems that all mods that alter stats or use magic effects on the player in some way or another need special instructions to remove after all.



JRoush and ABO, can you confirm this? I think Kuertee mentioned that he's using unplayable invisible enchanted clothing to safely apply modifications to the player stats and skills, and I'd love to know if that works well and if there are any limitations.
If it's a good technique, quite a few mods such as Stealth Overhaul and Realistic Fatigue would benefit from a rewrite using that.

There are disadvantages to this technique as well, particularly if the adjustments need to react to game events in real-time as is the case with precisely the mods you mention. Also, it appears this only works on the player, so Realistic Fatigue doesn't really benefit from it.

Ultimately, there's no truly safe solution. For the best balance of responsiveness, ease of scripting and player-visible information, I think Ability effects are still king in most situations.

Exactly this. It will work for the player, but nobody else. An equivalent (and perhaps easier) approach would be to store the bonuses in a quest script and use "ModAVMod Max " inside a GetGameLoaded check.

A few things to note:

• Non-player actors will generally reset themselves if you leave their cell for long enough. It's likely that this will erase any "corrupted" stats from careless mod makers. I'm not sure when or if this would apply to persistent NPCs.
  
• If you want to change the magnitude of an Ability or Enchantment effect you should (1) remove it, (2) use SetNthEIMagnitude, and then (3) reapply it. Don't use SetNthAEMagnitude for anything but Damage/Restore effects.
  
• If the Base value for Skills or Attributes exceeds 255 it will wrap around to 0. Since Abilities affect the Base value for the player, they are not always a good choice for Skills and Attributes. Also, Ability bonuses to skills will grant mastery perks as a side effect.

The bottom line is that your users will probably need to perform some 'Uninstallation' before they can safely remove your mod. That may change with a future version of OBME, but for the time being it is immutable.

Darn. I'm really looking forward to that foretold version of OBME, then! (I imagine you'll hijack the magic effects code and ensure they are tracked in the OBSE savegame more reliably than they are now... or something of the sort.)

This has the notable disadvantage of not showing the player why an attribute is altered. After illusions of safety vanish, there's still that one big remaining draw to using spell effects of some sort: they can check the Active Effects page of their spellbook to see most of what's going on. (And since I believe altering Max always turns a skill or attribute red or green, they're very likely to wonder.)


Damage/Restore, I think? Dangerous typo, there.


Agreed that using abilities to edit skills is generally a bad idea all around, but using them on attributes is common practice and generally doesn't hurt anything. Anyone who doesn't simply use ModAV probably knows about the 8-bit base value and takes steps to avoid breaking it. Elys Uncapper (and Legendary Mastery before it) only raises the normal-advancement cap to 200 to leave some headroom, and uncap-friendly advancement mods follow the same convention. There's potential danger, but a high awareness level. Ultimately it's just another tool in the box; the most important thing is knowing exactly how that tool works.

That being said, with OBME in play I think the real winner is going to be diseases. If a disease contains no hostile effects you don't get any message or screen blur when it's applied, or special NPC reactions as far as I've seen; and with OBME, you can make a non-hostile drain. I already use this technique in Birthsigns Expanded for the Steed's encumbrance reduction, because Feather doesn't work as an ability but does as a disease.

Good catch. Fixed it above.


I'm afraid a 'Cure Disease' spell is going to ruin your whole day :ermm:
With OBME in play, you can make Abilities that affect the Max or Script modifiers instead of the Base. That would be a better option, for the time being. Assuming you're using OBME, which ZenshinZenrei may not be interested in doing.

My tests show that equipping slotless enchanted tokens will be safely removed when the mod is deactivated, but only for the player. For NPC's the drain/fortify will not be correctly removed when the mod is deactivated.

Yeah, the delay for addItem/equipItem is a PITA. My tests seem to show you can addItem/equipItem in the same frame, but it takes 2 frames after that before the stat change is applied. Also, unEquipItem takes a frame or two, so you cannot unEquipItem/ SetNthEffectItemMagnitude/equipItem in the same frame. And then there's the message and sound spam... AFAIK there is no way to remove the equip/unequip sounds. The good news is addItem/SetNthEffectItemMagnitude/equipItem will apply the magnitude you set at the time you call equipItem, even if you change the magnitude later in the same frame and before it is applied. This means you can have a loop iterating through a bunch of actors equipping the same item with different magnitudes. Also unEquipItem will correctly remove the applied affect magnitude, regardless of what magnitude the effect is set to at the time you unequip it.


I would suggest that even though ModAVMod lets you do this now, setting it to values that don't correspond with the AEMagnitudes would be a really bad idea. It would not surprise me if some stat-change operations or cell reloads or something in Oblivion would re-evaluate and "repair" the max value from ActiveEffect Magnitudes, even if reloading a savegame doesn't. Part of the reason changing 'script' offsets using ModAV was so bad is there is no way of checking and identifying what applied it... we shouldn't start messing with "max" offsets in the same way, if you want to do that just use "script" offsets.


This is kinda handy and mildly reduces the need and complexity of cleanup after removing a mod... you would only need to cleanup the actors you can still reach in loaded cells. However, it also implies that arrays of "applied actor ModAVMods" can get out of sync with what has actually been applied... your array might say you changed an actor's attribute but the actor may have been reset.


I'm going to experiment with using equipped slotless enchanted tokens, and using "SetNthAEMagnitude" together with "ModAVMod max" to keep the AEMagnitude in sync with the max offset. This hopefully should give me the best of both worlds; actor attr changes that are correlated with ActiveEffects that can be instantly changed without requiring an unEquipItem/equipItem delay.

It would also be interesting to see what GetTotalAENonAbilityMagnitude and GetTotalAEAbilityMagnitude report when ActiveEffects don't correspond with the max offset... I suspect it iters through AE's to calculate a value, and hence can be used to get what "max" *should* be set to.

This has the notable disadvantage of not showing the player why an attribute is altered. After illusions of safety vanish, there's still that one big remaining draw to using spell effects of some sort: they can check the Active Effects page of their spellbook to see most of what's going on. (And since I believe altering Max always turns a skill or attribute red or green, they're very likely to wonder.)

Note that this is the big difference between Abilities and Enchantments (or any non-ability effects); Ability drain/fortify effects do not make the attribute red/green, only non-abilities do. This means Abilities are not as great for pointing out to the player they have something affecting them. I think even modAV "script" changes make that attribute red/green, but they don't show anything in the ActiveEffects menu so they are a bit mysterious still.

The fact that Abilities apply a bit differently to the player and NPCs is also disturbing... (on the player it changes getBaseAV, on NPC's it doesn't).

Agreed that using abilities to edit skills is generally a bad idea all around, but using them on attributes is common practice and generally doesn't hurt anything. Anyone who doesn't simply use ModAV probably knows about the 8-bit base value and takes steps to avoid breaking it. Elys Uncapper (and Legendary Mastery before it) only raises the normal-advancement cap to 200 to leave some headroom, and uncap-friendly advancement mods follow the same convention. There's potential danger, but a high awareness level. Ultimately it's just another tool in the box; the most important thing is knowing exactly how that tool works.

I don't think Abilities are a problem for modifying skills, provided the applied affect is small and you don't mess around with it too much... ie permanent small effects.

That being said, with OBME in play I think the real winner is going to be diseases. If a disease contains no hostile effects you don't get any message or screen blur when it's applied, or special NPC reactions as far as I've seen; and with OBME, you can make a non-hostile drain. I already use this technique in Birthsigns Expanded for the Steed's encumbrance reduction, because Feather doesn't work as an ability but does as a disease.

I've considered diseases too... but I'm a little wary of how it might interact with disease mods (like my own RealisticHealth), the problems with cure disease, and the whole "catching" thing is a bit disturbing too. I've also considered repeated application of short duration spells or potions, but these seem to have too much potential for bad interactions with other stuff.

Of course none of these deal with the fact that the effects are not correctly removed when the mod is deactivated, which was part of the original appeal of Abilities and Tokens. Now that I know that I'm kinda tempted in RF to just use modAV and take ownership of the whole "script" offset for the stats I care about. This will not play nice with other mods using modAV on NPCs, but currently most of the problems I've had reported appear to be other mods messing badly with NPC stats, so doing this will "repair" the damage done by other mods. I can then provide an uninstall.esp that just zero's out the script offsets of nearby actors.

Not if I continually verify that the effect is on the actor, which I do, for that reason.


And break any non-OBME-aware mod which checks Ability values to determine what the Base AVs would be without them. (Though granted that for the specific case of Feather, this would probably work; the reason it doesn't work as an ability is that Encumbrance formulas ignores the Base value.)

Think I'd rather run the risk of possibly having to ask shadeMe to make Vector verify that a disease is hostile before spreading it, which it can do even without OBME awareness.