At what instant do scripts get baked into your save? When you check the plugin the script is used by and load the game. Or do the scripts get read and saved into your game directly from the scripts folder simply due to their presence in the folder, even if the plugin is not checked in your load order? And does this include fragments on dialog infos as well? Or do they get baked when the quest they are attached to starts?

As soon as you save your game with the scripts active, they are baked into the save. Why would they be present in a save made previously to the introduction of the scripts in your game?

I understand that, but as I asked, does the mere presence of them in your scripts folder cause them to be saved, or does the esp they're used by have to be checked. The reason I ask is I have a weird error going to the log from a couple of fragments on a couple of dialog infos that I cant get to go away.

Ah, I see. You shouldn't leave loose scripts in the scripts folder if you are not using them; I'm not sure but they might be loaded and baked into the save. If you don't want to bother about moving them continuously, put them in a bsa and restore the original scripts (psc) if necessary. Also remove the pex files of course.

That's the rub. It's not that I'm not using them, I am. However, the log says this:

[08/03/2013 - 08:34:43AM] warning: Property ShieldBash on script Balo_TIF__0206C96F attached to topic info 0806C96F on quest BalokConstructionQuest (08023589) cannot be initialized because the script no longer contains that property

I've completely redone the fragment with a different property, and I still get this error even if I load a clean save directly from the main menu using the dev character, and I cannot for the life of me figure out why. Here's the fragment:

;BEGIN FRAGMENT CODE - Do not edit anything between this and the end comment;NEXT FRAGMENT INDEX 3Scriptname Balo_TIF__0206C96F Extends TopicInfo Hidden;BEGIN FRAGMENT Fragment_2Function Fragment_2(ObjectReference akSpeakerRef)Actor akSpeaker = akSpeakerRef as Actor;BEGIN CODEBalokFighter01.PlayIdle(CombatIdleStretching);END CODEEndFunction;END FRAGMENT;END FRAGMENT CODE - Do not edit anything between this and the begin commentActor Property BalokFighter01  Auto  Idle Property CombatIdleStretching  Auto

I've gone as far as completely removing the fragment, saving my plugin, and recreating it again and saving, but the error persists. As you can see there is no ShieldBash property on the new fragment. I can see it throwing the error on a dirty save, but why would it throw the error with the dev character from the main menu? It's driving me nuts, lol.

I am not an expert by any means, but that error seems to occur when you change a property or correct a property - it still seems to think it should be linked to the original property or object. Vanilla Skyrim papyrus logs have them as well. It's as if once you change something, the CK and the papyrus logs remember what it was and says "no longer has that property".

To properly test any changes to scripted parts of your mod, you have to start a new game or use a save that has never seen the mod activated. The old version may be baked in and cannot now be shifted. I found this when I could not get map markers to activate for a mini quest mod - I know I had corrected it properly, but it just would not work. So I started a new character without the mod active and used batch files with incpcs to level up his skills etc and saved to test the mod.

Apparently, there are all sorts of advantages to papyrus and the saved games working like this, but this is one of the downsides.

~.~

Right, I know that, that's why I was testing from the main menu using the built in dev character, which is impossible to have my mod baked into it because there WERE no saves. He is loaded straight from the main menu, not even loading a previous save. That's what's so maddening with all of this.

... Sorry...

The other thing is, make sure you pull up the Properties window in the CK for that fragment, close it, then save your .esp again.

As far as I can tell, information on properties attached to scripts are stored in two places: the compiled script itself (the pex file), and in the .esp. It takes actually opening the Properties window in the CK for the mod (the .esp part, that is) to refresh its list of the properties from the script. So you'll see that kind of error if you delete a property from a script in your script editor, but don't refresh the properties list in the CK--because the .esp will still think the old property should be there.

AAHHH! Now THAT might explain it. It does seem from the message that something is remembering that it used to be different, and so telling you it no longer has that property, even if it is no longer even there. But I never understood how or why.

Bethesda should have opens and closed the properties in the CK as well, then!

~.~