*grumbles about the gotchas thread not being a sticky*

So. Here's one for everyone. Not sure if this has been documented anywhere because I'm not sure anyone has ever tried it.

Dwip found something that's pretty nasty. I'd link to the discussion, but it took place on my blog which is, shall we say, not sanitized for language. Here's the gist though.

He's modified some aspects of the Arena. In doing so, he rewrote vast portions of the arena betting script. This new script took the existing Bethesda material and added boatloads of new stuff to it. He then took the existing Arena Spectators quest and assigned it a new script - his behemoth of a rewrite for it. What resulted from that was that some dialogue conditions in the standard arena topics are now pointing to incorrect variables.

In looking things over in tes4edit, when he copied Bethesda's script to modify it, the new script got a new table of variable indexes. Bethesda's original script skips the #2 index because the apparently deleted or modified a variable. Dwip's script did not skip this index because his was compiled fresh in that setup.

The result of course is that everything past the #1 index is pointing to the wrong variable. At least as seen in dialogue checks. I can't say for sure if this has also broken any other usage of those variables in other scripts because he wouldn't have needed to recompile any of them since the actual quest name didn't change.

Needless to say, this is a pretty big gotcha in terms of consequences. One that certainly isn't terribly obvious.

Assuming this wasn't a fluke, anyone else ever done something like that and torn their hair out wondering why everything was broken? Also seems to me that this should get documented in a more permanent manner somewhere like on the CS wiki.

I can pretty much say for certain that it's possible to break dialogue result scripts due to this, and I've experienced behavior from an object script that is almost certainly due to this problem. Since documenting it at your place, I copied all of my edits back into Bethesda's script and changed the quest to point back at Bethesda's script. At that point the actual dialogue worked fine, but I had to go back and recompile the result scripts and the object script to fix them back to the correct script. Didn't change anything, but it did take the recompile to fix back to the way it should have been.

Which seems to be saying to me that you can do all sorts of editing to a script and have it work ok, but changing from one script to another can lead to all sorts of really strange stuff. Things just not firing, dialogue repeating itself, very unpredictable results.

Some of the symptoms Dwip was mentioning on the blog appear to similar to ones I've had reported with Gweden Brothel, which adds a quest in the Arena (I bet my Nord's more naked than his), with the Red Room Gate getting stuck closed. I may have to register over there and compare notes, now you have a handle on a cause.

Yeah. In thinking about it more, any variable reference back to the quest would be thrown off since the index table would be expecting things to be a certain way and swapping the script on it would change all that. Dialogue results, references from other scripts, AI pack conditions, you name it.

We actually discovered this a couple years ago, and yes it affects all scripts. When the compiler references a variable on another script, it stores only that var's index, not its name. Any change to the script then which reorders the variables will cause the other script to reference the wrong thing. Besides changing vanilla scripts, the other big culprit is when people add variables to their scripts when writing a new version of a mod.

Eg:

scn SomeQuestScriptint var1 ;index 0float var2 ;index 1...scn SomeOtherScript...if (SomeQuest.var1 == 1 && SomeQuest.var2 > 10.0)...

Then in v2 of your mod change the quest script to

scn SomeQuestScriptref refVar ;index 0int var1 ;index 1float var2 ;index 2

Then the if statement in SomeOtherScript is going to attempt to use refVar and var1, rather than var1 and var2, unless it's recompiled after the change.

Bottom line:
Anything which reorders script variable declarations requires all other scripts which reference it to be recompiled.
If you only need to add new variables to an existing script, you can get around this if you're always sure to add your new variables are at the end of the existing declarations.

That "Recompile all scripts" button is beginning to make sense, although it would only be useful for Beth developers! It's a pity it can't be highjacked to recompile all the scripts in the current mod only.

scn SomeQuestScriptint var1 ;index 0float var2 ;index 1

scn SomeQuestScriptref refVar ;index 0int var1 ;index 1float var2 ;index 2

Just tried this in the CS, results don't match what you're getting at.

Instead of refVar getting index 0, it was assigned index 3 as expected, despite it being declared before the originals.

So I'd have to say modifiying within the script is fine, otherwise there's going to be a lot of us in a heap of trouble.

It's when you take a quest that has Script A, and then change it to use Script B that the gotcha I posted becomes the nightmare scenario because the CS does not update things to correct for it.

The "recompile all" option still wouldn't fix the issue with dialogue and AI pack conditions pointing to the wrong variables in any case. Those still need to be corrected by hand.

I may be misremembering the details, but there was definitely a problem with reordering variables in a script. I'll try to track it down again if I get time. Alas that forum history doesn't go back that far...

It is reported here : http://cs.elderscrolls.com/constwiki/index.php/Common_Mistakes#Changing_Script_Variables
So what goes :confused:

The CS wiki issue you're linking to isn't the same thing as the one I posted here, which is what I added the "Changing a Quest Script" section for.

What the CS wiki describes is having a script, then having a mod alter that script to change variable types to something different and causing chaos of another variety.

Both of these are equally bad things, but the quest script issue wasn't documented before and is actually considerably worse than modifications within the same script.