Old versions of mods conflicting with newer ones... : V - Skyrim

» Tue Jun 19, 2012 12:00 am

And how did you want to do the disabling/enabling itself? It can't be in the script itself, because once it's disabled itself it can't enable itself again because it's disabled.

Scripts still run on disabled objects.

Also, a disabled object enables itself when the respawn happens.

I don't think so. Additionally, a disabled object isn't reset at a cell reset (at least with respect to script and script data), and can thus be used to store variables you want to persist between resets.

There is little magic here, you need to know the kind of mayhem your mod can cause and create a proper uninstaller esp.

This I think is going to be a common solution. However, as Cipscis noted, this should really only be necessary for modified vanilla references (or mods changing records from another mod's master).

The real hard time will come to uninstall mods with scripts affecting the player character as it can't be deactivated and Obviously can't be in a different cell than itself during respawn.

Though I haven't looked into it deeply, I'm under the impression that if you attach scripts to the player via extension quests, when the quest is removed so is the script.

-Makes scripts attached to the player or to other objects non fixable dependant on properties to work

That's not a bad idea. It'd be very simple to put a check in a script to check the presence of a global var that an .esp adds. If the var is missing, don't run.

When you deactivate a data file, you are not destroying the script. The script was not defined inside the data file - all that was defined in there (with respect to the script) was which objects should have it attached to them. Once the game has attached a script to an instance of an object, it appears as though it won't detach it once the plugin file in which the attachment was defined is deactivated - this is the whole entire problem here.

Exactly! And thanks for the clear description Cipscis.

As far as I've been able to tell, there is no reason whatsoever why disabling an object should detach a script from it.

As above, that's correct, disabled objects still run scripts.

» Mon Jun 18, 2012 7:54 pm

I was wrong about disabling objects as a solution. My previous tests has been made with an script attached by a spell. Testing with scripts attached directly by the esp the scripts aren't removede by disabling the object.

Anyway, here is another workaround. If you don't need a script to be permanently attached to an object, better assign the script by a spell, instead of directly by the esp.

» Mon Jun 18, 2012 2:23 pm

So, have we made any progress on this? Is there any way to cleanly detach an old script from an object so it's no longer in the save? I'm running into some horrible problems with this.

» Mon Jun 18, 2012 10:27 pm

No, but so longer as you're not attaching vanilla scripts to vanilla objects it should be possible to either remove the object (by disabling the plugin file) or remove the script (by removing the *.pex file, or replacing it with a non-functional one)

Cipscis

» Mon Jun 18, 2012 8:25 pm

Unfortunately simply deactiving the ESP and deleteing the Script file is not sufficient to remove them from the game.
Once the Script is in your saved game, its Objects, Events, and Properties will exists forever.
Here's my log after 3 clean-saves (i.e. game saves without the ESP active and the Script files removed:

Spoiler

[02/27/2012 - 11:49:25PM] Cannot open store for class "kuEASAutoEatQS", missing file?[02/27/2012 - 11:49:25PM] warning: Unable to get type kuEASAutoEatQS referenced by the save game. Objects of this type will not be loaded.[02/27/2012 - 11:49:25PM] Cannot open store for class "kuEASQSEat", missing file?[02/27/2012 - 11:49:25PM] warning: Unable to get type kuEASQSEat referenced by the save game. Objects of this type will not be loaded.[02/27/2012 - 11:49:25PM] Cannot open store for class "kuEASForkS", missing file?[02/27/2012 - 11:49:25PM] warning: Unable to get type kuEASForkS referenced by the save game. Objects of this type will not be loaded.[02/27/2012 - 11:49:25PM] Cannot open store for class "kuEASPlayerS", missing file?[02/27/2012 - 11:49:25PM] warning: Unable to get type kuEASPlayerS referenced by the save game. Objects of this type will not be loaded.[02/27/2012 - 11:49:25PM] Cannot open store for class "kuEASQSSleep", missing file?[02/27/2012 - 11:49:25PM] warning: Unable to get type kuEASQSSleep referenced by the save game. Objects of this type will not be loaded.[02/27/2012 - 11:49:25PM] warning: Could not find type kuEASAutoEatQS in the type table in save[02/27/2012 - 11:49:25PM] warning: Could not find type kuEASQSSleep in the type table in save[02/27/2012 - 11:49:25PM] warning: Could not find type kuEASQSEat in the type table in save[02/27/2012 - 11:49:25PM] warning: Could not find type kuEASForkS in the type table in save[02/27/2012 - 11:49:25PM] warning: Could not find type kuEASPlayerS in the type table in save

As Script/gameplay mod developers, we need to be mindful of this bug/feature.
(Is it fixable by Bethesda? I don't know. This feature feels too intrinsic to have an easy fix. Hopefully, there is an easy fix and we'll get it by the next update.
For now, lets just say that there is no easy fix and it may take them several updates to fix.)

We'll need to make sure that updates to our mods don't break the users games.

Here are my thoughts:

Between updates, it may be safer to:

Disabling unwanted Scripts by compiling blank/non-functional versions as Cipscis suggested instead of deleting them.
However, these cannot be simply blank (i.e. all code, variable and Property declaration removed).
Registered intervals need to be unregistered.
E.g.
Spoiler
```
Event OnUpdate ()	UnregisterForAnimationEvent ()	UnregisterForLOS ()	UnregisterForSleep ()	UnregisterForTrackedStatsEvent ()	UnregisterForUpdate ()	UnregisterForUpdateGameTime ()	UpdateCurrentInstanceGlobal ()EndEvent
```
Properties need to be cleared. Any reference attached to a Property may not be "garbage collected" by the game because it will be forever in use.
Unfortunately, Properties need to be cleared before the Script's blanked-out version compiled.
The Properties window will not open unless Properties are declared in the compiled version of the Script.
Since they've been wiped, the Properites window will not open.
Any Property values attached to that Script before it was wiped out will always be attached.
Deleting the object the Script was attached to could be a solution - but that will create another "empty" reference the game will try to access when you reload it.
Property Types: I found that when I changed the Property type from one to another, its value was corrupt in the game because its game was expecting it to be the type in the saved game.
So, basically, we have to ensure that when we release a mod, our updates do not change any the Types of the Property.
Instead, we'll need to create a new Property and leave the old Property unusued.
Also, at one stage I found a note in the logs that stated something like "the Property in the ESP doesn't match the Property in the saved game, it will use the version in the saved game".
What this means is that we cannot update that Property with new releases.
I think in this situation, I changed an Array Property into a FormList Property.
The Script simply wouldn't run or receive any new OnUpdate () events.
I had to start my game from scratch.
Because previous ESPs and Scripts cannot be wiped from the saved-game, I can imagine a lot of corrupt saves in the near future.
The only way I've been able to test my mods as I develop their code and create new Objects, Scripts, and methodologies is to load a game WITHOUT mods.
Everytime I load a game with a deactivated mod - especially with one that has Scripts that have been deleted instead of made non-functional with a blank script, the game keeps trying to access its code. The log above shows this.
Imagine the integrity of a mature game (30 hrs or more) that's gone through several mod trials, changes and updates.
For updates, it could be better to leave old Scripts that have been made non-functional and emptied Properties alone in the ESP.
Any functional or logic changes to the Objects will need to be built as new Scripts.
The problem here is that they will accumulate over time.
But I think having unusued Objects and blanked out Scripts are better than the game finding them invalid and Empty.
Currently, we cannot guarantee that any updates to mods that we release will not corrupt the user's game at all.
And I doubt anyone can release a mod ONCE and once only without updates to it.
Even if we re-release the mod as a new mod (e.g. ESP), the old deactivated ESP will still be active in the game.

Regardless of how careful we create mods and release updates to it, this new save system is very F'ed! :swear:

» Tue Jun 19, 2012 4:33 am

This issue spans out for more than just world objects. It affects spell effects too. I am doing a racial power mod and for ages I did not know why my changes were being applied, until I realised Ineeded to use a pre-mod save.

The scripts are called by a newly made effect, which is activated by a newly made ability, but the script calls vanilla spell effects.

Essentaily, as it stands, I cannot release my mod until I am certain I do not need to update it- otherwise updates will not take effect over saves. (svcks)

» Tue Jun 19, 2012 5:21 am

Here's another F'ed up thing:
Aliases are saved in your file.

What this means:
1. Create a Quest.
2. Create an Alias.
3. Attach a Script with Properties to that Alias.
4. Remove that Alias (because maybe you've found a better of doing things and do not need that Alias anymore).
5. That Script on the Alias still runs.
6. So when releasing updates to your mods, you need to make sure not to remove unwanted Aliases.
7. Just attach a blanked out Compiled Script to it - as described previously.

» Tue Jun 19, 2012 5:42 am

The problem is the theory that you can release a MOD and then go back and do stuff to it. It is stretching stupid to design the Steamworks system to encourage people to amend MODS when the game does not want amended mods to be run (because of dirty saves).

It's all good while I'm testing, I put quickstarts and shortcuts in quests/scripts, so that I can start a new game and quickly get to what I want to test.

But once release as happened you can't ask Players to start a new game everytime you find and fix an error (or update functionality) in a mod.

Basically, your first release needs to be final ... or many people are not going to update to your final as it will either break their save or your revamped mod will not work.

So far, I can see few workarounds that are palatable (releasing cleaning mods is a possible ... but damn that makes it a lot of unnecessary work)

Did this problem exist in Oblivion?? I don't remember having similar issues in Morrow, is all I can say ...

(I'm hoping for a Beth statement that says ... ooops BUG, or one that says, Oi! Idiots! Don't do it like that!)

» Tue Jun 19, 2012 12:21 am

Moral of the story for all the people who dont feel like reading the entire thread like I just did (again)

Scripts stay on objects no matter what, and they are not removable, unless the script has finished (aka deletes itself or unregisters) This is a feature in order for potential objects that are scripted to delete themselves or run on anything with a timed event. This is done in order to save the states for these to work later on, once you load your game.

This means that you must be aware of this change when modifying vanilla objects, as you must start a NEW GAME in order for the NEW script to be loaded into memory. Through my own efforts, I have found that scripts attached to items will reset once they are picked up/ dropped. Other objects such as activators / doors / or other static objects will NOT be able to be fixed unless the object is completely removed from memory. This means that the object in question must NOT be a vanilla object and will be removed upon disabling the plugin. Modified Vanilla objects will still retain the script.

Please be aware of what you modify, as you may run into issues with corrupted saves for updates, rendering new versions of a script to only be used in a fresh game... possibly pissing off a bunch of your audience with "Broken" updates, when it really isn't broken. You may also run into issues testing your newly modified versions of scripts when the object is running an older version.

Again, this is a feature, which means it will most likely NOT be fixed, even though I am sure most of us will want it removed, however it may be crucial to many inner workings of many mods / scripts.

Bottom Line: Be careful what you script for objects.

» Mon Jun 18, 2012 2:52 pm

So... someone remind me again... why are we modding this game?

Pitfalls like this are intolerable. How the hell is Bethesda ever supposed to be able to update a broken script if this is how things work?

» Mon Jun 18, 2012 8:03 pm

Did this exist in Oblivion?

In a way, yes. But we were able to produce "clean" saves by deactivating the ESP and saving a game without it.
The file is relatively clean of the previous mod's functions. The references however are NULLed and can be further cleaned with Wrye.
Maybe Wrye can find a way to remove these linked Events from saved games.
The problem with Skyrim is that the mod's functionality (e.g. Events) are tied to the Scripts.
I think the problem stems from the Scripts (i.e. Class objects) are now separate from the ESP.
That's probably what caused this big problem.
(Modders who regularly check the logs will find that Bethesda's own Scripts produce a lot of errors.)

I added some more checks to my code - trying to UnregisterForUpdate () when IsRunning () is False.

So, I deactivated the mod. But kept the Scripts (the PEX files) in the file system.
I want them there so that I can try to unregister them from events.
If they are not there, the game will continually try to hook into them.
"Clean saving" your game will not remove those "empty references".

Anyway, Even if it detects that the Quest has been unloaded due to the ESP not active,
it can't UnregisterForUpdate () because it can't find the Quest it was attached to EVEN if it keeps triggering the OnUpdate ().

Spoiler

It still detected that it needed an init even if the ESP was not active:

[02/28/2012 - 06:31:38PM] !kuEASQSSleep.initGameLoaded[02/28/2012 - 06:31:38PM] !kuEASAutoEatQS.initGameLoaded[02/28/2012 - 06:31:38PM] !kuEASPlayerS.initGameLoaded[02/28/2012 - 06:31:38PM] !kuEASQSEat.initGameLoaded

Now, the ESP has been deactivated but its previous Script from the mod is still receiving OnUpdate ().
Somewhere in the mod I change the update frequency. Something I do in my mod depending on it's state.
However, it can't apply the RegisterForUpdate () because the the mod has been deactivated.
EVEN IF IT's STILL receiving the OnUpdate () from the save game.

[02/28/2012 - 06:31:38PM] error: Unable to call RegisterForUpdate - no native object bound to the script object, or object is of incorrect typestack:	[None].kuEASQSSleep.RegisterForUpdate() - "" Line ?	[None].kuEASQSSleep.initGameLoaded() - "kuEASQSSleep.psc" Line 55	[None].kuEASQSSleep.OnUpdate() - "kuEASQSSleep.psc" Line 20[02/28/2012 - 06:31:38PM] error: Unable to call RegisterForUpdate - no native object bound to the script object, or object is of incorrect typestack:	[None].kueasautoeatqs.RegisterForUpdate() - "" Line ?	[None].kueasautoeatqs.initGameLoaded() - "kuEASAutoEatQS.psc" Line 60	[None].kueasautoeatqs.OnUpdate() - "kuEASAutoEatQS.psc" Line 20

So I added code in the Script to detect IsRunning () to unregister itself if so.
BUT it can't UnregisterForUpdate () because the Quest is not active.
EVEN IF IT's STILL receiving the OnUpdate () from the save game.

[02/28/2012 - 06:31:38PM] warning: Assigning None to a non-object variable named "::temp4"stack:	[None].kuEASQSSleep.OnUpdate() - "kuEASQSSleep.psc" Line 26[02/28/2012 - 06:31:38PM] error: Unable to call UnregisterForUpdate - no native object bound to the script object, or object is of incorrect typestack:	[None].kueasqseat.UnregisterForUpdate() - "" Line ?	[None].kueasqseat.OnUpdate() - "kuEASQSEat.psc" Line 28

So...the Scripts that are active in the file system receives OnUpdate () from the saved game EVEN if they are not attached to active ESPs.
So, you'd think that you can somehow UnregisterForUpdate () on those. You can't.
You can't UnregisterForUpdate ().
You can't Stop () them.
You can't Start () them.

Another problem here is...what if the mod Author decides to add a new Alias to his Quest mod in an update.
Mod authors can't. Aliases are created when the Quest first starts. It needs to be Stop ()ed and Start ()ed for Aliases to reinstantiate.
I can't even begin to imagine work arounds for these.
E.g. another Quest that simply monitors new versions of the mod.
Because that same Quest will have the same problems as other Quest.

Mind you these problems are specific to Script-based mods like mine.
I'm at the point simply trying to find an easy way release updates.
Don't know the solution at the moment.

Bethesda needs to simply cut ties to the Scripts once the Scripts find that the Quests they are attached to is no longer running.
With this change, we can go back to "clean-saving" our games of mods.

» Tue Jun 19, 2012 5:57 am

.
[code][02/28/2012 - 06:31:38PM] error: Unable to call RegisterForUpdate - no native object bound to the script object, or object is of incorrect type
stack:

This is promising... I think.

So if you never use RegisterForUpdate, and instead use the RegisterForSingleUpdate at OnInit & within the OnUpdate block.
When OnUpdate runs after the mod is de-installed, Re-registering will fail. Loop broken?

Then have a leap of faith that the garbage collection will do the right thing lol.

» Mon Jun 18, 2012 6:43 pm

snip to save on pyramids

Good theory, well written out, mate.

I also tried to see how you could kill the scripts from a deleted or revamped Quest, and I also had no luck. I'll keep looking/thinking, but I honestly don't see a way given - as you put - the errors that appear in the logs from (old versions) of vanilla quests.

Pending any proper "fix", there needs to be a big sticker on the front of the wiki to get people to pay attention and try to minimise the impact of the way the system works (and I can't see that system changing).

Don't mod anything in Vanilla unless you absolutely must - Certainly not items that have scripts attached
Keep your testing community small and make sure they understand to start new games when testing
Try to release a mod that is finished - Going back and amending will cause many problems for your players
If you do have to amend, think hard how your amendments can be created in such a way to minimise the impact of this design-choice
Large/Complex mods that must mod the Vanilla game are (almost certainly) going to require your players to start new games to play them (I have seen mention of a number in this and the Mods forum that are definately going to be heavily impacted)

Of all of the things currently on the "issues" list (Navmesh and World-size X-Axis, included) I think this is the one that will end up causing most pain. Because it effects the players of mods, as much as it effects the people doing the mods.

Thinking caps on ... We need a proceedure that's easy to follow and tries to get mod-authors around the issues they'll face.

(Just from personnal experience: When I started out on the Mod I am working on, I needed to make a fairly simple change to the scripts running off the "Caravans" Quest. Two weeks later and I am still trying to figure out how I can do what I need to do without amending the original script ... and so far, I am failing. At the moment - because of two lines of script - I appear to be authoring a New Game Only mod)

» Tue Jun 19, 2012 3:50 am

...instead use the RegisterForSingleUpdate...

Good idea!
Will test this out in my mods this week.
This will also solve the problem of OnUpdate () running over the previous OnUpdate () in Scripts that have high intervals.

...Thinking caps on ... We need a proceedure that's easy to follow and tries to get mod-authors around the issues they'll face....

I've been trying to get a "one-for-all" Script instantiate and unload block. So far this is what I have:
http://www.gamesas.com/topic/1349590-init-at-game-load-and-init-at-game-restart/

I'll test the RegisterForSingleUpdate () then add to it.

Cheers, guys!

» Mon Jun 18, 2012 6:31 pm

Ok...I tested RegisterForSingleUpdate ()...

At loading a game with the mod deactivated, it only warned me once.
Also, missing variables are skipped, as normal.
I changed a variable name.

Spoiler

[02/29/2012 - 12:47:18PM] warning: Variable cleanApparel on script kuiawqs loaded from save not found within the actual object. This variable will be skipped.[02/29/2012 - 12:47:18PM] warning: Variable cleanEquippedApparel on script kuiawqs loaded from save not found within the actual object. This variable will be skipped.[02/29/2012 - 12:47:18PM] VM is thawing...[02/29/2012 - 12:47:19PM] error: Unable to call RegisterForSingleUpdate - no native object bound to the script object, or object is of incorrect typestack:	[None].kuiawqs.RegisterForSingleUpdate() - "" Line ?	[None].kuiawqs.OnUpdate() - "kuiawqs.psc" Line 28

So, I save my game here. This should produce a "clean save".
Then loaded it up - still without the mod active.
The OnUpdate () interval has stopped.
And better yet, the missing variables has truly been skipped (removed?) from the file.

Spoiler

[02/29/2012 - 12:47:46PM] Papyrus log opened (PC)[02/29/2012 - 12:47:46PM] Update budget: 1.200000ms (Extra tasklet budget: 1.200000ms, Load screen budget: 500.000000ms)[02/29/2012 - 12:47:46PM] Memory page: 128 (min) 512 (max) 76800 (max total)[02/29/2012 - 12:48:00PM] VM is freezing...[02/29/2012 - 12:48:00PM] VM is frozen[02/29/2012 - 12:48:00PM] Reverting game...[02/29/2012 - 12:48:03PM] Loading game...[02/29/2012 - 12:48:04PM] VM is thawing...[02/29/2012 - 12:48:05PM] Info: *Achievement 1 awarded - a winnar is you!*[02/29/2012 - 12:48:15PM] VM is freezing...[02/29/2012 - 12:48:15PM] VM is frozen[02/29/2012 - 12:48:15PM] Log closed

However, this is with RegisterForSingleUpdate ().
I can imagine the RegisterForSleep () and others like it will still execute - because they are still registered to the Script.
And as before, they cannot be unregistered with a deactivated mod because the Script, at this point, is not attached to any valid objects.

BUT I found a safer alternative to trigger player sleep start and sleep end events. Will post in a new thread.

Edit: here's how to use Conditions (particularly IsPCSleeping) in Papyrus: http://www.gamesas.com/topic/1354316-conditions-in-papyrus/

» Tue Jun 19, 2012 2:46 am

I don't have access to Skyrim at the moment, so I can't test it myself, but could someone see what happens if something like this is used so only native types are ever registered for anything?

ScriptName Something extends ObjectReference; Inside an event...Parent.RegisterForSingleUpdate(1)

Does the code still run correctly? What errors show when the script is removed?

Generally I'd say this is bad practice, as it seems an entirely unnecessary addition that wouldn't be removed by optimisation, but if it provides us with only an advantage here then it mightn't be a bad idea...

Cipscis

» Mon Jun 18, 2012 11:00 pm

I'll check this out, cipscis.

Some of these problems were actually kind-of mentioned in the Wiki:
http://www.creationkit.com/Save_File_Notes_(Papyrus)
However, there's nothing like experience to truly understand a text book manual.

I think the only real problem they have to address are with the Events.
It should easily be fixed with a patch.
Because the script itself can detect if it is attached to a "native" object (as shown in some of my logs in previous posts),
the script itself should be able to cancel the next iteration of the Event.

Also, I apologis for my ramblings. Hahaha! I'm sure 90% of my sentences (and the concepts I was trying to present) were run-on sentences and difficult to understand.

» Mon Jun 18, 2012 7:31 pm

The problem, as far as I've been able to tell, is that by removing the script you're also removing the object type, which might prevent the Papyrus engine from travelling up the hierarchy to find the native type that was extended by the script.

It's possible that it won't like "Parent" for a similar reason, but if that's the case then a manual cast to its parent native type might work.

Cipscis

» Mon Jun 18, 2012 8:44 pm

Actually, it's the other way around. The Script file is still in the FileSystem.
But the ESP (e.g. Quest, its Properties, and its Aliases) have been deactivated and so invalid in the game.

But, I think, what the game does is it finds a reference to the Script it in your saved game.
And so, it uses that Script file to send OnUpdate () events to - even if the Script is not attached to an Object (a Quest or Alias in my particular case).

» Mon Jun 18, 2012 3:47 pm

Oh, I thought the script had been removed as well in those tests. In that case, perhaps it's that the script was calling RegisterForUpdate on the object as whatever type was defined by the script, but once the data file is removed the object no longer has that type? I'm not sure whether or not that's the case, although I could see it as being possible that, after deactivating the data file, the script is still attached but the object no longer has that type. Definitely something that needs testing before I could say one way or the other, though.

Cipscis

» Mon Jun 18, 2012 1:40 pm

Yeah, I did several tests. All of them produced errors.

ESP deactivated but Scripts still exist: OnUpdate () kept running even if it couldn't find Variables and Properties it uses.

Script deleted: Same. OnUpdate () kept running.

ESP deactivated but Script recompiled as an empty script: OnUpdate () ran once - I think.
The only suggestion of this were error messages about missing Variables/Properties in the log.
However, I can imagine that OnUpdate () kept running after that first - since it couldn't be unregistered because the ESP was deactivated.
No messages were in the log because at this stage the script was empty and any Variables/Properties attached to it form the saved game has been removed.

ESP stil active but Script recompiled as an empty script: Same as above.
But with this, we can add an "unloaded" test in the code and unregister the events.
This is probably the safest optin.
But we wouldn't want the user to load a "cleaner" ESP just to deactivate a mod.

» Mon Jun 18, 2012 2:36 pm

I think, that propertys, that don't exists anymore, are not a problem, but events running until the end of the game. When you have 20 uninstalled mods with events still running, this may slow down the game.

But this method works for me:

int Property FxVersion autoGlobalVariable Property DRWFxVersion Auto ; You have to set this global to 1Event OnInit ()FxVersion = 14 ; Increment with new versionsDRWFxVersion.SetValueInt(FxVersion)InitMod() ; My functionsEndEventEvent OnUpdate()If(!updateLocked)If (DRWFxVersion.GetValueInt() == 0) ; Global does not existupdateLocked = trueUnregisterForUpdate()Debug.Notification("Mod uninstalled!")ElseIf (DRWFxVersion.GetValueInt() != 14) ; Increment with new versionsDRWFxVersion.SetValueInt(14) ; Increment with new versionsDebug.Notification("Mod updated!"); OrYouHaveToStartWithCleanSaveBecauseThisEngineIsFromHell.Show()ElseUpdateMod() ; My functionsEndIfEndIfEndEvent

You can check, if the mod is uninstalled to stop events and you can check, if the mod was initialized in other version.
I think, that it's not possible to put that in a central update-quest, because even if an event in another quest is still running, you can't access the other quest itself via script.

» Mon Jun 18, 2012 5:28 pm

Hey PixelMurder, If this is attached to a Quest, then if that Quest's ESP is deactivated, you'll run into the same problems I did.
The Script will not be able to UnregisterForUpdate () because it won't find the object it was attached to.
Regardless of where you attach this to, when the ESP is deactivated but the Scripts still exists, OnUpdate () will keep running on those Scripts.
But if you remove the Script as well, you'll hit onto the same problem. The OnUpdate () will keep trying to trigger itself on the non-existant Script.
The best option I've found is RegisterForSingleUpdate (). Then after the Onupdate (), you call RegisterForSingleUpdate () again.

Edit:
Basically, once registered to a reiterative event, the Event manager will continually send the events to the registered Scripts.

If the Script has been dettached from its Object (e.g. Quest, Spell, etc... when the ESP is deactiavted) but still exists, the variables the OnUpdate () uses will be invalid throwing errors.
And because the Script is not attached to any Object, Unregister calls in your code will fail.
The Event manager has no links to the Scripts invalid variables and properites and so is not affected by the errors.
And so it'll continually send events to the Script.

If the Script has been deleted, then the Event manager will still keep pinging that Script.

So the best option is to only register for one-off events.
After that event fires, it's done.
If the ESP has been deactivated, it'll fire that event.
The OnUpdate () fails because it's variables and properties become invalid.
At this point, the variables and properites attached to that Script is then discarded - according to the Wiki.

If the Script is deleted (by a Mod Manager when the mod is deactivated), the event will fail because there is Script to send it to.
But because it's a one-off event, it wont try to ping the Script again.
Properties and variables are also discarded in this cirumstance.

The problem arises with other reiterative events that have no one-off version.
E.g. OnSleepStart and OnSleepEnd.
Once registered, the Event manager will keep firing these events at invalid Scripts.
With these two events, I use IsPCSleeping Conditional Magic Effects attached to Abilities to detect when the player sleeps and wakes up.

Spoiler

Also, it looks like we're trying to do the same thing in looking for a good "start-up" process for our Scripts.
Yours is very similar to mine: http://www.gamesas.com/topic/1349590-init-at-game-load-and-init-at-game-restart/Both look like they address the inital set-up of the Script.
However, mine tries to address OnGameLoaded () situations - when the mod author needs to add, change or override data from a previous version.
It's still not full-proof, however. If you spend more than 60 seconds in a menu, initGameLoaded () gets triggered.

» Tue Jun 19, 2012 4:58 am

When i have the same scipt, running a Debug.Notification() in OnUpdate(): without my check, it will show this messages until end of the game. With my check, it doesn't show messages anymore. And this is a sign for me, that the event is stopped.
A global variable, that doesn't exist, returns 0. And when it was initially set to 1 and returns 0, the mod does'nt exist.

» Mon Jun 18, 2012 11:23 pm

@PixelMurder, it's hard to follow your code above.
You're setting a boolean to true, within a block that only runs if the boolean is true.
I'm assuming that's a typo. That boolean isn't declared either, so you may have made some typo's when pasting what you really use.

As that boolean is a condition that encompasses the whole of your OnUpdate() Event.
if you toggle it, you stop the event body (and messages) from ever running.
That doesn't mean that the OnUpdate has been de-registered.