37 réponses à ce sujet

[Genisys]

(Edited)

This is designed to be a basic tutorial, showing scripters the importance of making use of constant switches (Constant Variables which control a script or multiple scripts) within a script..

This is a very trivial tutorial, and would require basic knowledge of scripting.

(NOTE: Variable would be replaced with one of the following:   int / string / float)

Script A)    (No Constant Switches)

void main()
{
  //A Bunch of code will go here..

  variable a; //May Change
  variable b; //Does Not Change

 //Still yet more code may go here...
}

Script      The Constant Switches go above the #include "scriptname" & void main()

(Here is an example of making use of a constant as a switch (the term switch is being used here to represent constant that controls the outcome of a script)

//Set the constant below to TRUE if you want ______ to happen..
constant variable VARIABLE_X = FALSE;  //default = FALSE (don't do this)

#include "somescript"

void main()
{
  //A Bunch of code will go here..

  variable a; //May Change
  variable b = VARIABLE_X;  //The Constant Unchanging Variable Above.. (VARIABLE_X = is the name)
 
 //(another example of use)
 if(VARIABLE_X==TRUE)
 {
   // Then do something here..
 }

 //Still yet more code may go here...
}

If you can see the importance of the Constant Switches, which is nothing more than a control for a script, then you will understand that Constant Switches will not only save yourself time later if you want to come back and change the script (& most likely will), but they also give others looking at your script greater control over your script, for one builder may like it one way, while another may like it another way, we therefore can avoid dissagreements by making controls within a script (Constant Switches) that effect how the scripts works..

I love Constant Switches, because I try to build for the community, I try to include these control switches when I can..
And they are absolutely fabulous for Template Scripts (Script you will use a lot)

Hope someone enjoyed this.. 

Modifié par Genisys, 06 septembre 2010 - 05:59 .

[ehye_khandee]

What ARE you on about here? SWITCHES? Are you perhaps using a wrong / non-standard term for this (because I don't recognize it and I've noted loose use of jargon in your notes before).

Your text does nothing to explain the code and the code is really bare bones, so, if there is something here, maybe you can elaborate (and double check your terminology).

I notice you have a constant in there, but 'switch' is not the term to use there.

Modifié par ehye_khandee, 31 août 2010 - 05:34 .

[Lightfoot8]

Looked to me like he was wanting to build something like the X2_inc_switches.



He just did not get any of the points across to make it usefull.

[GhostOfGod]

This is what I think of when i see/hear "switches":

int iInt = d3();
switch(iInt)
{
case 1://do stuff;break;
case 2://do stuff;break;
case 3://do stuff;break;
}

That is actually what I thought I was going to see when I clicked on this topic.

I think you are just referring to constants that you can change at the top of the scripts to alter/customize a script to fit the needs or desires of the users. Not sure if there is a specific term for them. Customizable constants? Configuration constants? Control Constants?
I use these in the systems I've made and posted because I know people like to do things their own way. People might want a different sound to play, or a different visual effect, or a different item to drop, etc.. These are just some examples of what you might put in a constant variable at the top of scripts to easily let people alter the script.

Modifié par GhostOfGod, 31 août 2010 - 06:12 .

[ehye_khandee]

just constants is all they are called. also, never use constants unless you absolutely NEED to, as there are a limit to the number you can use in a module, so why waste?

[The Amethyst Dragon]

ehye_khandee wrote...

just constants is all they are called. also, never use constants unless you absolutely NEED to, as there are a limit to the number you can use in a module, so why waste?

I've encountered a limit in constants in individual scripts (especially when using mutiple "#include" files), but is there a whole-module limit I missed somewhere?

[Genisys]

ehye_khandee wrote...

just constants is all they are called. also, never use constants unless you absolutely NEED to, as there are a limit to the number you can use in a module, so why waste?

Uh oh, looks like I was giving bad advice then..

What is the limit, do you know?   <<<I need to know myself..

[Genisys]

The Amethyst Dragon wrote...

ehye_khandee wrote...

just constants is all they are called. also, never use constants unless you absolutely NEED to, as there are a limit to the number you can use in a module, so why waste?

I've encountered a limit in constants in individual scripts (especially when using mutiple "#include" files), but is there a whole-module limit I missed somewhere?

If you hit a limit with one script, try reducing the # in that script, then create a new script with more, and see the results..

I'm curious if his statement is true, because I have to tell you with over 2000 scripts in my module, with loads of constants in the many different include scripts, I have never hit this limit message or whatever that is suppose to happen..

I use A LOT of template scripts, many of which use 2-8 constant variables them, plus many of my systems, and other builder's systems, use constants, I have to question the validity of that statement, don't get me wrong, I just want to make sure & know the precise answer as well..

Modifié par Genisys, 31 août 2010 - 07:35 .

[Shadooow]

Yes there is limit on number of functions+constants+global variables. AFAIK nobody doesnt counted exact number, but many peoples reached it already. For example there is somewhere at vault (cant find it atm) include file with all 1.69 constants, which is very nice but if you have a medium sized custom include file and put it together you reach this limit immediately.

PRC scripts reached it too, but they use for compilling script Torlack Compiler and this compiler has this limit bugger or even none.

Modifié par ShaDoOoW, 31 août 2010 - 07:36 .

[Lightfoot8]

There is a limit to the number of constants that the NWN compiler can handle. So yes, if you try to include to many constants in a single script, you will run into problems. Constants in never winter scripts, are not true constants. Meaning they are not allocated constants in the constant memory section of a program. The nwn compiler does not even assign a constant to a Var memory location. It replaces the constant with the literal value when it compiles the script. So if you have a constant defined as :

const int nApples =5;

then
....
int growth += nApples;
is the same as
int growth += 5;

And compiles to exactly the same thing. The compiler replaces the nApples with 5 while the code is being compiled.

Edited: for spelling.

Modifié par Lightfoot8, 31 août 2010 - 08:38 .

[Genisys]

If what your saying is true Lightfoot8, then how could there be a limit?   (Can you fix your spellings some, I couldn't make out all of what you were saying there, sorry..)

I'm lost, and would definitely like a solid answer here, because I've seen some insanely high constants & functions in some includes which are part of other includes which also have many constants & functions.

Can someone add some clarifications on this topic?   (Me confusa)

Modifié par Genisys, 31 août 2010 - 08:22 .

[Shadooow]

When LightFoot8 wrote they are not true constants he meant that in other, higher, programming languages the constants behave a bit differently. For NWScript don't worry head about this.



As a rule of thumb, constants in normal script are okay, but avoid putting constants into "main" include file as you could very soon reach this limit.

[Lightfoot8]

Simple answer:



If you do not get a compile error when compiling your script, you do not have to many constants in it.



The number of constants in one script will not effect any other script.



The limit is there because the compiler can only handle so many constants/vars. Unless you are trying to include a Global master var/constant list into every script you write I dout you will often if ever hit the limit.

[Genisys]

Uh oh...

Ok, so I'm making this include which will be attached to all spell scripts that I'm editing, this Include has quite a few constant (maybe 10 or 15 I think, not sure as the list is growing) though only like a few functions (4-6) (possibly 1-3 more)...

Am I doing something wrong, based upon the given information supplied thus far?

Any suggestions?  Cause I don't want to mess this system up, it's important to me, and others..

Modifié par Genisys, 31 août 2010 - 09:11 .

[Lightfoot8]

No, You will not mess up the system. You are only using the includes the way they should be used.

[Genisys]

*Woosh* Thank Lightfoot8, I had serious scare there for a moment, thinking I was making some grave error in judgment or something...

[ehye_khandee]

Genisys wrote...



(Edited)
This is designed to be a basic tutorial, showing scripters the importance of making switches (Constant Variables which control a script or multiple scripts) in scripts..

This is a very trivial tutorial, and would require basic knowledge of scripting.
(NOTE: Variable would be replaced with one of the following:   int / string / float)

Script A)    (No switch / Constant)

void main()
{
  //A Bunch of code will go here..

  variable a; //May Change
  variable b; //Does Not Change

 //Still yet more code may go here...
}

Script      The Switches (Controls) / Constants go above #include "scriptname" & void main()

//Set the ? below to (what?), where ? = _____.  (You fill in the blanks)
//Tell yourself and others what changes to ? will effect)
const variable VARIABLE_X = ?;   

#include "somescript"

void main()
{
  //A Bunch of code will go here..

  variable a; //May Change
  variable b = VARIABLE_X;  //The Constant Unchanging Variable Above.. (VARIABLE_X = the name)

 //Still yet more code may go here...
}

Genesys, 
    You are misusing the term totally. Please call a constant a constant and stop confusing others with invalid jargon. Also, in your examples NOTHING is hinging on any of the constants, so what exactly you are trying to pass on to others in this post I cannot even guess. 



In short   GAAAH!

[ehye_khandee]

The Amethyst Dragon wrote...

ehye_khandee wrote...

just constants is all they are called. also, never use constants unless you absolutely NEED to, as there are a limit to the number you can use in a module, so why waste?

I've encountered a limit in constants in individual scripts (especially when using mutiple "#include" files), but is there a whole-module limit I missed somewhere?

I refuse to use an outside compiler for NWN, it is just my way. I helped tame a PRC server a while ago and was getting loads of issues out of it (lots of script cleaning ensued). I've also run into resource limits in the module as a whole when upgrading (sic) from CEP2.0 to 2.1 (and I will do that NEVER again). It was all down to constants of which there were way too many in the 2.1+ my module, and again, much script cleaning ensued.

IDK the exact limit, but it cuts into resources and I treasure resources, using it very very sparingly - I find I do no wrong that way.

[Shadooow]

ehye_khandee wrote...

Genesys, 
    You are misusing the term totally. Please call a constant a constant and stop confusing others with invalid jargon. Also, in your examples NOTHING is hinging on any of the constants, so what exactly you are trying to pass on to others in this post I cannot even guess. 



In short   GAAAH!

No he does not totally. Yes, he reffering to constants, however isn't constant like a constant.

There are special cases of constants that if you change them, changes behaviour of whole script. Many global scripts from vault uses that. If user do not like one feature there is constant-switch that after changing to 0 turn that feature off. I think the word switch is in proper place there.

Also the default bioware module load has special switch system, these switches are local variables actually, the good on them is that they do not require the affected script(s) to be compiled. But more experienced scripters tends just to place the variable on module by hand.

In my understanding, if there is anything that changes behaviour of the script(s) it may be named "switch". For example UO Abigail craftin system had material switches in the craftin placeables. If player took that switch, material was set up to silver etc.

Its not a ba technique, but personally I don't like too much global scripts (like Funky Swerve's SIM Tools) at all.:innocent:

[Invisig0th]

ShaDoOoW wrote...

ehye_khandee wrote...

Genesys, 
You are misusing the term totally. Please call a constant a constant and stop confusing others with invalid jargon.

No he does not totally. Yes, he reffering to constants, however isn't constant like a constant.

There are special cases of constants that if you change them, changes  behaviour of whole script. Many global scripts from vault uses that. If  user do not like one feature there is constant-switch that after  changing to 0 turn that feature off. I think the word switch is in  proper place there.

Also the default bioware module load has special switch system, these switches are local variables actually, the good on them is that they do not require the affected script(s) to be compiled. But more experienced scripters tends just to place the variable on module by hand.

In my understanding, if there is anything that changes behaviour of the script(s) it may be named "switch".

Well then, your understanding is wrong. Yes, Bioware used the term "switches" to refer to their system of global values obtained from local variables on objects. However, that is not relevant here, because that is not what Genisys is doing. Genisys is simply setting constant variables at the beginning of scripts. No one who knows anything about computer programming would call what Genisys is doing here "switches". Everyone in this thread understands that except you.

You may use whatever made up terminology you like, but please don't try to tell those of us who are actually programmers that your made up terminology is correct.. I'll remind you that this is the scripting forum, and that insisting on using incorrect programming terminology is extremely unhelpful, because it confuses new people. Perhaps it is confusing you as well?

