This was an error, because i have copied the code from a script and removed some things, that has nothing to do with the example for stoping an event after uninstall of a mod.
Logically:
If (!updateLocked)
updateLocked is a variable, that i use for immediately stop the event and to prevent stacking.

If the event stopped, you wouldn't need the variable would you?
Your variable is just hiding the messages. If your UnregisterForUpdate() call had functioned, there'd be no need to hide them.

I can't explain what happens any better than kuertee did above.

The variable, i don't need for this case.
Important are only this lines:

If (DRWFxVersion.GetValueInt() == 0)
UnregisterForUpdate()

I can check in a scipt, that doesn't exist, if a global exists. When not, the mod is not enabled, and needs unregister. This works.

And this can detect, if you are using a new version of a previous installed mod. This also works.
ElseIf (DRWFxVersion.GetValueInt() != 14) ; Increment with new versions

Edit: Wait...after reviewing your script, I found something else.
Previous post amended to this:


Let me get this straight...
Here's your code, prettified:

Event OnUpdate()    If(!updateLocked)        If (DRWFxVersion.GetValueInt() == 0) ; Global does not exist            updateLocked = true            UnregisterForUpdate()            Debug.Notification("Mod uninstalled!")        ElseIf (DRWFxVersion.GetValueInt() != 14) ; Increment with new versions            DRWFxVersion.SetValueInt(14) ; Increment with new versions            Debug.Notification("Mod updated!")            ; Or            YouHaveToStartWithCleanSaveBecauseThisEngineIsFromHell.Show()        Else            UpdateMod() ; My functions        EndIf    EndIfEndEvent

Ok...So when you deactiavte the ESP but leave the Script in the file system,
this "If (DRWFxVersion.GetValueInt() == 0)" runs this "UnregisterForUpdate()".

And you don't get an error in the logs that looks like this?

