Yeah. If you no longer want to use a mod, you should be going back to a save before the mod was installed just to be on the safe side. Using saves after removing mods is only supported so far as the game shouldn’t crash.

Here's what I found in regards to extending Scripts and compatibility.

Summary: Extending a Script will create two sets of Variables. One set is scoped in the new Script. Any new Functions in that new extension will use those variables. And another set is still scoped in the original Script. Any Functions that run from this original Script will use that second set.

(Note, this could get quite confusing. Mainly because I'm using very similar names for different objects. Sorry.)

Mod A and Mod B wants to support PlayerVampireQuestScript. Let's describe ModA and ModB independently and working on their own:

• PlayerVampireQuestScript has a bug that prevents the player from changing to the next stage of Vampirism if the player is in combat. This results in the player getting an additional 12 hours in the current Vampirism stage.
  Ok, so ModA tries to fix this bug by extending PlayerVampireQuestScript, removing the original and adding it's own. We'll call this script ModAPlayerVampireQuestScript.
  It only needs to change the OnUpdate () Function so that's all this new Script has. All other Properties and Variables are still scoped in PlayerVampireQuest.
  So, the game runs...all access to the Functions, Properties and Variables in PlayerVampireQuest are working fine. Only OnUpdate () is ignored because the OnUpdate () Function in ModAPlayerVampireQuestScript is used.
  Everything is good, the bug is fixed.
  
• ModB wants to adds new Vampire features. For e.g.: delay next transformation by feeding on newly dead NPCs, feeding off companions from the Dialogue, etc. It does this by manipulating the LastFeedTime Propery in PlayerVampireQuestScript.
  So, ModB needs a property that points to the Vampire Script, right. So, in it is a property that points to the Quest PlayerVampireQuest:

  PlayerVampireQuestScript Property questVampire Auto

  (Can you imagine the problem, now?)
  To delay the next transformation, ModB puts forward the LastFeedTime in PlayerVampireQuestScript by one day when the player activates a dead NPC that just died:

  questVampire.LastFeedTime += 1

  With the mod active, when the player loots a newly-dead NPC, his current Vampirism Stage is extended by one day.
  Note that LastFeedTime is GameDaysPassed. It is set by PlayerVampireQuest when the player feeds.

What I found when both have become active: (Yes, I built both and this is what happened.)

• My Player feeds on day 15 of the game. So LastFeedTime is 15.
  
• In the middle of that day (15.5), I loot an NPC I killed. So, ModB does: questVampire.LastFeedTime += 1. This ensures that Stage 1 is prolonged and Stage 2 will not happen for another day. With a Debug.Notfication (), the value of questVampire.LastFeedTime is confirmed as correct: 16.
  
• However SQV PlayerVampireQuest shows that LastFeedTime is still at 15.
  
• So, I add a Debug.Notification () to the OnUpdate () in ModA to check that ModB is updating LastFeedTime properly.
  
• Back in the game, when OnUpdate () is triggreed, LastFeedTime is confirmed as correct at 16.5.
  
• But SQV PlayerVampireQuest still shows it at 15. I ignore this, thinking that ModA should handle it. But when I eventually transform 2 days later, I transform into Stage 3 - not Stage 2. I totally skip Stage 2. I should have transformed to Stage 2.

Here's what happens:

• Even if LastFeedTime was correct in the OnUpdate() function of ModAPlayerVampireQuestScript (Remember we extended the normal Script to this?), LastFeedTime was still at 15 in other functions (e.g. VampireProgression ()) of PlayerVampireQuestScript.
  
• ModB was modifying LastFeedTime in the PlayerVampireQuest. Because ModAPlayerVampireQuestScript is attached to it, the changes are scoped in that.
  
• Changes to that variable are not passed on to the original script, PlayerVampireQuestScript. Any functions that ModA doesn't override (e.g. VampireFeed (), VampireProgression (), etc.) used the Variables in PlayerVampireQuestScript even if it is not attached to the Quest.
  
• Any 3rd-party mod will not be able to modify any of those - making ModA incompatible with ModB. ModA is the culprit here because it totally changed the Vampire feature and made it incompatible with anything that tries to use the standard, default and already-established features.

Yet it still does if the mod in question added a spell which the player used, and then has a chance to appear in the general stats menu (I think listed as favourite spell or something?). If the mod is then uninstalled the player will crash when attempting to view those stats. Can ''fix'' it relatively easy by just spamming some vanilla spell so that one takes the place in the menu, but many players won't know about that.

.
Sorry if this is getting off-topic, but if http://www.gamesas.com/user/176330-arthmoor/ is right, then this is, potentially, a bigger problem which may affect things outside of Papyrus scripts and nailing it could have the potential to solve a few other problems as well...

Arthmoor is correct. Whether they be Variables, Properties or Registered Events. They stick.

Variables and Properties are not too much of a worry, because they'll just get dropped for that session. They will not, however, be removed from the saved game UNLESS the Script they are attached to are recompiled without them. I.e. The Script is recompiled and active but without any Variable and Property declarations. What will happen (as I've experienced) is that the game will the values for them from the saved game, find their parent Script but will find no slots to insert them. So, the game will remove these Variables and Properties from the saved game.

