Ok first of all the only thing we have to go on is how scripting worked in past games. Secondly I don't think you're being very nice and I'm trying to be helpful. I think I've said all I have to say on this subject now.

And there is the issue: you rely on something you know.

But as a "new" feature, we don't really know what they do, but we can hope or assume.

And due this the question is "how will they achieve their goal?".

And now the roadmap spreads.

They have PLENTY of ways how they could make it work.

But I think they want to keep their savegames as small and as clean as possible, therefore a limitation of information could solve this problem.

My "rip it to it's core" is just a solution for this.

In the end it has nothing to do with "scripting" or how it was done in the past games.

Let's hope the new system is more friendly towards saves, like they say.

Just a random example if you're curious:

scriptname defaultSetStageActSCRIPT extends objectReference{ this is a generic script for one-shot quest stage updates}import gameimport debugquest property myQuest auto    { quest to call SetStage on}int property stage auto{ stage to set}int property prereqStageOPT = -1 auto{ OPTIONAL: stage that must be set for this trigger to fire }float property delay = 0.0 auto{ OPTIONAL: Amount of time to wait until setting the stage.  Defaults to 0 }bool property requirePlayerActivation = True auto{ Whether or not the player needs to be the one to activate this: Defaults to True}auto STATE waitingForPlayer    EVENT onActivate(objectReference triggerRef)        if (triggerRef == getPlayer() as actor || !requirePlayerActivation)            if prereqStageOPT == -1 || MyQuest.getStageDone(prereqStageOPT) == 1                utility.Wait(delay)                myQuest.setStage(stage)                gotoState("hasBeenTriggered")            endif        endif    endEVENTendSTATESTATE hasBeenTriggered    ; this is an empty state.endSTATE

This is a script from vanilla skyrim that you would attach to an object. When you activate that object, it can set the stage of a quest. Then, it will change the script state so that any further activate of that object will not do anything. Optionally, the script will check if a certain quest stage is complete and there is an optional delay before the quest stage changes. All those "property" lines are variables, which point to a quest, quest stage to advance to, quest stage to check for, quest stage advancement time delay, and a boolean (true/false) to check if the object should only be activated by the player. So what happens if we don't save these variables? Well in this case, if we load the variables defined upon script start-up, probably nothing bad. But many times these things change and we need to keep track of what they are such as variables pointing to different NPCs, true/false statements, numbers, etc.

Likewise, you need to keep track of your script progress (i.e. a function running in the middle of the save). Say for example you activate that object and the script triggers. You're in the middle of that time delay before the quest stage advances and you save the game. If you reload the game and don't continue the function, the quest stage won't advance and you'll have to reactivate the object.

Now with that explanation out of the way, I don't know the actual quantity or percentage of script data that goes into Skyrim's saved games. That was just one small example. Saving games isn't that simple as you want reloads to be as seamless as possible. Say you save the game fighting some super mutant and you run around the corner briefly to lose sight. When you reload, that super mutant should still be trying to chase you around the corner. Animations and effects that are in progress shouldn't be interrupted. Conversations shouldn't be randomly cut out. The duration of your Med-X drug effect shouldn't be reset or disappear. Sometimes NPCs are created randomly based on a template and that data has to be saved. Etc... Could Bethesda improve on their saved games? Probably. I do not think that they can support ripping mods out of a save though without any risk.

Yes they can if they want to. Oblivion proved this.

I was the first modder (on these forums anyway) to say that Oblivion save game files were saving "active" scripts in the save game. Many mod creators at the time thought I was crazy but a year latter I was proven right. So my point is yes the save game could save the active script, then after the script "completes" one cycle it is dumped and no longer effects the game and is no longer kept in the game.

That is how it worked in oblivion and that is why in oblivion you could rip out mods as you please anytime you wanted and not hurt your game.

This is what I would expect.

Beth is still working on Papyrus (well that is the impression I get from SmkViper's (Beth's senior programmer that made Papyrus ) posts concerning the optimising of the language). It is technically possible that they might also make it easier for modders to remove from the game as I described. In Fact this has been done in skyrim with the "good" script cleaners. At least well enough to show it is possible anyway.

In Oblivion (and Fallout 3) all active scripts ran every frame, and they ran to a safe pause-state every frame. The upside was that every frame all active scripts were in a safe state and could be saved cleanly. The downside (as you're aware) is that many scripts running very quickly had an impact on framerate.

In Papyrus, as you're probably also aware, the scripting system has changed drastically, with scripts running in parallel, being scheduled to run on an event basis, being suspended in whatever state they happen to be when allocated script CPU time has been exceeded, and only synchronising with frames in particular native function calls. The upside is that framerate is usually only affected by massive failure states (such as massive stack dumping) or the most extraordinary modded script behaviour. The downside is that scripts don't run with predictable and reliable timings, and are never guaranteed to be in a safe/stable state to remove from a savegame.

As I say, I know you're well aware of all this, but pointing it out is relevant to my next point, which is as follows...

Bethesda changed the way scripting works for a reason! They didn't just say "I know, lets implement a much more complicated script engine, with scheduling and parallelism, in order to mess with mod users and creators. It'll be a laugh." They did it so that framerates stayed stable and predictable on consoles and low-end PCs.

Is there any realistic likelihood that they'll abandon that work, and the benefit gained, in order to make it possible to remove mods and continue playing on the same save? I really don't think so. Yes, they could if they wanted to, as you say. But the implication that they should want to is, I think, based on the priorities of mod makers and users, not on Bethesda's priorities.

Remember, the vast majority of Skyrim's 20 million (+?) purchasers would never download a mod - the top endorsed mod on Skyrim Nexus (Sky UI) has 1.5 million unique downloads of the latest file, far fewer for the various older downloads (and most of those will be the same users who downloaded the latest). Mods definitely increase lifespan and boost sales, but they're still not nearly as important as we sometimes like to think.

However the DEV statements did in fact imply they were doing "something" to make removing mods ..er... better. We will see if this turns out to be 'significantly much better' or 'so little it may as well be nothing' by October.

A trite little counterpoint popped into my head (and I can't shake the feeling I must have heard it, or something like it, somewhere...)

"Hope for all. Strive for much. Demand little. Expect nothing."

I certainly hope they've done a lot to make savegames more resilient to mod removal. There's good reason for them to do so, and some evidence that they certainly wanted to. But I've done enough software development to know things don't always go according to plan, so I'm not exactly going to fret in anticipation - or gnash my teeth in frustration if it turns out to be no better.

I... might sigh in weary cynicism, though