Modifié par Invisig0th, 06 septembre 2010 - 05:06 .

[Lightfoot8]

I hate to dissagree but shadow is correct. And yes the boiware system does set constants at the begining of there switches. After all the name of every switch is constant. They have different values set to the switch (TRUE or FALSE). But the Name of the modular var where it is stored is a constant.

[Invisig0th]

Irrelevant. I've already explained why.

As a professional Solution Architect with 15 years of computer programming experience, I can assure you that using the term "switches" here is incorrect, confusing, and counterproductive. But don't take my word for it -- ehye_khandee and GhostOfGod have also said the same thing above. What Genisys is talking about here is simply setting constants.

It has absolutely nothing to do with the Bioware system you mentioned at all. That is nothing but a red herring. Setting constants at the top of a script in the toolset (design time) is completely different from getting values from the localvars of objects (runtime). Apples and oranges.

If you want to insist on using incorrect terminology that does nothing but confuse people, then forgive me if I insist that you are wrong. This is the scripting forum, after all, and incorrect information helps no one.

Modifié par Invisig0th, 06 septembre 2010 - 05:21 .

[Lightfoot8]

I Guess you should tell Bioware to change the name of there include to something other then x2_inc_switches then.

[Invisig0th]

Setting constants at the top of a script in the toolset (design time) is completely different from  getting values from the localvars of objects (runtime), which is what that Bioware script file does.

//----------------------------------------------------------------------------
// Return the value of a module switch set by SetModuleSwitch
// See X2_INC_SWITCHES for a list of all module switches
//----------------------------------------------------------------------------
int GetModuleSwitchValue(string  sModuleSwitchConstant)
{
    int nRet =  GetLocalInt (GetModule(),sModuleSwitchConstant);
    return nRet;
}

That is not what is being discussed in this thread. They are two completely different things. You are doing nothing but further confusing the issue.

Modifié par Invisig0th, 06 septembre 2010 - 05:37 .

[GhostOfGod]

I can totally see how these constants can be viewed as "switches" though. They can indeed act as a switch in a script. Perhaps when referencing them in in your scripts Genisys, you can call em "constant switches" or something. Or in posts maybe "Constants being used as script switches". I don't know. Something that won't confuse people with an actual "switch" is all.

2 cents. Maybe only worth 1.

Modifié par GhostOfGod, 06 septembre 2010 - 05:40 .