Corrupt savegames after mod changes

[jaime74]

Dear all,

 

to set it straight:

What can be possible reasons for savegames going havoc after a mod (which this saved game is based on) has been modified or updated?

 

I guess that this a well known and old question among modders, though I haven't found much information about it in the forums, apart from the general "create-a-clean-save" approach (see this post, for example).

 

Why is this so critical?

Just an example: I have created a quest mod, and after changing several things inside it, my savegames based on older versions of the mod may (or may not) produce weird effects. It's often unpredictable, or at least very hard to track down what causes the corruption in every specific case.

As long as I am still only developing my mod, I can easily ignore this, because I can create new savegames for testing, of course.

But as my mod is a quest mod that I want to publish, I want to ensure that any update that I will have to provide later (e.g. for important bugfixes) won't break other users' savegames, because this would force them to restart the whole quest over and over!

 

I'd like to learn more about the chances that I have to develop my mod in a way that helps avoid this issue, or at least minimize the risk.

I guess that this requires nothing less than understanding what the game engine does with savegames and mods (which may seem nearly impossible!), but I'd like to gather together whatever is known.

 

Possible reasons that I know of (or at least suppose to be a reason) are:

 

1.) Mixing up old and new script variables, which may result in the game engine mixing up their persisted values (as detected by Wrye long time ago and described here)

2.) Changing the name of the esp file, the name of the quest or the name of the script, which may all result in the game not being able to assign the persisted values properly on game load

3.) Changing the load order position of the esp(?)

4.) Using a Bashed Patch created with Wrye Bash that might interfere with my esp if it hasn't been rebuilt properly the mod update

5.) ...?

 

These are the things that I tried to regard so far, but, unfortunately, with only partial success, so apparently there must be other possible causes.

Can anybody append more things to this list?

 

In general, I am not sure whether such errors are always caused by custom scripting only. For instance, if my savegame is suddenly missing an item that this quest added, but the item is not referenced/used in any of my scripts, how could a recent script change then be the reason for that?

 

I am hungry for more ideas, so thanks alot to anybody who wants to take part in this discussion!!

[Ranokoa]

I really wish I had enough energy left to read your entire post. I want to help but I only got a couple lines in. Hopefully I can still be helpful. I am just very very very tired.

 

As for why you create savegames.

Basically you character is in Cell A and is saved there.

You open the mod in the CS and change the mod. When you "save" you replace the entire mod as it was with an entirely new mod as it now is.

 

The save game remembers the mod. It remembers everything that is inside the mod and exactly where it all should be. When all of the sudden that mod is replaced by the new saved version of the mod it takes away that enabled version of the mod and adds the new version to be enabled.

 

The save game thinks that the mod is no longer there. And now it decides to either ef up or crash or just get rid of everything that was in that mod because the mod no longer technically exists, because there is a new mod in its place that is not exactly the same.

 

A "clean save" simply refers to a game being saved without that mod being enabled. Best to make it separate rather than quicksave or something. The reason people do this is because there is always potential for danger, crashing, getting stuck and destroying your save.

 

Imagin that two people make a different mod that use the very same place as the other, but neither know the other is using that same place, and both are making the mod at the very same time. You see both mods, and they are not exactly specific about where and what every little detail is affected. You download both because they both sound good, and, while you're at it, download a dozen other mods or half a dozen that are just good mods that do not use the same space.

 

You enable the em all and start playing, of course, you can't try every feature of every mod at the same time. You play the game and after a while eventually get to the part where mod A clashes with mod B, they can either extremely and obviously clash, like having a mantion smack dab in the middle of a castle wall with flying cows running through the trees, literally, and squirrel ninjas just because squirrel ninjas sound awesome. Really awesome. Now imagine those squirrel ninjas are Foamy the Squirrel, and back to something relevant. You can't quite SEE that it is mod B that is clashing with mod A, you know you are looking where mod A should have been, but some part of mod B is right there. And because you have already gotten so far with mod A and mod B your unmodded version of the game, on this save game, things that are vanilla, are all effed up. People are dead who shouldn't be because mod A changes something that mod B also changes and that made it dangerous for the vanilla NPC to wander, things are corrupt, who cares.

 

