Variables on Objects...

[Legacy_Leurnid]

               I am contemplating the merits of using a single script for things like self-closing and/or self-locking doors.

In my test module, I have a tidy, single script that will execute either or both events, and might be set to include more options, depending on the outcome of this discussion.

The script works by checking for stored variables on the door. if the correct float is present, it will use that as the delay timer for closing or locking, if no variable is set, or the variable is set to 0, then the close and/or lock events don't fire.


I like the idea of a single script with stored variables to control execution case by case, instead of a bunch of indivually modified scripts, but I am concerned that this may not be 'best practice', and that by glutting a module with a bunch of locally stored variables, it may have an adverse effect on the modules performance.

TL/DR:  Is it bad practice to keep variables stored an many doors and placeables?
               
               

               
            

[Legacy_Lightfoot8]

               If you are consistantly storing more then 1000  variables per object, Then  yes.
               
               

               
            

[Legacy_The Amethyst Dragon]

               I much prefer using multipurpose scripts that use variables on objects.  It cuts down on the number of "resources" a module contains (gotta stay under that 16k limit), and makes it easier to work with multiple objects.

I use this method all the time for things like flavor text triggers (using a string variable on each trigger).  I even have specialized code in that same script for a couple of other extra events I might want to happen in specific spots which don't, in my opinion as a builder, warrant adding a whole new script...and those are triggered by another variable on the trigger.

I also use the same approach for things like spots for climbing, and for fruit trees, and for all sorts of other interactive objects.
               
               

               
            

[Legacy_henesua]

               I think this is more of a question of design. How easy is it to work with the local variables and all in one scripts that you are writing? What are you comfortable with?

If it is working well for you, I think it is the right path to take.

In terms of efficiency, TAD said it well. It is more efficient to reuse the same script rather than make several that do variations of the same thing because the quantity of module resources does relate to performance. The more resources you have the harder your machine has to work.
               
               

               

                     Modifié par henesua, 27 avril 2012 - 06:10 .
                     
                  

            

[Legacy_AndarianTD]

               I use the approach you describe (a reduced number of scripts tailored by using locally stored variables) aggressively, and whenever I can. Far from there being a question of whether this is a "best practice," I would strongly suggest that anything else is poor design, both from a performance and from a maintenance perspective.
               
               

               

                     Modifié par AndarianTD, 27 avril 2012 - 11:05 .
                     
                  

            

[Legacy_The Amethyst Dragon]

               Also, sometimes it's just a lot faster and easier than doing something like a tag-based system that parses an object's tag into pieces for different options.  No need to parse anything out (just use multiple, easier to understand variables), and it's much faster in the toolset to right-click and pick the "Variables" option than to go the "Properties" route, wait for the window to open, then change out an object's tag.
               
               

               
            

[Legacy_Leurnid]

               Thanks all!
My experience outside of NWN has told me it is best practice, but the lack of widespread documentation for this practice in tutorials and vault scripts made me suspicious enough to ask.

Tutorials and script-helpers really should spend more time emphasizing this practice.
               
               

               
            

[Legacy_henesua]

               Disagree. There are instances where it is NOT best practice. If you need a works out of the box solution for a builder, local variables and complex scripts are not the way to go.

Granted I am playing devil's advocate here, but I see no value in any effort throughout the NWN community being put toward teaching best practices. This is purely for fun, and provides an environment that is great for learning from your own mistakes. "Following the leader" will not help you develop yourself.
               
               

               
            

[Legacy_Leurnid]

               The 'out o the box' scripts are plentiful on the vault, and I don't expect all those scripts to have elaborate set-up procedures because its advantageous over time. I understand that many builders are barely interested in plug and play scripts, and certainly don't want to tangle with anything more elaborate than that if possible. Scripting tuts aren't really for that class of builders tho. If you are learning scripting you probably want things that don't come out of boxes.

Almost every scripting tutorial begins by teaching best practices in regard to defining variables at the beginning and using variables instead of calling for data every time you need it (defining and using oSelf throughout a script instead of OBJECT_SELF, for instance).  I wish those tuts had included more on when, where, and how to predefine local vars.