Registered Events, however, are more of a worry. If the Script still exist even if the ESP is not active, they will keep pinging the Script. Of course, the following operations from that Event will fail. However, the Event will keep pinging the Script. That's why it's best to use RegisterForSingleUpdate () instead of RegisterForUpdate (). Other Events, however, will have to be unregistered properly. That's why it's essential to include an "uninstall" procedure in your mods. But this is a "best practice", anyway and should be built with any mod.

Persistent data in saved games are hinted in the Wiki: http://www.creationkit.com/Save_File_Notes_%28Papyrus%29 And here is my tests in regards to persistent Events on inactive mods: http://www.creationkit.com/Talk:Save_File_Notes_%28Papyrus%29 (in the 2nd section titled: ESP and Script deactivation tests - OnUpdate () Event, Variables and Properties ())

I've just done a very interesting discovery about that (maybe someone else already noticed it, idk. Sry in advance if it's the case) !

It seems that only abilities that change actor values (with a Value or a Peak Value modifier) are still affecting players values if a mod is disabled before an unstallation process !

If it's correct (and it seems to be), we should never use abilities to change actor values, but regular spells.

-> In my mod project I was using constant abilities to mod HealRateMult, MagickaRateMult, and StaminaRateMult. If I was disabling my mod before a scripted uninstallation process these modified values were still affecting the player.
I've just tried to replace these abilities by regular spells (wich have the exact same custom MagicEffects), and now if I disable my mod without any uninstallation process to dispel these MagicEffects -> the modified values of my mod no longer affect the player
*Don't forget to check the "Recover" flag in your custom magic effect tab.

*Note that even if you can select "constant" type for a regular spell (with constant ME), you must set a duration for each ME of the spell !
But just set a very long duration, for ex of 5000 days, and it's really like the spell was constant. You can even recast the spell by a conditioned script inside the magic effect or from another script to be sure that the spell will always be there if it's necessary.

*If you want to avoid the IG magic effects menu to display this very long duration : simply create a fake ability which will be cast with the real spell to display it in the menu, then simply hide all magic effects of the real spell by checking the "Hide in ui" flag in the magic effect tab.


I've just done some tests, and it seems to work, but please don't hesitate to test by yourself and to give feedback here ! Imo, this kind of game mechanism seems very important to understand for the modding community.

I've done some tests with these actor values : DestructionPowerMod, RestorationPowerMod, MarksManMod, OneHandedMod, TwoHandedMod, SpeedMult, HealRateMult, MagickaRateMult, and StaminaRateMult. It's working for all these values.
-> I've also tested with constant diseases, and it's working as regular duration spells : actor values wont be anymore affected if a mod is disabled without an uninstallation process. But be careful cause diseases will be dispeled by altars or potions.

*I'm only working with custom magic effects, so idk if it's working the same way with vanilla magic effects.

See you.
PS : sry for my none really fluent english, but I try to do my best ^^'

I thought I'd read this and see if I could pick up a few pointers.
The thread started off well, but then halfway through the first page it got hijacked. After that, it proceeded totally off course by discussing individual problems of individual mods, as opposed to, tips for all mods in general. I just gave up reading.

Could you start another Tips for mod Compatibility thread and hope that it stays on topic.

Hey Tamb0, I try to update the first post of the thread to include the tips from the replies below. So for the general tips, only that first post is required reading. The replies below are good to discuss about the actual tips.

Hey Thanatos00, this is true - even from Oblivion. That's why it's important for us mod developers to have an in-game uninstall utility to remove these effects. In my mods that have these effects, I ask the user to do a console uninstall with: "setpqv uninstallNow True" before deactivating the mod.

If it's correct (and it seems to be), we should never use abilities to change actor values, but regular spells.

But what you found about spells not sticking is great! I assumed that they stuck also like they did in Oblivion. That should make the life of users and mod-authors a lot simple: just activate/deactivate the mod as you wish. Will work on converting my mods from using Abilities to Spells. Thanks, mate!

Np, you're welcome kuertee

I tried it again and again, and it's working great.
We finally have a 100% clean way to ModAV ^^

PS : Thanks to have quoted me in the 1st post.
If something is wrong with my english dont hesitate to correct my quote

Sry for this "bump" but it worth it.

Maybe a much easier method :
Simply add a condition to each MagicEffect of an ability (with a custom globalValue for ex), and the problem is gone. When you'll desactivate your mod, global will be reseted, so each MagicEffect will be dispelled, and ActorValues will be restored.
Thanks to Gérauld for finding that =)

In brief to ModAV by spells :
-Use an ability with MagicEffect conditioned by a custom var which will be reseted if your mod is disabled.
-Regular duration spells, and constant diseases are not concerned by this problem : any modified AV will be restored if your mod is disabled.

Too good, Thanatos! Thanks to you and Gerauld for sharing these!

I've tried this trick and it's not working for me... I have an ability with a constant Magic Effect (in this case, carryweight peak value +10), targeted based on a global in the same mod with a value of 5. When uninstalled, the Magic Effect remains. I made sure the Recover flag was set, and I'm stumped.

