HI,
I've updated one of my mods. It used to have the following script attached to treasSatchelRare

Scriptname JM_BAS_LoadAllIngredients extends ObjectReference  {Gives the option of dumping all of your ingredients into a satchel at once}Function JM_LoadAllIngredients(ObjectReference satchelToBeFilled)		int ingredientCount = 0		bool dontShowNotification = true													 ; parameter passed to the removeItem method to indicate whether to inform the player of each move		formlist JM_AlchemyIngredients = Game.GetForm(0x020048AD) as formlist			; Ingredient list		Message msgAskAboutIngredients   =  Game.GetForm(0x02000D62) as message		; Message box		debug.notification("version 1.0 revision 6")											; Show current revision		ingredientCount = game.getplayer().Getitemcount(JM_AlchemyIngredients)			; Count player's ingredients		debug.notification("Ingredient count = " + ingredientCount)							; Show count of player's ingredients		if (Utility.IsInMenuMode())															; Check that the user hasn't exited the menu before asking if they want to put their ingredients away			if ingredientCount > 0															; If they have - ask them if they want to put them in the satchel						if msgAskAboutIngredients.show() == 0										; Ask if player wants to transfer all ingredients into satchel: 0 = Yes, 1 = No					Game.GetPlayer().RemoveItem(JM_AlchemyIngredients,200,dontShowNotification,satchelToBeFilled)  ; Transfer 200 of each ingredient into the satchel					debug.notification("All ingredients transferred")				endif			endif		endIfendFunctionEvent OnActivate(ObjectReference akActionRef)	 GotoState("Disable_OnActivateEvent")	JM_LoadAllIngredients(Self)	 GotoState("")endEventstate Disable_OnActivateEvent  event OnActivate(ObjectReference akTriggerRef)	; Do nothing  endEventendState

This was fine except for the fact that the editorIDs seem to change if other mods are loaded.

Looking though posts on here it seemed properties are the way forward. So I wrote a new script as follows:

Scriptname JM_BAS2_LoadAllIngredients extends ObjectReference  {Gives the option of dumping all of your ingredients into a satchel at once} Function JM_LoadAllIngredients(ObjectReference satchelToBeFilled)        int ingredientCount = 0        bool dontShowNotification = true ; parameter passed to the removeItem method to indicate whether to inform the player of each move        debug.notification("version 2.0 revision 1")     ; Show current revision        ingredientCount = game.getplayer().Getitemcount(JM_AlchemyIngredients)    ; Count player's ingredients        debug.notification("Ingredient count = " + ingredientCount)        ; Show count of player's ingredients;        if (Utility.IsInMenuMode())                        ; Check that the user hasn't exited the menu before asking if they want to put their ingredients away            if ingredientCount > 0                        ; If they have any ingredients - ask them if they want to put them in the satchel                        if msgAskAboutIngredients.show() == 0            ; Ask if player wants to transfer all ingredients into satchel: 0 = Yes, 1 = No                    Game.GetPlayer().RemoveItem(JM_AlchemyIngredients,200,dontShowNotification,satchelToBeFilled)  ; Transfer 200 of each ingredient into the satchel                    debug.notification("All ingredients transferred")                endif            endif;        endIf endFunction Event OnActivate(ObjectReference akActionRef)     GotoState("Disable_OnActivateEvent")    JM_LoadAllIngredients(Self)     GotoState("")endEventstate Disable_OnActivateEvent  event OnActivate(ObjectReference akTriggerRef)    ; Do nothing  endEventendStateFormList Property JM_AlchemyIngredients  Auto  Message Property msgAskAboutIngredients  Auto  

The problem I'm having is that if I add the new mod and remove the old one, the old script is still running. Is this supposed to happen?

If I copy the new script over the old one - it will run but the properties don't seem to be working (ingredient count always returns 0) and the message won't show.

Any help would be much appreciated.

Editor IDs change based upon load order.

Yeah. This is why I was trying to use properties instead. The problem I'm having is that properties seem to be saved in the savegame file. i.e. the properties of the objects which have been affected by the old script don't seem to inherit the properties associated with the newer version of the base object. This seems crazy, as it makes publishing updated mods almost impossible.

Ah well - I'll have to try and find another solution...

Does a clean save help? Uninstall the mod, save the game, re-enable and load from that save?

