Jump to content

[Skyrim] Information Baked Into Saves


Recommended Posts

So I figured it's about time to begin keeping track of what does and doesn't bake itself into your saved game. Enough things do so that it's getting hard to keep track of in my head, and what good does it to anyone else up there... where my fingers are too short to get it out....
 
So far, we have:

  • Papyrus script properties. These become permanently baked in from the moment the game starts and/or when a new mod with scripts is added. Script properties can only be updated by forcing them to change via an update script, like what the USKP uses for retroactive fixes.
  • Objects pointed to by Papyrus properties. These can never be moved, even with scripted commands. This data is baked in from the moment the game starts and/or a new mod is added. Most attempts will simply fail silently, while others will log an error saying the objects can't be moved.
  • Objects pointed to in forced reference aliases for quests. These are not supposed to become permanently persistent, but more often than not that's exactly what happens.
  • Changes to any vanilla objects made via scripts. Including global variables and any other information. These changes are written as modification records in the save and can only be reversed with another script.
  • Map Marker data. Specifically, if you alter a map marker, remove the name from it, then proceed to play, the map marker will permanently lose this information even after the mod is removed.
  • Positions of havok enabled items in cells you've visited. Even if you move them in the CK and you haven't disturbed them yourself. This may reset itself upon the cell's next cycle, but so far all indications are that it won't.
  • Positions of moveable static objects become permanent after your first encounter with them. Prior to this they will update.
  • Changing ownership on a bed from nobody to a faction does not appear to update, while changing it from nobody to a specific NPC appears to work fine.
  • Several fields on NPCs are known to bake in: Crime Faction, Faction memberships, Inventory items, Morality (AI Data tab), the opposite gender animations flag. These fields appear to only bake in if the NPC actually loads into memory at least once during play.
  • Facegen Data for NPCs. This seems somewhat hit or miss, but more often than not, if you have encountered an NPC while playing, any changes to their facegen data that may be made later will be ignored.
  • Timescale changes. You can make a one-time change to the game's timescale through an ESP, but after that, any changes to timescale must be done either via Papyrus or the console as the change is permanent in the save once made.

More data will be added as its discovered.

 

It is worth noting that SOME of this can be corrected through the use of Hadoram's Save Game Script Cleaner. For instance, Jac (from Wolflore) has a brief post on how to correct the baked in facegen data from an NPC.

Link to post
Share on other sites
  • Replies 87
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

So I figured it's about time to begin keeping track of what does and doesn't bake itself into your saved game. Enough things do so that it's getting hard to keep track of in my head, and what good doe

ENBoost doesn't leave any data in your save at all so it's perfectly safe to drop, just like an SKSE dll would be.

 

Positions of havok enabled items in cells you've visited. Even if you move them in the CK and you haven't disturbed them yourself. This may reset itself upon the cell's next cycle, but so far all indications are that it won't.

 

 

Does this means that respawned items can or cannot reset the cell?

Link to post
Share on other sites

Like I said, it may or may not reset. Havok items moving from their default positions gets remembered and I'm not sure if the game ever wipes that data properly. At no point has it ever fixed any of the havok stuff I've seen displaced.

Link to post
Share on other sites

Have just reinstalled Skyrim plus all mods I want to use, but right now I can't make up my mind about installing Frostfall or not.

 

So with that in mind I want to ask.  If I install Frostfall will any script that's added by Frostfall end up in my save even if I haven't enable it in MCM for my character? :unsure:

Link to post
Share on other sites

It's already too late I'm afraid, because the scripts is already baked into a save.

 

Unless the mod installation itself can create an installation save so to speak similar to what Windows do when you're installing a program by creating a restore system point.

Link to post
Share on other sites

I don't know where you're getting the message that we can clean saves. We can't. Those stop scripts cannot resolve the issue. They only serve to shut down the running update loops those mods have. They cannot reverse the actual changes made.

Link to post
Share on other sites

Actually from what I've gathered it's not so cut and dry with Morrowind either. From my own personal experience I managed to corrupt a save fairly easily by removing some town mods I decided I didn't like. Granted, the tools for MW make it possible to actually clean the save as though it were a plugin, but still.

 

Oblivion and both Fallouts were the only ones where you could live dangerously and not break anything - so long as the mods were not altering any of the persistent vanilla references.

 

Also, this thread was for Skyrim, and I guess I'll go mark the title to be more specific :P

Link to post
Share on other sites

Actually from what I've gathered it's not so cut and dry with Morrowind either. From my own personal experience I managed to corrupt a save fairly easily by removing some town mods I decided I didn't like. Granted, the tools for MW make it possible to actually clean the save as though it were a plugin, but still.

 

Oblivion and both Fallouts were the only ones where you could live dangerously and not break anything - so long as the mods were not altering any of the persistent vanilla references.

True.  I can't comment about how it was in Oblivion or in Fallout, but I trust you on that.