[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 ?

I can understand how you will see the "Mod uninstalled." Notification.
This is because Papyrus will try to continue through the code regardless of errors.
But that is not a true indication of whether your mod Unregistered itself properly.
As far as I can tell, the Event manager fires events to the Script files/classes.
But Unregister commands requires the native Object to exist.
But if the ESP has been deactivated, this native Object is gone and so, the error that I get above.

And I don't see the difference between using a Global Variable instead of an Variable or Property to check for versions.
Mod deactivation is easy to check without Global Variables.
You simply check if a ReferenceAlias or Property that points to an Object in your ESP exists or not.

Okay, this method works only, when you have disabled mod, but not deleted the scripts, but this can occur often, when you're developing or testing other mods.

But only a patch from Bethesda can unregister a mod, like it have to be unregistered. Disabled mods don't have to execute any script or event, even if the pex-files exists. This is a serious bug, from the same guys, that released an exe with crapy code and crapy compilation, forgot to check the 4GB-flag and since three or more games aren't able to create a decent laucher. I care about performance of my users, but Bethesda reacts only, if the whole web, playing a slideshow, names them ***(insert any name you like).

I use a global for this check, because i use other globals too.

Here's a conclusive test. It is free from gameplay features nor objects in the base ESM.
All it contains are:
1. A Quest with a RegisterForUpdate (1) in its OnInit ()
2. An OnUpdate () with a Debug.Notification () and a Debug.Trace ().
3. Both Debugs trace out a custom FormList and a custom Armor.

With the mod active, both Debug.Notification () and Debug.Trace () worked on screen and in the log every 1 second.
I then save then quit the game.

Then I deactivated and deleted the ESP and the Script.
Mod managers will delete both the ESP and the Script. So I'm mirroring this behaviour.
The log detected that kuFLQS was missing. I highlighted these lines in the log below.
And the Debug.Notification () nor Debug.Trace () did not show on screen nor in the log.
So, it looks like the OnUpdate () was terminated.

So, I save the game again at this point - a 2nd clean save.
In normal play-time, this 2nd clean save will naturally as you play the game after deactivating the mod.
I quit the game.

Then reloaded it with the mod STILL deactivated (i.e. no ESP nor Script in the file system).
Unfortunately, the reference to kuFLQS is still in the game as shown with the highlighted errors in the log.
So, the references to the ESP still exist after 2 clean saves.
But again, Debugs from the registered OnUpdate (). A good sign that the event is not firing.
This, I think, is acceptable.
In Oblivion, some objects from deactivated mods persisted as NULL objects.

So, I then changed the mod: removed a Property and so removed that Property's reference from my Debugs.
I returned the mod to the file system but I DID NOT activate it. I.e. the ESP and Script exist but the ESP is not active.
This is to test if the OnUpdate () event was still firing from the time I deactivated the mod.
I.e. removed the ESP and the Script from the file system.
Remember that there were no indications of the OnUpdate () running from previous logs.
This is the log after I loaded the game.
"None" in the OnUpdate () Debug.Trace () tells me that the variables were truly discarded at the save AFTER first deactivation.
However, the Onupdate () Event is still firing!
What this tells me is that the Event manager pings the Script even if it doesn't exist in the file system.

Fears confirmed. Problems abound!!!

I added this to this Discussion Page in the Wiki: http://www.creationkit.com/Talk:Save_File_Notes_(Papyrus)

Note: I think with game tools (e.g. Wrye - maybe?), we'd be able to produce real clean saves.
This was the same situation we had with Oblivion with NULL objects.
Though if I understand properly, NULL objects in Oblivion save games were not only a product of deactivated mods.
NULL objects were simply a product of the game itself as it "garbage collects".

But this problem wasn't as big in Oblivion.
We didn't have reiterative Events back then.

Thanks kuertee for all your posts.
One month later is there any feedback ? Is Beth simply aware about that ?

I've just realised that properties that no longer exists in quest scripts (at least) after a mod update are still called when I'm loading my saved game (Papyrus logs)......
Same thing for scripts (quest scripts, alias scripts, magicEffects scripts, etc) if my mod is completely uninstalled (esp, bsa, scripts folder removed).

That's the most important thing Bethesda should look for. SOS Devs !

it's way too easy to royally eff your game by even the simplest mods.

doesn't matter if you write the most amazing, self-sufficient non-corrupting mod/script. if the user installs a dirty mod, it could potentially wreck your mod regardless.

Dirty mods is a different issue. "Dirty mods" are those that inadvertently changed records from Update.ESM or Skyrim.ESM.

The problem described in this thread is a little bit more worrisome.

@Thanatos00, Unfortunately, I doubt that Bethesda can/will change their base code.
I still have properties that I have removed 2 months ago from mod development that is lingering in my saves. They are still getting reported as missing in the logs.
However, once our tools have matured. I'm sure they can be removed. In Oblivion, Wrye was able to remove from save files NULL records or records that don't point to anything in your load-list.
I've not checked the reiterative calls to unactivated ESPs with the newer versions of the game.
However, I bet that the old problem still exists.

Tips:

• Just tell your users that they don't simply deactivate your mods, they need to completely uninstall them. So make sure that they have Wrye or Nexus Mod Manager.
  This ensures that the Script files are also removed. If your mod was built with RegisterForSingleUpdate () instead of RegisterForUpdate ()...those reiterative calls will stop at the first error. Note that deactivating the ESP will not stop those reitarative calls until their Scripts are removed. That's why uninstallation of mods are better than simply deactivating them when creative "clean saves".
  
• When you use other event calls, e.g.: RegisterForSleep (), ensure that you give your users a way to stop them when they deactivate/uninstall your mod. In my mods, I add a "uninstallNow" Property that the users can set to True via the console. E.g.: SETPQV [questname] uninstallNow True. When my mod registers that uninstall, it will unregister all registered events and remove any Abilities from the user. Note that if the user simply deactivates the mod while they have Abilities from that mod attached, their player stats will be corrupted.

So, basically, to recap this whole thread:

• Properties and reiterative events stick with your saved game - even if your mod was deactivated and uninstalled.
  
• If your Scripts still exists in the file system (i.e. ESP is deactivated but it's Script files are still in the Scripts folder), Properties and Events will be inserted and called in your game. This will not only take up memory but also cause errors in the game.
  
• If your Scripts have been removed (i.e. ESP and Scripts removed),
  
  • Properties will load allways and forever but will not be inserted in the game - saving in memory.
    
  • Reiterative events will still get called continously and forever. It will find an invalid target because your Scripts do not exists anymore. These will be reported in the logs.
    
  • One-shot events will get called the first time, but not again because it's a one shot event. So use RegisterForSingleUpdate () when you can. And give the user a way to unregister any reiterative events you set-up

Thanks again kuertee.

There is something I really don't understand about properties : I've just tried to delete some properties in a quest scripts. As I expected when I load a saved game where my old mod version was running, with the new version, in the Papyrus log I have this kind of message :

warning: Property MyProperty on script MyQuestScript attached to MyQuest (0801DED2) cannot be initialized because the script no longer contains that property

But the weirdest thing is that I get the exact same message if I load my new mod version, with a complete clean saved game (which has never been running my mod)
If I simply unselect my esp file (whitout removing pex and psc files from the script folder), then if I load the same clean saved game, these warning messages about missing properties are gone...

So the missing properties aren't stored in the saved game, but in my esp itself (or maybe in the compiled scripts) ??? I'm totally confused.

Yeah. The properties are in the plugin as subrecord data for the attached form(s), pointing to the FormIDs of their targets.

Wiping the properties, saving, closing CK, reopening and adding the properties back seems to actually wipe the slate clean as all properties will require filling afterward rather than automatically pointing to their previous remembered targets if the CK hasn't closed and forgotten (liken to "Ignore" flag). If it auto-fills on its own, it was never wiped...

Oh many thanks JustinOther !

Ok I've just :
-Removed the script from the quest in the Ck
-Saved my esp
-Re-added the script to the quest
-Auto-filled properties (and give some values to vars that must have an ini value != 0)
-Saved my esp

It's perfectly working, no more property warning in Papyrus logs (for a clean saved game ofc)

Edit :
Omg it seems it is also working with saved game containing old non-existing properties !
After cleaning my scripts with the method above :
-I reloaded a saved game where my old mod version was running, with the new mod version, in the Papyrus log I get this new message :

Variable :: MyVar on script MyQuestScript loaded from save not found within the actual object. This variable will be skipped.

-Then I've saved my game.
-Then I've reloaded this last save : no more warning message of any kind ^^

Cool I've updated Bag of Holding (heavily script dependent) several times adding, removing, changing, and substituting variables and properties alike and never had any such trouble with updating.

Does anyone know if it could be possible that in the latest 2 patches (the big one with the new killmoves and the very recent small one) bethesda screwed interaction between older versions of mods up even more? I'm having a lot of trouble now in newly made versions of my mod with properties, even after making clean saves my script logs are saying some properties are pointing to NONE, even though they are clearly defined in the CK (and saved games which have never had previous versions of the mod active before work fine).

I think in the changelogs of those patches bethesda did mention something about fixing an issue where the game could crash if previously active mods were disabled.. I'm wondering if they fixed it by having properties stick into saved games even harder than before.

Yep, I learned this stuff the hard way... The best way to update if you are changing a property is to delete it and link a new one with a new name. If its during runtime of the script where you made the changes, it should encounter runtime errors and bail out and the next time its executed should be the updated version, I found the problem was sometimes persistent when it was an alias script that was changing.

If you have a quest it's usually best to perform a stop and start to have it reset most scripts to do with the quest, although if your mod IS a quest this poses a bit of a problem as anyone who updates will have to do this portion all over again.
stopquest MyQuest
startquest MyQuest
These have usually dealt with the oddities occurring in my updates. Updating an already running questline is extremely difficult to begin with because you don't know where in the script they are going to update, which is why you need update instructions such as stopping the quest, or getting to a certain stage of the quest.

Your save game should garbage collect missing properties.

"cannot be initialized because the script no longer contains that property" This one means the property exists in the plugin but not the script, need to update the properties that the script is attached to.
"loaded from save not found within the actual object. This variable will be skipped." This one will be garbage collected.

The storal of the mory is: Avoid using Editor IDs if at all possible.

Please elaborate. I'm using vanilla editor ID's for object references (mostly enable/disable markers) in my fragments all over the place, as well as on objects I will be enabling and disabling throughout my rebuild of Helgen. This is not sounding very good.

Vanilla Editor IDs are probably OK...but IDs from your mod will be wrong most of the time if your users are using more or less mods than you are during testing. Anything using something that looks like "0x(big number)" could be trouble.

OK, maybe we're talking about 2 different things. I'm talking about when you place an object, double click on it, pull up it's dialog box and give it a unique name in the very top input field called Reference Editor ID. I thought most people commonly refer to that as giving your reference an Editor ID.

It's things like Game.GetForm(0x02000D62) I'm talking about...in the original mod, it might be for summoning a mighty Sabrecat companion...but if another mod loads in that slot, where it happens to be purple chicken named "Petunia", well, lets just say the results, while humerous, are probably not what was intended.

OK, everything I'm doing is using the Editor ID like I was referring to like: BalokScene01Xmarker.Enable(), and Alias like: Alias_BaloksNPC.GetReference().EnableNoWait()
so these should be OK?

I'm also using vanilla references like: NorthGate.Setopen(true) (opens the north gate of Helgen.)

There is no problem with that. When you attach your propperties to ingame objects that way, the game handles all. As redwood Elf says, it only affects the getform command.

I would like to extend on it, by the way. Once DLCs are released, unless they are fused to Skyrim.esm like it happens with Oblivion's SI, they will have almost the same problems as any mod, as for a user buying the first DLC it will be the 01 file while for another one not doing it, that file could be any other mod.

((I think you mean FormIDs)) ....

Yeah, 'cause I've been using EditorIDs as property names from the onset and never had anything go wrong...

Can't find the Wiki page, but property/variable names should never start with a number, IIRC.