Just tried that - it still tries to run version 1 of the script. Even if I disable all mods, the game still tries to run the script!
If I go back to a save before I used version 1 of the mod, the version 2 of the script will run fine.
I don't want to (but may have to) have to tell all of my subscribers that they'll have to go back to a save pre version 1 of the mod and replay their game.
Surely there must be a way of forcing a save game to forget about the old version...
If there isn't then surely the subscription model in Steamworks is broken.

I confirm, Tried some other things today, it's worse than anything we had imagined...
For test, I added a simple quest script to fire a sound every second in the game :

Scriptname Testscript extends QuestSound Property ActiveSound AutoEVENT onInit()registerForUpdate(1)gotoState ("Loop")endEVENTSTATE LoopEVENT onUpdate()ActiveSound.play(Game.GetPlayer())endEVENTendSTATE

If i load the game with it, save, uncheck the esp and reload, the sound are always here every second ! It's mean that every script we add are definitly in the save game ! No way to stop them !
Of course, if i change the ActiveSound properties to something else, nothing happen and the first sound is always here.

I didn't remember having this kind of problem in GECK ? I'm really disapointed and I wonder if I will continue to script something in CK. Scripts seem to dangerous to use right now, don't really want to broke savegames.

This is really bad news.

Do the property values still stick if you remove the script files, save and install a new version of the mod?

Weird thing seem to happen if i change the sound property :

• Check the esp.
  
  
• Load a a clean save (I hear "sound1" every seconds)
  
  
• save
  
  
• uncheck the esp
  
  
• load the last save (I always hear "sound1" every seconds !)
  
  
• save
  
  
• check new esp and change the sound property to "sound2"
  
  
• load the last save ( I always hear "sound1" every seconds, and... "sound2" at the same time !!!! So script are duplicated !)

This behaviour seem to be the same for all properties.

I also tried to script a book to show a message when book are read, to see if it happen only with the event "onupdate" or not. If I uncheck the esp, and open the book, the message are always here...
So it's the same for all scripts, they are saved definitly in the savegame. I let you imagine the mess it can cause...

I think I will personally not use any scripted mod right now... Scripts can completly broke a savegame.
I didn't remember having this problem with the geck. So it seem to be a major bug in the script engine (scripts are not unloaded correctly if they are not present)

I wait confirmation from another modder on this. Because if it's confirmed, lot of peoples will need to restart their game if something go wrong with mod using scripts !

EDIT :
Just removed .pex file, loaded the save game and the script doesn't play sound every second. So it seem that you only need to remove script file to delete script from save.

Replacing your compiled script with an "empty" compiled script should fix that, but it's not a very clean way to uninstall...

Cipscis

EDIT:

Also see this page and it's talk page - http://www.creationkit.com/Save_File_Notes_(Papyrus)
Here's what I've said in the talk page:
Cipscis

Scripts/Properties attaching themselves to saved games is a MAJOR problem.
This was a sign that something would be wrong: the Scripts have a "hard-link" to the Properties.
It points to non-portability and I thought it was wrong to have that.

The games we use to play-test our Scripts with will always be corrupt.

EDIT:
And so, a best practice is to always stick with the same ESP, same Quest, same Scripts/Properties, etc...
So compiling the same scripts will always overwrite what was in the saved game - instead of new Scripts/Properties stacking in the game.
And the old idea of having ONE major Quest running all your functionality could still be valid as a best practice.

Just removed .pex file. I loaded the save game and the script doesn't play sound every second. I saved again and replaced the pex file. Sound loop is gone. Great.
So the only thing bother me now is the saved Properties, how can't be changed after. (unless you delete and recreate the attached form...)

I have found through my own testing, unaware of this topic, that if the object is something you can remove, (say, a script on an item?) picking the item up and dropping it again will set the script correctly. Not sure of any ways to fix actors, objects, etc. but just a helpfull hint

Have your tryed disabling-enabling the scripted object?

Wow, this is just... wow. No wonder I've been seeing such oddities when updating my mod!

Well that's not cool. Why would they want to make scripts stick to the save like that?

yah...this is not good.

my experience tonight:
1. a function may have gotten stuck. it was probably queued to run but i saved and quit before it executed.
2. when i restarted the game, all seemed ok.
3. later weird things started to happen.
4. so i deactivated the mod.
5. i had a Debug.Notification on that function. and even with the mod deactivated, the function was running.
6. because the mod was deactivated, the spell it was suppose to add forces the script to fail. so the function never finishes.
7. even if it wasn't attached to an OnUpdate ('coz there was none 'coz the mod was disabled), the function was still running every update from the OnUpdate from when the mod was active.