Link to post
Share on other sites
  • 4 weeks later...

In the first moment a new scripted mod runs, the engine starts to collect data to add to your save file. If it was the scripts only, this wouldn't matter too much, as it would only increase the size of your saves. The problematic data are not the scripts themselves, but the state each instance of a script is in when the game is saved (the so-called uncompleted tasks):

 

When a game is saved, all running scripts are instantly stopped, and to make sure that they are properly resumed when the save is reloaded, all the related information is written in the save file. If there are several instances of a script running when the game is saved, there will be separate blocks of information written in the save file for each single instance and it is obvious that this may bloat the saves considerably (imagine, for example, that a mod attaches a script to a common clothing item and lets it carry out a specific task while the item is worn: a separate instance of the same script will then run on each equipped copy of the item, and because those instances all run independently, they have to be treated like separate scripts, so to say, when the save game is written).

 

Upon reloading, the engine will reconfigure the scripts from the information it finds in the save file and then tries to complete all scripts tasks that have been interrupted when the game was saved. When the respective mod has been removed in the meantime, all those tasks will fail to execute. Unfortunately though, the tasks are not discarded when the they fail, but queued instead and called again in regular intervals until they can be completed - which is never the case when the mod has gone. Moreover, there is evidence that all uncompleted tasks are carried over in subsequent saves, and therefore, will remain in the save forever.

 

You probably think that this sucks, but you have to keep in mind that this procedure adds a lot to the general gaming experience: this is what makes the game actually saveable at all times. Moreover, though, every task will be resumed upon reload and this is almost (well, there are a few minor glitches; for example, when you collect ingredients, then die and reload, the plants will still appear as harvested) perfectly repeatable. In other words, there was a good reason to handle it that way. This doesn't mean that I like it; to be honest, it has driven me almost crazy more than once, but I do also see the advantages.

 

While you can't remove the scripts themselves from the saves, you can take appropriate measures to keep the number of script tasks written to your save as small as possible (ideally, you should be able to eliminate them entirely, but that's very difficult). There are mod authors who recommend to keep off of objects that are modified by their mods (others propose similar solutions), but this won't work most of the time. The only acceptable solution is to integrate a shut-down procedure into the mod itself, just as I did with the surveyors mod. When the process is started, the script will stop all running tasks (in some cases, it has to wait until they are completed, since interrupting them would cause a bunch of other problems), then clear the quest aliases, stop all quests, then print an info message on the screen and finally terminate the script which controlled this process (and was conceived specifically for that purpose). While I can't guarantee to remove all extra data, I can confirm that they do the least harm possible.

 

Though, whether or not such a procedure is successful also depends on the conception of your mod. For example, don't add any scripts to vanilla actors or objects, because there is no way to detach them again. Set up a quest instead and add your scripts to aliases. Make sure however, that you do not force a reference into an alias, as this will make it persistent even if your mod has gone. Let the story manager fill your aliases or handle the process by a quest script instead. Likewise, do not add vanilla actors as properties to your scripts, as this will make their editor locations persistent (while the editor locations of most actors are persistent anyway, some of them are not!). If you have to check something about an actor, add him to a specifically created formlist instead and add that to your script. All the tools, procedures and functionality to create the most amazing things without detrimental side effects are already there (Skyrim is very powerful in that respect), but applying them properly often requires a different way of thinking, compared to earlier games.

Link to post
Share on other sites

Adding them to formlists will still mark them as persistent - check it in TES5Edit some time. :P

 

As for "You probably think this sucks" - I KNOW it sucks.... there had to have been a better way to deal with this. At the very least, the system should be discarding all information about scripts which are no longer present. I think it's safe to say we all know this isn't happening.

 

There is one method for mitigating this - to a point. Blank a script you want the system to clear. As long as it isn't carrying out OnUpdate() events, the game will strip all the properties, variables, and other things from it. That will leave behind just an empty stub on your save. That will still never go away, but it DOES clean up most of the problem in the process. It's as close to a "save cleaner" as one can safely get.

Link to post
Share on other sites

what about SKSE ClearInvalidregistrations

 

that stops and clears all unregistered onupdatecommands as they try to run

 

This has successfully reduced savegame bloat by a signifigant amount according to multiple users

Link to post
Share on other sites

That ONLY works for invalid update registrations. It would have no effect on anything else, and it CANNOT clear that sort of thing from broken vanilla scripts since vanilla scripts can never become invalid.

 

If, however, your save game bloat is brought about by a bad mod that had OnUpdate events, then yes, the SKSE flag would fix that AFTER you have uninstalled the mod.

 

That still doesn't mean uninstalling mods is a good idea. You can still break plenty of stuff by being careless about it.

Link to post
Share on other sites

Yes good modders do allow a stop scripts command at the uninstall process but again id have to agree with Arathmoor that even WITH that and the clearinvalidregistrations, there is still room to corrupt your save

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...