Compatibility with other mods - tips : V

» Wed Jun 20, 2012 4:46 pm

Here are some of my tips to make your Script mod as compatible as possible with others:

I've removed this. Reason is in this post: http://www.gamesas.com/topic/1362474-compatibility-with-other-mods-tips/page__view__findpost__p__20568706
Do not change the origrinal Script files.
Spoiler
Some work-arounds:
Find ways to interact with it from your own separate Quest Script.
E.g. in my Vampirism Tweaks mod, I wanted the player to heal Health, Stamina and Magicka when they feed.
So, instead of changing the PlayerVampireQuestScript, I created my own Quest script that monitored the "Necks Bitten" stat.
Extend it. Then detach the original Script from its parent and attach yours. Remember to populate the Properties of your Script with the value of the original Script.E.g.:
ScriptName kuerteePlayerVampireQuestScript extends PlayerVampireQuestScript Conditional
When you do this, your Script extension takes on all the original Script's Properties and Functions.
So, any Script that changes the original's Properties and calls the original's Functions will also be called on yours.
Do not enable what your mod didn't disable. Indirectly, track what you disabled so that you know which to renable.
What this means is easiely explained with an example.
For e.g. another mod disables player controls. But you need it disabled, too. So you do. Then you enable it. But since the other mod still needs it disabled, you've broken it because you've renabled it.
Spoiler
Solution:
- check if the controls have been disabled already.
- If not, disable it and set a variable so that you know your mod disabled it.
- When you need it renabled again, check that flag and enable if that flag was set.
This way, the two mods work in a first-come-first-serve basis. The mod that disables a game object, enables it. If you find Bethesda's Vampire feeding camera buggy sometimes, it is because of this problem. They enable/disable player controls willy-nilly.
ModActorValue: keep track of the value of your modification. And restore only that value when you need it restored. Give your user a way to restore your changes with an uninstall process. Usually, this is a Quest that they have to run separately via the console or a menu-sequence-control that you build.
Spoiler
- If two mods affect/apply ModActorValue to the same ActorValue, and one or both do not keep track of their own values and instead uses (GetBaseActorValue () - GetActorValue ()) as an indication of the changes to the ActorValue, one or both mods have corrupted the player's Stat.
- Alternative: Use Abilities. You won't get the same incremental control of modifications but it is a lot safer. And it offers a way for the user to see the changes in their Magic Effects list.
This was a problem in the early days of Oblivion gameplay Script mods. I really don't want to see this here in Skyrim.

They are the three most important factors that I apply in all my mods. Do you use any others?

Replies from others. Click on them to view the actual posts for more info about them.

In Quests, uses Aliases for everything (well, as near everything as you can), rather than the Base Actor/NPC instance - Especially if you are using a Vanilla character/item

1. Aliases get priority in the packages system
2. Almost everything on an NPC is reset once a Quest has finished with the Alias.

Turn on the script prefix feature in the CK, that way any scripts you create will have a XXXX_ prefix...

Ex
EXP_TIF__FORMID.psc/pex
You can have up to four characters in your prefix

Also if you need to edit vanilla dialogue "rename" it, the Creation Kit will automatically make a new script with the new name and keep the old intact.

I learned a lot of useful practices while experimenting, the main one I learned the hard way was not to edit vanilla scripts even if you're changing a feature to do with them directly. You run into a lot of headaches with scripts running when they aren't suppose to, runtime errors mostly. Extending scripts should be a more common practice but unfortunately it is not, I'd guess its because its a more advanced concept for beginners. The plugin determines what script to load, if you edit a vanilla script and add or remove properties, if you disable your plugin but keep the loose scripts your going to encounter plenty of runtime errors....

To add to this, make sure, for your own sanity at least, that you also add something in between those two underscores that will further separate the TIF so you know which mod it belongs to. You can easily run into a situation where even with a prefix you collide with your own scripts if you don't.

ARTH_TIF__0200C74D.psc is nowhere near as obvious as ARTH_TIF_LALNewStart_0200C74D.psc for example. Having two of your own mods with 0200C74D as a form ID, you can probably guess where this would go if this clarification is not made while renaming the script.