Can you or Gérauld post your mod file, or a screenshot of the Magic Effect settings you're using?

It worked in my tests and have converted my two mods that have detrimental effects (Eat and sleep and Battle fatigue and injuries) to using this. My Battle faituge and injuries mod has a CarryWeight penalty like yours.
I attach the Condition at the Spell level for each Magic effect rather than at the Magic effect level.
I've found while I was getting conditions to work link to Papyrus (http://www.gamesas.com/topic/1354316-conditions-in-papyrus/) that the Conditions at the Magic effect level are triggered only at the onset of the Magic effect. Once triggered, it is either applied or removed.
However, at the Spell level for each Magic effect, the Conditions are checked at each game update/tick and so the Magic effects turn on or off.
If your set up is not like that, try that and let us know how you go, please.

That's completely different than what Thamatos00 posted:


He specifically says to install the condition on the Magic Effect, and it works with Abilities, which is what I tested.

So... what's the deal? Does it work with Abilities, or is Thanatos00's write-up wrong?

EDIT: Ok, I got it. Thanatos00 is not wrong, the detail I was missing is that the condition has to be placed on the Magic Effect entry *in* the Ability, it can't be put on the Magic Effect's normal entry. (kuertee is right; that condition only gets tested when the Magic Effect is initially applied.)

WOOT this solves MANY of my problems, thanks all.

Cool! Now, all we need is a way to change the Magnitude of spells. E.g. so that we only have one Ability. E.g. for sleep-deprived penalties that increases the longer you sleep instead of how we currently need multiple Abliiities with small increments. E.g. for my Eat and sleep mods each hour penalty has an Abiliity that I add/remove depending on what is required at every hour.
I'm thinking of setting up an ESM with a multiplier perks that all my Abilities are attached to. And my player penalty mods (Eat and sleep, Battle fatigue and injuries) uses that ESM as a master.
So when I need to increase the sleep-deprived penalty to the Ability, I simply remove the previous Perk and add the new Perk.
But this needs some testing - so I'm not sure when I can get around to this.

Amen to that. FIxing Real Dovahkiin Strength to use this new method required me to change 50 abilities, it took awhile and I think I got carpal tunnel, heh.

What's the best way to add to a merchant's items for sale? For e.g. I want to add an item to all merchants that sell ingredients. I want it so that any new NPCs that sell ingredients will have a change to sell the new item.

I can sort of see how ... but I'm not sure it is all scriptable:

• Can you iterate through the LIST of Members in a Faction (like you can through a list of items in a list)? If you can, then you could iterate through the MerchantFaction (using a Do While Loop and Index values ...)
  
• Is the Merchant Chest a linkedRef (I sort of think it is, but I can't remember)? If it is then it should have a SpecialKeyword to signify it is their chest. So you can then get the "InventoryList" for each member of the MerchantFaction (http://www.creationkit.com/GetLinkedRef_-_ObjectReference)
  
• IF you can do both of those then you can add an item to those lists (having checked for it not being present), using AddForm (or something similar)
  
• Then you need to hook up an event - OnUpdatePlayer every 24 hours, as a rubbish example - to do the checks/loops and add the item to any new merchants that have appeared.

(I can't think of another way, and I'm not sure the way I have thought of will work )

I would try this:

• Create a quest started by the "Player Activate Actor" event
  
• Hook it up to the "Player Activate Actor" SM Event node
  
• Condition it using event data so the quest starts only if the actor is in the "JobMerchantFaction"
  
• Add a couple dozen optional reference aliases to the quest
  
• The match conditions should be:
  
  • GetIsObjectType Container == 1
    
  • GetItemCount FormListOfIngredients >= 10
• Check the flags for "In Loaded Area" and "Closest"
  
• The container reference aliases should all have a script to add your item(s) OnInit()
  
  • Or you could just add the items to the alias' inventory

EDIT: Might want to have an additional condition that the container doesn't have any of your items already. Also that the actor isn't dead and the player isn't sneaking.

Hey RandomNoob,

I actually found the answer in dwarfmp's post in this thread: http://www.gamesas.com/topic/1356345-adding-items-permanently-to-respawning-chests-without-editing-said-chests/page__view__findpost__p__20602845

I wanted to add the method in this thread but I was waiting on someone from there to reply to my question in regards to Chesko's method of resetting the Quest (i.e. and so the Aliases) adding new items without removing previous items. What this means is that after a while you'll end up with 1000s of those custom items that the merchant sells.



What I found with dynamically searching for certain actors (particularly merchants - i.e. in my Professions mod and now in my Battle Fatigue and Injuries mod to sell bandages), is that the developers have not been consistent in adding their actors to the proper Faction. E.g. some Draugr are actually not in the Draugr faction.

Dwarfmp's method worked for me. And it looks quite "clean" and compatible.

Thanks anyway, mate.

Yeah, I was aware of that thread too, which is why I also suggested to add the items to the reference alias' inventory at the end. The rest of the stuff is just so that you can try to dynamically find and add items to a merchant's vendor chest in the game.