The reason people say make clean saves is in case when you start to play the mod you realize there is an incompatibility but you aren't always sure what it is and or it has already affected you. Every mod has the potential of being incompatible with another mod you have, simply because no one knows what every single mod does no matter how remote you think the areas are that are affected.

 

Anyways, you get the point.

 

Oh god, I had a lot more points to make as I read a little more but I'm running on 1% energy in my headzies.

 

I'll just shorten it all up. Basically, instead of everything else I was originally going to say, if you have any questions, need help with learning how to remove incompatibilities or crashes or whatever, ensuring your quest does not ruin something and or a variable that you change is not destroying anything else, or have any problems with existing mods or just need to learn about things that most already know but you do not because you are new or whatever, just PM me with the details and when I wake up, get back from work, and get on the internet, I will help you with whatever it is that you need even if it means making a giant tutorial. Now, to fall asleep to Burn Notice,

 

Be well, sleep well, fight well, live long.

~Ranokoa

 

Really sorry that I couldn't read more but I'm getting a migraine and really needed to shut my eyes... which I did for the duration of this entire post up till be well sleep well. Please excuse any typos. (fast typer)

[jaime74]

Dear ranokoa,

 

what a reply! :thumbsup:

That's faaar more than I had expected! :yes:

I will now read through it thoroughly after having caught my train and then come back with any (hopefully) helpful new ideas and questions! But I can see from a quick walkthrough that you have already given me a lot of good answers!

 

Sleep well, get well and take care of your head!

[jaime74]

Well, here I'm back again!

I hope you could get a good amount of sleep after spending your very last breath in answering my questions yesterday! :)

 

First of all: In the meantime I was able to restore my mod by falling back to a backup copy. My savegames work again. That isn't an elegant way, of course, and it doesn't solve the matter at all. But the main thing is that I can lean back and take a deep breath.

 

Now for your explanations:

Imagin that two people make a different mod that use the very same place as the other, but neither know the other is using that same place, and both are making the mod at the very same time.

Well, I think this is one of the most basic reasons for mod conflicts, of course.

But it bears very interesting point that I did never think of!

If my understanding is correct, the game engine's behaviour to "drop" and reinitialize a mod whenever it has been changed is not simply a bug or a weakness, but actually intention, in order to avoid conflicts like the one you are describing! From this new point of view, it seems quite logical to me!

 

But then I am wondering how the engine detects mod updates? Is it just the name and timestamp of the file? I guess not! I suppose it's rather some hidden information (like timestamps or incremental IDs in the file header or whatever... I can only guess). But it might help alot to know more about that.

 

Apart from that, if this behaviour is systematic, why does the game handle such situations in such a sporadic, unpredictable way (sometimes mod changes will kill the savegame, sometimes they won't)?

 

I still dare to hope that it could be possible to distinguish "hard changes", that definitely will break a savegame, from "soft changes", that we can consider as "savegame-compatible". But maybe this is too optimistic?

 

I'll start a try to update my "possible reasons" list from above, based on what I have learned (maybe it's still partially rubbish, but why not give it a chance?)...

 

What could be "hard changes" to a mod that "kill" savegames?

- Mixing up of old and new script variables, i.e. mixing the position in the scripts where they are declared

- Changing the name of the esp file

- Changing the name of quests

- Changing the name of the scripts

- Redefining/modifying quest stages

- Changing the load order position of the esp(?) --> I think we can consider this as a "safe change", don't we?

- Using a Bashed Patch created with Wrye Bash that might interfere with my esp if it hasn't been rebuilt properly the mod update --> I am not sure about that. I guess I should be more specific here!

- Adding new masters to the esp (yes, I ran into that yesterday!)

- Deleting persistent references

- Deleting cells

- anything else?