One thing I have noticed (and this maybe a minor thing) that a lot of new modders have been asking about adding new items and actors. It seems that there are a few people who are editing the base objects and actors instead of creating new ones. This will eventually lead to major bugs especially if these changes are not intentional. So beginners should be warned not to edit the base objects if they want to make new stuff but to make duplicates and edit them. This is of course a very simple thing compared to the issues above, but I thought I should mention it since beginners don't always know the basics.

I'd like to add a little thing : try to respect original keywords system, to help other mods tracking things added by your own mod.

Keywords can be used to track a lot of things, for ex :
-to track what kind of spell added by other mods are affecting actors.
-to track if the player is eating something added by other mods
-to track if the player is equipping a specific armor part added by other mods
-> about that, some keywords corresponding to armor slots :
Head : ClothingHead or ArmorHelmet
Body : ClothingBody or ArmorCuirass
Hands: ClothingHands or ArmorGauntlets
Feet : ClothingFeet or ArmorBoots
*Unlike Beth, if your create an armor that covers several slots, be careful to add each keyword for each slot that is covered by the armor (Beth have forgotten to add a head keyword to all robes that cover body and head for ex).
-Etc...

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 :smile:

*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 ^^'

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.

» Wed Jun 20, 2012 6:25 pm

In Quests, uses Aliases for everything (well, as near everything as you can), rather than the Base Actor/NPC instance - Especially if you are using a Vanilla character/item

1. Aliases get priority in the packages system
2. Almost everything on an NPC is reset once a Quest has finished with the Alias.

The wiki tutorials do state this ... but only after you've already run away with yourself in the first set of tutorials. It's a bit of pain when you first start doing it, but easy when you're use to it and worth that initial pain

(nice thread

)

» Wed Jun 20, 2012 5:42 pm

In Quests, uses Aliases for everything (well, as near everything as you can), rather than the Base Actor/NPC instance - Especially if you are using a Vanilla character/item...(nice thread

)

Of course! Aliases! How can I forget? There was a question this week about using bases references (or something). I didn't click on it, so I could be wrong in my assumption. And Thanks!

» Wed Jun 20, 2012 3:09 pm

Turn on the script prefix feature in the CK, that way any scripts you create will have a XXXX_ prefix...

Ex
EXP_TIF__FORMID.psc/pex
You can have up to four characters in your prefix

Also if you need to edit vanilla dialogue "rename" it, the Creation Kit will automatically make a new script with the new name and keep the old intact.

I learned a lot of useful practices while experimenting, the main one I learned the hard way was not to edit vanilla scripts even if you're changing a feature to do with them directly. You run into a lot of headaches with scripts running when they aren't suppose to, runtime errors mostly. Extending scripts should be a more common practice but unfortunately it is not, I'd guess its because its a more advanced concept for beginners. The plugin determines what script to load, if you edit a vanilla script and add or remove properties, if you disable your plugin but keep the loose scripts your going to encounter plenty of runtime errors.

Don't get me started on the savegame script quirks. If you need to change a property to point to a different object NEVER use the same variable name, the savegame will not realize the type or object has changed and instead try to fill the property with the saved property ANYWAY and cry about it. As a programmer I had to force myself to get used to this, giving variables new names, I'm still not a number guy though. I don't add numbers to my variables unless they have a purpose other than to be named differently.

» Wed Jun 20, 2012 7:42 pm

One thing I have noticed (and this maybe a minor thing) that a lot of new modders have been asking about adding new items and actors. It seems that there are a few people who are editing the base objects and actors instead of creating new ones. This will eventually lead to major bugs especially if these changes are not intentional. So beginners should be warned not to edit the base objects if they want to make new stuff but to make duplicates and edit them. This is of course a very simple thing compared to the issues above, but I thought I should mention it since beginners don't always know the basics.

» Wed Jun 20, 2012 6:08 pm

...Don't get me started on the savegame script quirks. If you need to change a property to point to a different object NEVER use the same variable name, the savegame will not realize the type or object has changed and instead try to fill the property with the saved property ANYWAY and cry about it. As a programmer I had to force myself to get used to this, giving variables new names, I'm still not a number guy though. I don't add numbers to my variables unless they have a purpose other than to be named differently.