It's all academic of course.
               
               

               
            

[Legacy_Lightfoot8]

               

Leurnid wrote...
Almost every scripting tutorial begins by teaching best practices in regard to defining variables at the beginning and using variables instead of calling for data every time you need it (defining and using oSelf throughout a script instead of OBJECT_SELF, for instance).

If you have a tutorial that is telling you that it is a better practice to use oSelf in place of OBJECT_SELF, In all places.  You have a bad tutorial.  Or at least a tutorial that is teaching something that is not always the best practice.   The fact of the matter is that best practice is not globally unique,  What is a best practice for one person may not be the best practice for another.    We will use your OBJECT_SELF as an example for this.   It is in fact faster and better to use OBJECT_SELF in a script.   OBJECT_SELF Retrives the data faster then getting the same data being priviously stored in into a Var named oSelf.   The reason for this is quite simple OBJECT_SELF is the current object so it's location in memory is already loaded into the ESI regester on the CPU.   There are time however when using OBJECT_SELF can get a beginer scripter into trouble, because OBJECT_SELF will always refferance the object that the code is currently running on.  With the use of AssignCommand  that object is not always the same as the object the script is running on.   For a scripter who has an understanding of how OBJECT_SELF  reacts in given scripts, It is a better practice to use OBJECT_SELF then the var oSelf.   If the scripter is a biginer and does not have an understanding in the way it reacts, he is better off always use oSelf  except in the cases where he has learned that OBJECT_SELF is needed for the correct results.   

In fact now that I am thinking about it,  Defining all the Vars at the begining of the script is also subjective.  There are times where it is not the best practice.        

I wish those tuts had included more on when, where, and how to predefine local vars.

It's all academic of course.

  When:  Anytime you need to pass information into a script from another script.  
  Where:  normally for me it is from within a script that I set Iocal Vars.  I seldom set them in the toolset, But I that is an option also.
  How: With the Toolset or the Scripting functions.  

The LocalVars are nothing more then variables that have ben attached to an object.   Being attached to an object that have a scope(Life Span)  equal to the life span of the object.   This alows you to create vars that have a larger scope  then the vars used in a script.   So basicly every thing you learn about variables that are local to you script, Also apply to the things we call LocalVars that are nothing more then variables that are Local to an Object.
               
               

               
            

[Legacy_Leurnid]

               I should have said 'good practice', not best. I wasn't trying to declare an absolute, but point out what is generally good form...

There are a lot of things that are good practice that are often disregarded by experienced users, not because they are reckless but because they thoroughly understand their product and tailor their solutions to the specific issues they seek to address. Commenting code, spaces, indents, variables or direct calls, etc.  

When I say good practice, I mean good practice for your average and below users who look at the screen and see green squiggles, not the Matrix. In that sense, *best practice* is being an expert... but the tutorials are not written for experts.
               
               

               
            

[Legacy_AndarianTD]

               Well, let me play devil's advocate on the OBJECT_SELF example, and use my own experience as an object lesson (pun not intended). If you *know* you only want your script to run on the current object, then using OBJECT_SELF will work and is perhaps a little bit faster. But I have had a number of scripts that I've written or adapted, initially with the intent that they be executed on the current object, and then realized that I needed to generalize to be run anywhere. If you adhere to the "set a variable at the top and use it" approach, that's a two-line change. Otherwise, it's a search and replace effort that can be prone to error.

That's one reason why the "set a variable and use it" approach is considered good software engineering practice *in general*: for clarity, and ease of maintenance. I've participated in code reviews where the author would be sent back to re-do the work if he made use of constants within the body of his code in that way. My software engineering discipline already predisposes me to those kinds of practices, which I would argue were developed for good reasons.

My own mods may be unusual in that I tend to make them -heavily- scripted, and perhaps more so than most. If you're just using a limited set of scripting features and don't script heavily, it won't matter as much. But heavy scripting allows you to do more with your modding, and after a certain point I think it becomes necessary to enforce a certain set of standards and discipline on the process if you're going to be able to manage it effectively.
               
               

               

                     Modifié par AndarianTD, 28 avril 2012 - 02:03 .