The most infuriating aspect of Skyrim is the way that it saves data into a save game file. It does so in such a way that said data is always accessible but is not alterable once it has been initialized. The term “Baked into your save” comes up often when issues arise after a player has updated their copy of a mod to a newer version. This little guide will give you a few useful hints to keep in mind when writing and updating scripts and other elements in general so that you can maintain a mod that can be upgraded mid play-through as much as possible and not have to require your players to start a fresh game in order to get recent changes to take effect.
Rule #1: You can always add new properties to a script but you cannot change or remove them.
Properties are one of those annoying elements that are saved to your save game, and once they are, there is no changing them, your save game will henceforth forever refer to said property as the saved target element, even if you change it and update your mod. So ONLY update your mod once you are certain that the properties you are creating in a script are the correct ones.
Furthermore, if you delete a property that has been previously established, the game will start to generate errors in the form of Stack Errors. These stack errors will cause a problem in the long run because when they happen, the game basically keeps the failed function in memory until it can clear it up (which is usually never in the case of a reassigned or deleted property), and if enough of these stacks pile up, it causes a memory dump or stack overflow error. You may notice this in the form of random dips in FPS or lag that has no logical cause. This is because the system is halting momentarily while it purges the memory cache holding these bad stack errors and then will recover. The risk here is that often times, it can’t recover quickly enough and the game crashes to desktop. So cleaning up stack errors from your mod is critical.
Rule #2: Use less properties when possible for simple scripts that may be updated in the future.
Properties are faster to access than functions which acquire the same object, but sometimes it’s smarter to acquire the object especially if you might update a script later down the road.
EX: Character.RemoveItem(IronWarAxe, 1) will remove one iron war axe from the character, but Character must be established as a property, which means you can never redefine Character to be something else once it’s been filled and loaded to a new game. Instead use: Game.GetPlayer().RemoveItem(IronWarAxer, 1) if removing from the player for instance. This way the Game script will use it’s function to get the player for the remove item function and if you decide later that instead it should be attached to another character, you can easily make it into a property to point to the other character.
Another handy alternative to a property is to use GetLinkedRef() and link the scripted object to the intended other object so as to avoid having to fill the property reference. This way you can easily reassign what that script is connecting to.
Rule #3: Persistent VS Temporary
The other aspect of modding which must be kept in mind when editing your already released mod for an update is Persistent VS Temporary references. Each object you place in a cell will be one of these two type. Standard static objects, scenery, etc will all be temporary references and generally these items can be moved around as you see fit to fix problems or expand your mod. Persistent references however are any object which gets enabled or disabled, is scripted, or is utilized or referenced by another script or quest in any way. These persistent objects are locked into your save game when they are first loaded up (when your game initializes with the mod loaded). If persistent objects are moved, they will not translate as such to existing games, only new ones. The alternative here is to delete the object and re-place it. This is not always easy especially if the object is utilized by other scripts or is part of a quest, so plan out accordingly.
My major solution to the upgrade persistence issues is to do as many of the big alterations as possible as an entirely new version of the mod labeled as a redevelopment beta, and telling your users that upgrading is not recommended as things are being overhauled. Then once you are done with it all, release the new final version and state that it requires a fresh game to begin anew. From that point on, be aware of “upgrade friendly” changes, using the rules above.
Rule #4: Do not delete scripted objects
Once a scripted object is loaded into a game, it’s properties are saved to the save game and the functions will always attempt to load and process. If you no longer need a scripted object or it’s function and that script is not used by anything else in your mod (assuming it is YOUR script and not a shared script), you should disable the object if it is no longer needed, move it out into the void somewhere and alter the script adding semi-colin comment marks in front of each line of code. This will preserve the properties of the script in your save game but will halt the functions of the unused script.
The only exception to this rule is if you use the Save Game Script Cleaning utility (see below).
Loop hole to alterations of “baked in” scripts:
There is a utility available on the Nexus called Save Game Script Cleaner which can be used to essentially “reboot” a script so that it must re-fill the properties based on the current plugin settings. So for example if you have a script with a property pointing to an Iron Sword and you later change it to point to an Elven Sword instead, the property would be baked in to the save game normally. Using the Save Game Script Cleaner you can delete “instances” of that script from the save file. This basically removes that script from the save game. The next time the save game is loaded, Skyrim will automatically see that the scripted object needs to have it’s properties filled and will look at what property it should be filled with, which would be the new Elven Sword since the plugin now says different from what it used to.
There are still small chances that this will either not work or will potentially break a save game, but using it for this specific purpose is generally safe.
Additionally you can break Rule #4 and delete a scripted item if you use the Save Game Script Cleaner utility to “remove scripts from non-existent deleted forms” which will clear scripts that were attached to objects which have since been deleted from the mod.