Yeah. This is understandable though. Any Variables or Properties initialised in the main body of the Script will not reinitialise again. We really need a OnGameLoaded () Event which SKSE will provide. In that OnGameLoaded (), you can reinitialise any Variables or Properties you need to change when your mod changes or updated. Or when you simply wish to reinitialise something on game load. I simulate OnGameLoaded () with this start-up Script. It's a bit long-winded but it is 90% accurate in detecting OnGameLoaded (). http://www.gamesas.com/topic/1349590-init-at-game-load-and-init-at-game-restart. Also the Script segment allows for the resetting (resetNow variable), uninstalling (uninstallNow) and updating (version != lastVersion) events.

One thing I have noticed (and this maybe a minor thing) that a lot of new modders have been asking about adding new items and actors. It seems that there are a few people who are editing the base objects and actors instead of creating new ones. This will eventually lead to major bugs especially if these changes are not intentional. So beginners should be warned not to edit the base objects if they want to make new stuff but to make duplicates and edit them. This is of course a very simple thing compared to the issues above, but I thought I should mention it since beginners don't always know the basics.

Agreed. No editting of base objects!

Duplication of items is simple. Just edit an item, change its name, save as new object. However, sometimes, I can see the need for editing a base item and saving it in your ESP. E.g.: You want all spawns of the a Sword of frost to have double the Stamina damage. So, changing the base Enchantment is sufficient instead of creating a new Enchantment, a new sword then adding that new sword to all the levelled lists the original Sword of frost is in. I think this is ok for editing base objects.

However, editing of Actors is a lot more dangerous in regards to compatibility purposes. Best to use Aliases when an actor needs to be changed - even if you only need to add one item to or one spell to the actor. Best to create a Quest, add an Alias, add that item to the Alias. Easy.

» Wed Jun 20, 2012 9:32 pm

Very good topic !

I'd like to add a little thing : try to respect original keywords system, to help other mods to track things added by your own mod.

Keywords can be used to track a lot of things, for ex :
-to track what kind of spell added by other mods are affecting actors.
-to track if the player is eating something added by other mods
-to track if the player is equipping a specific armor part added by other mods
-> about that, some keywords corresponding to armor slots :
Head : ClothingHead or ArmorHelmet
Body : ClothingBody or ArmorCuirass
Hands: ClothingHands or ArmorGauntlets
Feet : ClothingFeet or ArmorBoots
*Unlike Beth, if your create an armor that covers several slots, be careful to add each keyword for each slot that is covered by the armor (Beth have forgotten to add a head keyword to all robes that cover body and head for ex).
-Etc...

» Wed Jun 20, 2012 6:07 pm

...try to respect original keywords system, to help other mods tracking things added by your own mod...

So right! I used those Keywords in your example in my Encumbering Loot Armour and Weapons mod.

» Wed Jun 20, 2012 9:08 am

Excellent thread! And I so wish to see your night-eye shaders again.

» Wed Jun 20, 2012 5:59 pm

EDIT: Nevermind about this.

Spoiler

Here are some of my tips to make your Script mod as compatible as possible with others:

Do not change the origrinal Script files.Some work-arounds:
- ...
- Extend it. Then detach the original Script from its parent and attach yours. Remember to populate the Properties of your Script with the value of the original Script.E.g.:
```
ScriptName kuerteePlayerVampireQuestScript extends PlayerVampireQuestScript Conditional
```
  When you do this, your Script extension takes on all the original Script's Properties and Functions.
  So, any Script that changes the original's Properties and calls the original's Functions will also be called on yours.

I'm not so sure about this one anymore. Though, it is always best to keep the original Script intact, when it is extended, Scripts that have properties pointing to the original will have to be repointed to the new Script. E.g. in my particular case of extending PlayerVampireQuestScript into kuVTPlayerVampirequestScript, I had to change all the Properties that pointed to PlayerVampireQuestScript to point to the new Script of kuVTPlayerVampireQuestScript.

The main problem is that Properties that should link to Quests objects are actually linked to the Scripts. For e.g., 3rd party mods that point to PlayerVampireQuestScript will have to be tweaked so that they point to kuVTPlayerVampireQuestScript and recompiled just to make them compatible with my mod. This is actually a design flaw when viewed in respect to a system being open or closed. Grrr @ Bethesda!

I'm not sure yet how it works/doesn't work. The Property points to the Quest but changes I make to a Property of that Quest do not stick. Investigating...

