davidlallen Posted February 28, 2011 Share Posted February 28, 2011 In this thread I have learned a surprising and disappointing lesson about local variables in scripts: http://forums.bethsoft.com/index.php?/topic/1170296-issues-with-variables-in-dialogue-result-scripts/ Scripts can be written in a number of places, such as a quest script, an object script, or a few places where you can type in a script to a dialog box. This second type of script never has any name of its own; it includes scripts in the begin/change/end section of a package, or a dialog before/after result, or a terminal action script. When writing the second kind of script, never ever declare local variables! It will compile and run, but while running it will trash other data in ways you cannot predict. Please see the thread at bethsoft and if possible comment over there, to keep the knowledge centralized. This *may* explain a lot of weird results we have seen when writing dialog and package scripts. Link to comment Share on other sites More sharing options...
Floatsup Posted March 1, 2011 Share Posted March 1, 2011 Intresting. Thanks for the heads up. Link to comment Share on other sites More sharing options...
rickerhk Posted March 1, 2011 Share Posted March 1, 2011 If you need to use a function in a dialog result script, and it won't compile because you are using a referenced variable as one of the parameters, you can do this: short iTemp set iTemp to Myquestname.iItemcount MyactorRef.Additem MyWidget iTemp I've used temp ref variables too. Link to comment Share on other sites More sharing options...
davidlallen Posted March 1, 2011 Author Share Posted March 1, 2011 Well, as far as I can tell from the other thread, if you do that then you are overwriting the first variable declared on any NPC who says that line. This leads to mysterious problems which are hard to diagnose. That is because the "short iTemp" declaration creates a variable at the same memory address as the NPC script variables. So the assignment to iTemp places the same value in the first NPC script variable. If the first NPC script variable happens to be a float, then it will be set to some huge weird and/or negative value. Link to comment Share on other sites More sharing options...
rickerhk Posted March 1, 2011 Share Posted March 1, 2011 Well, as far as I can tell from the other thread, if you do that then you are overwriting the first variable declared on any NPC who says that line. This leads to mysterious problems which are hard to diagnose. That is because the "short iTemp" declaration creates a variable at the same memory address as the NPC script variables. So the assignment to iTemp places the same value in the first NPC script variable. If the first NPC script variable happens to be a float, then it will be set to some huge weird and/or negative value. It should be easy enough to set up a test to see if that is actually happening. FNVedit tells you the variable numbers for a given script so you aren't going to be guessing when looking for variable 1, etc.But there are many actors without scripts - what about them. Personally, I think the result script is running in it's own context in reference to the actor - not the actor's NPC script. Link to comment Share on other sites More sharing options...
davidlallen Posted March 1, 2011 Author Share Posted March 1, 2011 The evidence in the OP in the linked thread seems conclusive that this is not so. I wonder if this may be behind many problems of apparently inconsistent/unexpected behavior from un-named scripts. Further discussion over at that thread. Link to comment Share on other sites More sharing options...
rickerhk Posted March 1, 2011 Share Posted March 1, 2011 Fortunately, I have just a handful of result script that do this, and can be easily moved to a menumode section of a quest script.I'm still going to test it out to see for myself as it would be nice to finally have a verifiable reason why it shouldn't be done ;) Link to comment Share on other sites More sharing options...
Recommended Posts