8. to try to clean my game: i renamed the compiled script (pex file), made sure the mod was deactivated.
9. reloaded the game. the function wasn't running. resaved the game to a new file.
10. renamed the pex file back to what it was.
11. loaded the game WITHOUT the mod active.
12. the function didn't execute but the script went through it's initialisation process. their Debug.Notification showed on screen.
13. so the link to the script and it's OnInit () (and i assume the quest it was attached to) was still in the file.
14. the quest would run WITHOUT the mod active.
15. but the scripts will fail because it won't find the spells it needs because the mod is not active.

bottom line: corrupted saves that cannot be cleaned.




EDIT:
at 14 above, the script did run through it's initialisation process even without the mod active.
i quit the game and looked at the log.

[02/18/2012 - 11:47:21PM] !kuELAAWPlayerS.initGameLoaded reinit[02/18/2012 - 11:47:21PM] !kuELAAWPlayerS.updateEncumbrance 0.000000[02/18/2012 - 11:47:21PM] !kuELAAWPlayerS.updatePenalty 0.000000

however, even if the variables/properties were initialised, it seems to have failed and stopped at a critical point:

[02/18/2012 - 11:47:21PM] error: Unable to call RegisterForUpdate - no native object bound to the script object, or object is of incorrect typestack:	[ (1) on  (00000000)].kuELAAWPlayerS.RegisterForUpdate() - "" Line ?	[ (1) on  (00000000)].kuELAAWPlayerS.initGameLoaded() - "kuELAAWPlayerS.psc" Line 46	[ (1) on  (00000000)].kuELAAWPlayerS.OnUpdate() - "kuELAAWPlayerS.psc" Line 20

it seems that the linked OnUpdate was removed because the function didn't show its Notification again.
i saved the game at this point.
i'm not sure if the link to the script was completely cleaned but it is possible.
i reactivated the mod and it went through its initialisation process.
without the error above this time - because the mod was actually active.

bottom line: i really don't know what is happening.
it could be that for mods that have OnUpdate intervals, the next OnUpdate iteration will run even AFTER the mod is deactivated.
removing (in this case renaming) the compiled script then resaving the game helped clean it.
i can assume that with a Mod Manager (e.g. Wrye), deactivating a mod will also remove its associated Scripts.
so, doing a clean save is still a valid procedure of cleaning the game - EVEN if that LAST onUpdate runs.

GOT DAMMIT. First navmesh, now this?! Every corner I run to so I can mod, is BORKED in some way. So NO WONDER all the scripting and testing I did all darn day yesterday didn't WORK.

I can't deal with this.

Creation Kit: I dont wont you to mod

FINE!

Yes noticed scripts keep running as well..

I guess the modding community and all mod users will have to get used to the fact that just deactivating a mod is no longer enough, they'll have to completely uninstall the mod (or at least uninstall whatever the mod put in the scripts folder) if they want to stop using a mod.

On the other hand, this could something that can be fixed through Wyre Bash. Well whenever they are able to.

Seriously, have anyone tried disabling and then enabling the scripted object? The scripts you attached will continue running until they are finished. Same applied to variable and properties. This is not a bug, it's how is supposed to work and it has it's own advantages. it's fully documented in the wiki. Disabling the affected object should do the trick.

Now about the advantages, suppose a mod creates a lot of vanilla objects that are auto deleted later. Without this system, if the mod is uninstalled those objects won't be deleted ever. Now, the scripts will continue running and will delete them. This is a feature that if used properly could make uninstalling certain mods cleaner.

This has it's advantages and disadvantages. Keep in mind this. A script attached to an object won't stop just because you have changed where this script came from. Use this to your advantage.

And again, try disabling and enabling the objects you want detach the scripts from.

I can't see any practical way to disable and enable the objects really when the mod has already been unloaded. If you're using a script with an OnUpdate block, it would need to have some sort of way (defined by the mod) to check whether the mod is still active. However, if the mod is deactivated, chances are that it will fail to check correctly because whatever variable you're using to check no longer exists.

Also, what about scripts which don't use an OnUpdate block but an OnHit block? They'll remain attached and won't know when to remove them.

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. And it can't be outside the script either, because it would have to be in some other script in the mod, and the mod is deactivated.