Excellent thread! And I so wish to see your night-eye shaders again. :biggrin:

Hey AndalayBay, Thanks!

Spoiler

I turned into a Vampire a couple of weeks ago and, though, the new Night eye retains the dark/light information, the "tunnel vision" effect makes it hard to be used except for short period of times. I.e. I removed the duration so that I can use it "properly" (i.e. without have to recast it everytime it turns off) but I found that the tunnel vision effect causes too much eye strain in long periods of time. I'll look into how Shaders work and try to remove that tunnel vision and try to make it look more like my Oblivion Night eye. Not sure when this will happen, though.

» Wed Jun 20, 2012 7:24 pm

I'm getting weird results when I extended PlayerVampireQuestScript to my own, kuVTPlayerVampireQuestScript.

My set-up:
In the CK:

Extended PlayerVampireQuestScript to kuVTPlayerVampireQuestScript.
Detached PlayerVampireQuestScript from PlayerVampireQuest and attached my Script to it.
Populated the Properties of my new Script with the same values as the old Script.

In-game:

Mods that use PlayerVampireQuest updated that Quest's Properties ok while the mod is running.
However, my new Script's Variables (i.e. LastFeedTime, FeedTimer, VampireStatus, etc..) were not populated from the saved-game. This is because the saved game had values for PlayerVampireQuestScript NOT kuVTPlayerVampireQuestScript.

I don't know how to update these from PlayerVampireQuestScript because when I set a Property to refer to PlayerVampireQuest and point it back to the Quest, it'll link back to itself. At this point PlayerVampireQuestScript is detached from the Quest and kuVTPlayerVampireQuest is attached, remember? What this means, is that my Vampire Tweaks mod cannot SEAMLESSLY integrate with the default PlayerVampireQuest.

I think the solution is to create a new Quest (e.g. kuVTPlayerVampireQuest). Attach my new Script, kuVTPlayerVampireQuestScript that still extends PlayerVampireQuest to it. And populate the Variables of the new kuVTPlayerVampireQuest with values from PlayerVampireQuest. The new Quest will need to stop the old Quest, however. But doing it this way will definitely not make it compatible with other mods that rely on PlayerVampireQuest. :S
Also, when I do SQV PlayerVampireQuest, I get the values from PlayerVampireQuestScript and not kuVTPlayerVampireQuestScript.

Maybe rewriting the Script WITHOUT changing any of its existing Function, Variable, and Property names may be OK.

EDIT: When I said SEAMLESSLY, above, I mean SEAMLESSLY when you first activate my mod after being turned into a vampire. So it's only at the initial instatiation of the mod (and when deactivating my mod to return back to the original vampire) would it be a problem. Because at runtime, as the mod gets going, the Properties and Variables of the new Script are accessed and updated properly.

» Wed Jun 20, 2012 7:15 pm

The only thing I did with vanilla things is removing the WISpellDangerous keyword from summons. I got tired of Cloak spells making my long-duration atronochs go poof 2 seconds after I summoned them.

» Wed Jun 20, 2012 7:56 pm

The only thing I did with vanilla things is removing the WISpellDangerous keyword from summons. I got tired of Cloak spells making my long-duration atronochs go poof 2 seconds after I summoned them.

Yeah, I think changing these things in the Objects (i.e. not Script-based) are ok. E.g. I removed the duration of the Night-eye in my Vampirism Tweaks mod - without having to create new Spells for it.

» Wed Jun 20, 2012 10:13 am

Turn on the script prefix feature in the CK, that way any scripts you create will have a XXXX_ prefix...

Ex
EXP_TIF__FORMID.psc/pex
You can have up to four characters in your prefix

To add to this, make sure, for your own sanity at least, that you also add something in between those two underscores that will further separate the TIF so you know which mod it belongs to. You can easily run into a situation where even with a prefix you collide with your own scripts if you don't.

ARTH_TIF__0200C74D.psc is nowhere near as obvious as ARTH_TIF_LALNewStart_0200C74D.psc for example. Having two of your own mods with 0200C74D as a form ID, you can probably guess where this would go if this clarification is not made while renaming the script.

I'm getting weird results when I extended PlayerVampireQuestScript to my own, kuVTPlayerVampireQuestScript.

My set-up:
In the CK:

Extended PlayerVampireQuestScript to kuVTPlayerVampireQuestScript.
Detached PlayerVampireQuestScript from PlayerVampireQuest and attached my Script to it.
Populated the Properties of my new Script with the same values as the old Script.

This was always super bad in Oblivion, and I'm not surprised to learn it's super bad in Skyrim. Probably more so with Papyrus.

It was death to even consider changing a vanilla quest to use a different script. The variable indexing would not match up and you'd simply corrupt the player's save. I wonder if we have similar indexing on properties and doing what you're suggesting isn't also just going to corrupt something. Exacerbated by the way Papyrus sticks to the saves too.

» Wed Jun 20, 2012 7:40 am

...This was always super bad in Oblivion, and I'm not surprised to learn it's super bad in Skyrim. Probably more so with Papyrus.

It was death to even consider changing a vanilla quest to use a different script. The variable indexing would not match up and you'd simply corrupt the player's save. I wonder if we have similar indexing on properties and doing what you're suggesting isn't also just going to corrupt something. Exacerbated by the way Papyrus sticks to the saves too....

I'm actually removing this from my List. The very nature of extending a Script means that the new Script is a totally new Object at run-time.

What I've experienced is that even if my new Script extended the Old Script, Functions in the old Script (i.e. those that I don't overwrite with the new Script) used the values of Properties and Variables in the old Script. But at run-time, any usage (access/update) to the Properties and Variables of the quest were done in the new Script.

So essentially, you'd have 2 separate lots of Functions, Variables and Properties that ran in parallel - even if the old Script has been detached. (Because the new Script extends the old Script, the old Script is still indirectly attached to the Quest.) Functions that are overwritten by the new extension used Variables and Properties in that extended Script while Functions that still reside in the old Script used values in the old Script.

So, currently, it's best to rewrite the logic in the Script - keeping Function, Variable and Property names intact rather than extending it. Adding new Functions, Variables and Properties are ok, of course.

Also, there is no such thing as indexing of Variables and Properties, I don't think. I've been reording my Variables and Properties. However, I can't be 100% sure of this.

» Wed Jun 20, 2012 11:23 am

Very good topic !

I'd like to add a little thing : try to respect original keywords system, to help other mods to track things added by your own mod.

Keywords can be used to track a lot of things, for ex :
-to track what kind of spell added by other mods are affecting actors.
-to track if the player is eating something added by other mods
-to track if the player is equipping a specific armor part added by other mods
-> about that, some keywords corresponding to armor slots :
Head : ClothingHead or ArmorHelmet
Body : ClothingBody or ArmorCuirass
Hands: ClothingHands or ArmorGauntlets
Feet : ClothingFeet or ArmorBoots
*Unlike Beth, if your create an armor that covers several slots, be careful to add each keyword for each slot that is covered by the armor (Beth have forgotten to add a head keyword to all robes that cover body and head for ex).
-Etc...

in addition to this, i would like to add that you should ONLY use these vanilla keywords to correspond to armors of vanilla body types.

for example, let's say you have a helmet with a removable and re-equipable visor. you assign a new body node for the visor so that you can wear the helmet and visor together as 2 separate head items.

the helmet should have the ArmorHelmet keyword, while the visor should have a NEW keyword that you assign to it.

the reason for this is because if you assign the visor the same ArmorHelmet keyword, you will end up breaking several of the armor-related vanilla perks.

the perks query body keywords with a keyword count value equal to 1, going over a keyword count of 1 will throw it out of the conditional boolean, defaulting as false, when in reality it should return true.

same with "LightArmor" and "HeavyArmor" - only apply these to vanilla armor types, even if the extra armor piece is still considered either.

matching set perks will query a total keyword count of exactly 4 (head, body, hands, feet), and going over the amount will incorrectly return false.

» Wed Jun 20, 2012 2:23 pm

Hey AndalayBay, Thanks!

Spoiler

I turned into a Vampire a couple of weeks ago and, though, the new Night eye retains the dark/light information, the "tunnel vision" effect makes it hard to be used except for short period of times. I.e. I removed the duration so that I can use it "properly" (i.e. without have to recast it everytime it turns off) but I found that the tunnel vision effect causes too much eye strain in long periods of time. I'll look into how Shaders work and try to remove that tunnel vision and try to make it look more like my Oblivion Night eye. Not sure when this will happen, though.

