Jump to content

Best practices / pearls of good scripting


Antono

Recommended Posts

Any tips on what constitutes good scripting vs bad scripting?

 

I have this grand plan for a mod with lots of scripting, which could even find its way to be uploaded here if it turns out to be good enough. However, before it ruins every single one of your Skyrim saves, I was wondering if this community could offer some advice.

 

For example, I understand I shouldn't point my variables to a specific object reference, as that reference will remain persistent; otherwise, I should clear them by assigning "none". Also, I should probably declare all my variables inside the functions that need them, as this will ensure they are properly cleared once the function ends. Also, I should avoid RegisterForUpdate and use RegisterForSingleUpdate instead.

 

But I'm afraid there's more to it, right? What's wrong with those mods which make a savegame "bloated" or corrupt it? Why is it that some mods require a clean save to remove or update them while others do not? How can I make sure that my mod will not cause trouble? And what is this option that some mods have to "stop" them before removing them? Does it stop all their scripts? Does it assign null values to every property/variable?

 

So, I welcome any insight and advice you could offer. Please point me to any guides about this if they exist or post your advice on how to script a good, safe, nice code.

 

 

If you can do something with the help of an alias you should! ^^

 

If you want to keep track of some numerical value related to an NPC (for example the number of times player failed a persuasion attempt against that person) using factions and faction ranks is safer than than modifying "unused" actor values.

 

RegisterForUpdate is the common cause for savegame bloating http://www.creationk...OnUpdate_-_Form

 

Stopping a quest. It does some useful stuff, like unregister events (only in the scripts attached to the quest), release quests aliases, not sure if it assigns none to the quest script variables . It doesn't automagically revert all the changes you may have done in your mod, that's up to you.

 

For stopping a quest: StopQuest

 

All changes/additions that you made during runtime should be rolled back if possible.

Quests should be stopped and magic effects removed. Same for spells, items and such. Ai packages that you added via script should be removed too and the packages should be evaluated after this (if you use StorageUtil, this seems to do all the EvP stuff for you).

 

Changing or removing properties on a running quest is a sure way to error log spam and save game corruption. So - try keeping changed to properties to a minimum and use functions instead of properties if possible.

 

Link to comment

I think the best way to avoid permanent damage to savegames is using aliases instead of directly modifying actors. aliases let you add spells, items, ai packages, change their names and stuffs like that. And if you're going to put persistent scripts on actors please *don't* use magic effects because their scripts stop working when player leaves the current cell! attaching the script to an alias instead and then putting the npc into that alias is both more reliable and safer.

 

I think if you can do something with the help of an alias you should! ^^

 

Ohhh and if you want to keep track of some numerical value related to an NPC (forexamplish the number of times player failed a persuasion attempt against that person) using factions and faction ranks is safer than than modifying "unused" actor values.

Link to comment

I had these same questions some time ago. I'm not an expert in Papyrus though, still learning

 

Local variables don't get baked into savegame. Nearly all other stuff do

http://www.creationkit.com/Persistence_(Papyrus)

http://www.creationkit.com/Save_File_Notes_(Papyrus)

 

As far as I know RegisterForUpdate is the common cause for savegame bloating http://www.creationkit.com/OnUpdate_-_Form

 

There are situations where a clean save its mandatory (for example to restart a quest with the "run once" flag enabled)

I think sometimes it's just a convenience for the mod authors when they have done major changes.

 

Stopping a quest. It does some useful stuff, like unregister events (only in the scripts attached to the quest), release quests aliases, not sure if it assigns none to the quest script variables . It doesn't automagically revert all the changes you may have done in your mod, that's up to you.

 

"How can I make sure that my mod will not cause trouble?"

Do a lot of testing.

Link to comment

This is really interesting b3lisario. I was wandering how my quests were going to complete since they are only carriers for aliases and scripts...

 

So, the "stop mod" that appears in some MCM menus calls a function to stop the mod's quests? (Damn, I really should read one of those buttons' scripts but I haven't studied the MCM menu documentation yet.)

 

Then,by offering a way to stop my quests and by avoiding "run once" quests, I can minimize the need for a clean save. Can you imagine any other reasons for a clean save? Also, could a player restart a "run once" quest using the StopQuest / StartQuest console commands?

Link to comment

A "Stop Mod"/"Uninstall" function has to be written by the mod author, as MCM has no way to know what to do, to uninstall and unregister a mod.

And if you follow what Ms Leeches and b3lisario wrote, you can keep the left overs in a savegame down to a minimum.

Completly avoiding this is not always possible and depends on what your mod does.

Link to comment

A "Stop Mod"/"Uninstall" function has to be written by the mod author, as MCM has no way to know what to do, to uninstall and unregister a mod.

Of course! :D

 

If I may ask, could you elaborate on what such a function would have to do? Would it be sufficient to stop the mod's quests? Should it also set all the mod's variables/properties to "none", end all functions and put every script to an inactive state? Should it also remove any custom factions, delete any relevant objects in the world and generally undo EVERYTHING a mod has changed?

 

...am I being too obsessive-compulsive here? :s

Link to comment

i would if i knew what i would talk about, but i never wrote such a function so my knowledge is rudimentary.

But as for stopping a quest: StopQuest

The Creation Kit wiki and the sources of other mods are your best friend.

 

Afterall, all changes/additions that you made during runtime should be rolled back if possible.

Quests should be stopped and magic effects removed. Same for spells, items and such. Ai packages that you added via script should be removed too and the packages should be evaluated after this (if you use StorageUtil, this seems to do all the EvP stuff for you).

Link to comment

One thing I learned the hard way is to pay attention to script properties.

 

Sometimes they are not assigned properly (or you forget to assign them the right value) and it can take hours of pulling your hair on something that is not working before you find that out.

 

Also, changing or removing properties on a running quest is a sure way to error log spam and save game corruption.

 

So - try keeping changed to properties to a minimum and use functions instead of properties if possible.

Link to comment

Thank you CGi, dully noted all these things.

 

 

Also, changing or removing properties on a running quest is a sure way to error log spam and save game corruption.

 

So - try keeping changed to properties to a minimum and use functions instead of properties if possible.

 

I see. Then that would mean that if I absolutely have to change a property, the next version of the mod would require a "stop/start" function or a clean save, right?

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use