LE WHY are clean saves necessary?

[fore]

It seems to be an accepted fact, that we need to make a "clean save" when we install a new version of a (scripted) mod.

 

But why is this necessary? And: would it be possible with some counter-measures, to at least avoid some of the cases?

 

Simply saying "it's because of new IDs for the same quest" doesn't satisfy me, and does not explain what happens.

 

For example, users of my mod (FNIS) have reported a behavior, which could have 2 different reasons:

1. the save file contains the old script (which I don't think can be true), or
   
2. the (main) script quest does not receive the OnInit event, and keeps using the old quest data
   

Does anyone else have similar observations?

[eltucu]

[*]the save file contains the old script (which I don't think can be true),

It is.

[EnaiSiaion]

*If the script was running at the time.

 

If you do an on-load script that doesn't have a finish condition, then it's going to stay there. Forever.

 

To work around this, the only thing you can do is make sure all your scripts that don't have a guaranteed maximum duration have a kill switch. My preferred solution is an OnUpdate() which runs once every in-game hour and checks for a certain global variable, if this variable is 0 then the script quits.

 

You can get fancy and make it automatically start its replacement, though you will need to put its replacement into a formlist at a known row and refer to that row because you can't change parameters on a running script either.

[fore]

[*]the save file contains the old script (which I don't think can be true),

It is.

 

Is this a theory, or do you have any prove?

I made a few checks if any piece of my code is in the save file. But, as expected, there is no indication. And I doubt that the binary script code would be encryted in the save file

 

*If the script was running at the time.

 

If you do an on-load script that doesn't have a finish condition, then it's going to stay there. Forever.

 

To work around this, the only thing you can do is make sure all your scripts that don't have a guaranteed maximum duration have a kill switch. My preferred solution is an OnUpdate() which runs once every in-game hour and checks for a certain global variable, if this variable is 0 then the script quits.

My scripts don't have a "duration" of 0.2 sec for a wait(), which I use so an animation doesn't start immediately after a spell. Others than that, it's all events. And if you don't have any excessive stuff in loops, your script terminates immediately. This is not Oblivion scripting anymore. Things are based on events, and there is no need to store running scripts (which would be a very bad design decision anyway).

 

I also don't see an "on-load script" staying forever. Onload is an event, which you can use to call a function. And as soon as you leave that function, your script is done.

[LittleBaron]

@ Fore: All of your counter arguments assume that everything functions as intended, or in ways that are efficient or make sense. SKYRIM is in reality a buggy mess.

 

When people are telling you 'it's because of new ID's for the same quest' they mean that an old quest i.d. and all of it's attached scripts *will* continue to exist in a save that was made, as EnaiSiaion said, if that script was currently running. [she?] doesn't mean an On-Load script event, she means a script that fires at game start (that resides inside a quest) and then has no end point. A continuous loop of OnUpdate, for instance that would never stop on it's own. She's also not talking about the same duration you are, again she is referring to a loop of some kind.

 

I have found it is helpful to never change the name of an .esp, a quest ID or a script name. Changing any of those things seems to really screw things up.

 

If you feel like your mod is exempt from needing clean saves, don't recommend that players do it. Considering your initial post contains a reference to bug reports that have been made about it, I'm guessing users of your mod DO need to make a clean save.

 

@EnaiSiaion : [bRILLIANT idea about the global... if the global doesn't exist anymore, shut down... totally going to implement that in future updates!]

[fore]

Sorry, LittleBaron, but I think you don't understand event-based programming.

 

There is no script that "has no end point". And there is no "continuous loop of OnUpdate, for instance that would never stop on it's own". Of course it stops, as soon a the current event function finishes. And then the script waits for the next event it has a function for. Some of them the script need to register (OnUpdate), most of them it gets for free (like OnInit). But in between the script does not run, independent if the script was active before, or not.

 

And "when people are telling me 'it's because of new ID's for the same quest'" then I'm experineced enough to understand what that means. Experience enough not to believe them, if they claim things without prove. And to ask further questions about possible conditions, which might help us write scripts that are less likely to need clean saves.

 

And yes, "I assume that most things functions as intended, or in ways that are efficient or make sense." It might be cool to simply state "SKYRIM is in reality a buggy mess", but I have great respect for Beth's developers and what they did. They are professionals. Sure, not everything works perfect, but it's a game, developed on restricted budget, not a DoD application.

[eltucu]

There is no script that "has no end point". And there is no "continuous loop of OnUpdate, for instance that would never stop on it's own". Of course it stops, as soon a the current event function finishes. And then the script waits for the next event it has a function for.

And where do you think the script is saved in that state while its waiting for the next event to fire up? Edited July 3, 2012 by eltucu

[LittleBaron]

@ Fore: You seem like a smart guy. Animations take a lot of work and expertise to master. I hope you're right and you find out what we've all been doing wrong since November of 2011. Once you start putting out some mods [for SKYRIM] with scripting in them and experience some of the frustration and all the same inexplicable complaints from users that we have, I'm sure you will be able to find a sure-fire way to avoid it without the need for a pesky clean save.

 

Many issues that players seem to experience are alleviated by ensuring a clean save has been made. For the time being, that is proof enough for me to encourage players to install my mods after doing a clean save before sending me a bug report.

 

In any case, I can't wait to find out what you come up with!

 

:thumbsup:

[J3X]

According to my experiences do not quest script's properties change if one does not do a clean save.

[fore]

According to my experiences do not quest script's properties change if one does not do a clean save.

I didn't change them. I added a few close to the bottom of my existing property variables, and the ones coming behind the new ones didn't seem to have any bad effect. I have also not changed anythng which might have changed the quest's id.

 

Right now I have another suspicion, which would be pretty bad.

 

I have a quest script, and 2 magic effect scripts which get data from several quest variables (<quest>.<variable>). To do this, each magic effect script has to define the main quest as an auto property variable. The quest variables are set with OnInit every time the mod starts.

 

What users have reported for the new version is, that they get the new spells, but the reaction is like the magic effect scripts only has the data from the old version, i.e. the data which was saved in the old save file, but not the data that was initialized in the OnInit function.

 

My suspicion is, that the incompatibility is not caused by a new version alone, but by an additional change of the load order.

 

Every ID consists of load order and mod specific ID. So could it be possible, that after the start of the new mod with the new load order there are 2 quest variable sets, one with the old load order + old data from the save file, one with the new load order + new data from the onInit initialization? And because the magic effect scripts have the quest's old load orderd ID (from the save file), they will also access the old quest data from the save file available.

 

Plausible? If this is true, this would almost prohibit the use of quest variables.