I'll be keeping my peepers open for developments! :biggrin:

And I need to go through this thread in more detail later. Looks like there are some tidbits in here that I should be paying attention to.

» Wed Jun 20, 2012 1:57 pm

I'm actually removing this from my List. The very nature of extending a Script means that the new Script is a totally new Object at run-time.

What I've experienced is that even if my new Script extended the Old Script, Functions in the old Script (i.e. those that I don't overwrite with the new Script) used the values of Properties and Variables in the old Script. But at run-time, any usage (access/update) to the Properties and Variables of the quest were done in the new Script.

That would fit better with my understanding of inheritance. Unless you override the parent function to do something different, you're acting on the parent object. Which I'm guessing isn't what most people want.

There are cases though where you'll have little choice. You can't alter the character generation quest (MQ101) without modifying the stage fragments for one. I also found it impossible to block the camera bobbing without directly modifying the MQ101 script. I'm sure other similar things exist and can't be dealt with any other way.

It's good to try and avoid it if you can, that's always best practice, but I don't think it's a good idea to train people to contort things in unreasonable ways just to avoid an edit that might well be necessary anyway.

Unfortunately the nature of Papyrus being what it is, you can't change a vanilla function to do ANYTHING different from what it starts as. The scripting engine will ALWAYS defer to what's been stored in the save even if that's now totally wrong for what you want it to do. I don't like this new setup one bit because of it. It forces a whole lot of unnecessary contortion to change script logic in updates.

» Wed Jun 20, 2012 7:36 pm

I'm getting some really weird results in my tests. So, I removed my kuVTPlayerVampireQuestScript and restored PlayerVampireQuestScript (with added Debug.Traces ()) to the PlayerVampireQuest. I also recasted the Property from kuVTPlayerVampireQuestScript back to PlayerVampireQuestScript in my own Quest.

(In my mod, I change VampireStatus, FeedTimer and LastFeedTime so that the player can: delay the next transformation (when feeding on a nearly-dead body), regress backwards (when feeding on a nearly-dead vampire), trigger VampireFeed () from a dialogue option.)

Anyway, here's the log:

[04/02/2012 - 04:14:27PM] !kuVTQS.checkHealFromFeeding None

So, from kuVTQS, PlayerVampireQuest.LastFeedTime = 52.328758

[04/02/2012 - 04:14:27PM] !kuVTQS.tick questVampire.LastFeedTime 52.328758[04/02/2012 - 04:14:28PM] !kuVTQS.checkHealFromFeeding None[04/02/2012 - 04:14:29PM] !kuVTQS.tick questVampire.LastFeedTime 52.328758

but from PlayerVampireQuest itself, it is 49.219952:

[04/02/2012 - 04:14:29PM] OnUpdateGameTime GameDaysPassed.Value 52.381035 - LastFeedTime 49.219952[04/02/2012 - 04:14:29PM] OnUpdateGameTime FeedTimer 3.161079 VampireStatus (pre)3[04/02/2012 - 04:14:29PM] VampireProgression 4[04/02/2012 - 04:14:33PM] OnUpdateGameTime VampireStatus (post)4

So, when I change, I change to Stage 4 instead of extending Stage 1 by 1 day.

» Wed Jun 20, 2012 2:28 pm

Unfortunately the nature of Papyrus being what it is, you can't change a vanilla function to do ANYTHING different from what it starts as. The scripting engine will ALWAYS defer to what's been stored in the save even if that's now totally wrong for what you want it to do. I don't like this new setup one bit because of it. It forces a whole lot of unnecessary contortion to change script logic in updates.