And what about scripts attached to the player? I haven't tried this but I'm pretty sure that disabling the player will crash the game or have other bad results.

I think I didn't explained myself here. I'm not saying that the scripts should enable and disable themselves. What I'm saying is that this let objects added by your mod delete themselves (variables and properties are also maintained and that is indeed part of the problem), when your mod is no longer installed and that you can disable and enable the objects from outside the script to eliminate the scripts.

Obviously, the thing that interest most of the modders is how to eliminate the scripts. There are two possible scenarios here, an update and an uninstallation. In the first case, you can implement in the new version a method for disabling and enabling objects with your scripts attached, in the second one, if you use scripts that could get stacked on objects not created by your mod, you need to add an esp to disable and then enable the objects needing cleaning. Also, a disabled object enables itself when the respawn happens. Not sure if there are exceptions.

By the way, there need to be a brief period of time between the disable and enable commands. The object need to be unloaded (just enough to make it invisible. Applying both commands one after the other won't work, use a wait() in between)

You have a good point about the impossibility to disable the player. That's why an alias should be used to avoid attaching scripts directly to the player.

Just in case. I'm not saying that this is an amazing feature. It's just that there were two options when an script is attached to an object and the source of the script is changed or uninstalled, the one they choose, or applying the change directly. Both options could cause serious issues. We can't expect this to be fixed, because it's not a bug, it's just their choice between two unavoidable problems. They could change to the other way, but that wouldn't make things better.

So, let me see if I grok this:

1. When updating a mod with scripts attached to objects, those objects need to be disabled and enabled in order for the script to update.
2. When uninstalling a mod, you need to basically do the same thing, by somehow magically knowing that your mod was uninstalled.
3. This does not affect things like Quest scripts.

This basically makes the creation of mods that affect NPCs through scripting that much harder - hell it makes scripting that much harder in general. Assuming I understand this properly. I honestly don't see how this system benefits anyone.

I suppose that's not the only method. Surelly the normal cell respawn will be enough to fix stacked scripts, though I didn't tried it yet.
There is little magic here, you need to know the kind of mayhem your mod can cause and create a proper uninstaller esp. Something really tricky depending on what your mod do. Unless, respawning cures this. Something needing to be tested. I really think it should, as it reset other object related characteristics, like angle or scale.

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.
Apparently not. I suppose the reason (if things are indeed this way) is that quest scripts are part of the CK, object scripts are not and needed to be attached.
It has not benefits. There was a problem (objects with orphaned non native scripts attached) and two possible ways (destroy them or let them continue), both leading to big troubles.

This is something needing a lot of testing on our part (does respawning fix this? what about unloading the 3d model? Are quest scripts really safe?. Good ideas are also needed.

Maybe a not so clean workaround could be to make scripts attached to permanent objects highly dependant on one or two properties. Once those properties are removed, the script won't be able to cause any harm.

Some suggestions:
-try not to attach scripts to permanent objects (or to the player)
-If you need to do, try to add in your esp or in another one, a method disabling, waiting and then enabling the objects were this can be applied (the player gets out of this again). Maybe the spawn fix this in any object that can be in a different cell while the respawn happens.
-Makes scripts attached to the player or to other objects non fixable dependant on properties to work (if (property) type conditions in vital parts as an example). Keep in mind that you could attach in those cases an tiny script just making the calls to another one better suited to be deleted (a quest script if as it seems there are not affected, a script attached to an object defined in your mod or simply attached to an object you could delete without problems...)

I want to clarify something that I've seen a few people here seem to be confused about.

Scripts are set up in two ways - the data file tells the game which object(s) should have this script attached to them, and the compiled script (which is not part of the plugin) is what the game looks at when running the script.

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.

If the script is only attached to objects which are entirely defined in your data file (i.e. not an altered form from a master file) then disabling the mod will cause all instances of the object to disappear, so no problem. However, for objects that still exist without your plugin file active, the script will still exist so the game will still look for your compiled script. If that's still there, then the script will still run.

As far as I've been able to tell, there is no reason whatsoever why disabling an object should detach a script from it. I'll admit I'm not sure whether newly created instances of an object will still have a script attached after a mod is uninstalled (I expect not, which would mean some instances might have a script attached while others might not), but I've seen no reason to believe that disabling an object detaches its scripts.

If someone could test this and post the results here, that would be cool. I'd be incredibly surprised if it fixes the issue, though.

Cipscis