Papyrus only runs the copy of the function stored in the save if the function was actually running at the time of save, and then only until that copy of the function exits. After the function exits it will use whatever is in the data files instead when it is next called. (See http://www.creationkit.com/Save_File_Notes_%28Papyrus%29#Changing_2 for more information)

» Wed Jun 20, 2012 7:34 pm

I managed to fix my saved game.

What happened was that kuVTPlayerVampireQuestScript was taking all my changes to the Variables. This is because it inherits from PlayerVampireQuest. Any changes to the Variables from the Quest kuVTQ, was applied to the kuVTPlayerVampireQuestScript.

BUT... functions that run in PlayerVampireQuestScript used its own Variables. And so, my vampire changes weren't as I expected.

SO... Debug.Traces () from the Quest kuVTQ would report values from kuVTPlayerVampireQuestScript (). But SQV PlayerVampireQuest would show values from PlayerVampireQuestScript.

To fix my game, I had to recompile an "empty" kuVTPlayerVampireQuestScript. And reattach it to the PlayerVampireQuest. (Remember that I removed it and reattached PlayerVampireQuestScript.)

NOW... The the Quest kuVTQ uses the Variables in PlayerVampireQuestScript. And I can remove kuVTPlayerVampireQuestScript from the PlayerVampireQuest.

Moral of the story: it's actually better to rewrite the original Scripts. Just make sure to back up the Source file first.

» Wed Jun 20, 2012 5:33 pm

All I can think of to say here is; just do things as cleanly as possible. If you can append your stuff onto vanilla content, instead of directly editing vanilla content, that's better 99% of the time. The more records you alter instead of adding, the likely your mod is to be incompatable.

» Wed Jun 20, 2012 12:05 pm

Papyrus only runs the copy of the function stored in the save if the function was actually running at the time of save, and then only until that copy of the function exits. After the function exits it will use whatever is in the data files instead when it is next called. (See http://www.creationkit.com/Save_File_Notes_%28Papyrus%29#Changing_2 for more information)

That being the case, shouldn't you get a clean run if you allow the game to play for awhile after receiving notice that stuff changed? Meaning if I save later down the road, shouldn't I stop seeing the logs mentioning stuff about old variables not matching up?

The problem we're having here is that this stuff doesn't clean itself up. It sticks, and sticks forever. I've got saves loading up that are STILL whining about mods I long ago dropped, or have long ago changed to something new. If this is supposed to sort itself, one would expect that to update, but it apparently doesn't.

» Wed Jun 20, 2012 2:27 pm

Papyrus only runs the copy of the function stored in the save if the function was actually running at the time of save, and then only until that copy of the function exits. After the function exits it will use whatever is in the data files instead when it is next called. (See http://www.creationkit.com/Save_File_Notes_%28Papyrus%29#Changing_2 for more information)

...The problem we're having here is that this stuff doesn't clean itself up. It sticks, and sticks forever. I've got saves loading up that are STILL whining about mods I long ago dropped, or have long ago changed to something new. If this is supposed to sort itself, one would expect that to update, but it apparently doesn't.

Agreed with Arthmoor. Variables in saved games are not the only problem. I am more fearful of iterative Events (e.g. RegisterForUpdate (), RegisterForSleep (), etc.) that continuously run on Scripts of ESPs that have been deactivated: http://www.creationkit.com/Talk:Save_File_Notes_%28Papyrus%29 (The ESP and Script deactivation tests - OnUpdate () Event, Variables and Properties () section). For us to completely stop those events, an uninstall procedure is required to Unregister them. This is to be expected, of course. But I think that it would have been much simpler if the game detected that the Script has been detached from the game (i.e. their ESP has been deactivated) and terminated any events to that Script.

And the only way I found to complete remove Variables from the saved game is to recompile an empty (i.e. it only contains the ScriptName line) Script for that object. What that means for us mod developers is to deliver two packages:

active mod that is used as normal,
clean-up to be activated after the mod is deactivated. Then deactivated again after that first clean save.

I'm definitely not going to do this. :S

In my current mods, I've simply given the user a console command to unregister any of the reiterative events and remove any active spells the mod adds.

» Wed Jun 20, 2012 4:14 pm

You should still extend vanilla scripts for the sake of not editing vanilla scripts, Papyrus will use the most derived version of overridden functions, if you have two mods that extend that script in the same quest it's going to be a load order thing. The plugin determines what script to load and what variables to give it, obviously if you have two mods that edit the same quest because it has a different script attached it's going to load the one loaded last.

Previously I just created a duplicate of the vanilla script and renamed it, but I decided it would be better to just extend the vanilla script as I was only editing small portions of the vanilla script so it would at least help in reducing file size if anything.

I think a better solution to the variable problem would be a dated flag we could tick in the plugin to tell the users game that it needs to reacquire the plugin variables. Or maybe just give us a volatile keyword to make the script always reacquire the plugin value.