KSI-GS (Coding Standards)
 

The following are scripting rules designed for three purposes:

1) To improve the readability of your code.
2) To make your code easier to debug.
3) To minimise errors in your code.

Adhere to them, or Kaimetsu will punch you in the eye and never help you with your code.

DEFINITIONS

Conditional Statement

A piece of code that can be evaluated and declared either true or false. For example, 'playerrupees>20' is a conditional statement; it is true if the player has more than 20 rupees, and false otherwise. 'timeout' is also a conditional statement (along with all other events); it returns true if the flag is set and false if not.

Code Block

A code block is a section of code delimited by braces ('{' and '}'). They can be used to specify the behaviour of many structures, including if, while, for, function and with. Below are some examples.

NPC Code:

---

if(playerenters){

 greetplayer();

}



function greetplayer(){

 if(playerap>60){

  message Hello! So good to see you!;

 }

}

---

Event Block

An event block is a special type of code block. It specifies the behaviour of an if statement that responds to an event. For example, the blue text below is an event block:

NPC Code:

---

if(playertouchsme){

 stealdonuts();

 message Pardon me, sir, I seem to have accidentally jostled you;

}

---

Whereas this is not:

NPC Code:

---

if(this.donuts==30){

 message I am in heaven! ^_^;

}

---

Flags such as playerenters, playerchats and timeout are events. 'this.donuts==30' is just a condition.

Nesting

Nesting is the act of placing code blocks within other code blocks. In the following example, the green text is nested inside the blue.

NPC Code:

---

if(playerchats){

 if(strequals(#c,Where are my donuts?)){

  message I have no idea;

 }

}

---

The green text is part of the blue event block, but the blue event block is not part of the green text. Nesting is an integral part to all truly complicated scripts.

RULES

Rule One

Never include code that is not part of an event block. Think about when you want your code to execute, and place it in a corresponding event block.

Rule Two

Never nest event blocks within one another, or have a single event block depend on multiple events. It's not as bad to have a block react to one of multiple events (playerenters||timeout, for example), but it's still to be discouraged in most circumstances.

Rule Two A

Do not use multiple event blocks that respond to the same event. Check for an event once only.

Rule Three

Don't combine multiple commands on one line unless the relationship between them is clear and obvious. Each line should have only one purpose. The following example is fine.

NPC Code:

---

this.x=10; this.y=40;

---

This line of code simply sets a position - it's okay to put both commands on the same line because they both combine to achieve an obvious purpose. On the other hand...

NPC Code:

---

this.x=10; rupees=100;

---

This code is poor. There is no obvious link between setting an x coordinate and modifying a rupee count.

Be careful about what you consider obvious - as the programmer, you have an automatic insight into the code's purpose. Others will need to figure it out themselves.

Rule Four

Similarly to rule three, do not combine unrelated conditional statements. Instead of writing shambling messes like this:

NPC Code:

---

if(playerrupees>5&&this.monkey==84&&strequals(#g,C  OOLGUYS)){

 message WORD UP DAWG WOOT LOL;

}

---

Try to organise your statements by nesting them, like this:

NPC Code:

---

if(strequals(#g,COOLGUYS)){

 if(playerrupees>5){

  if(this.monkey==84){

   message Yay, our script is now phat;

  }

 }

}

---

Here we have an issue of readability vs efficiency. Intuitively, it makes more sense to check the guild first (if they're not in the guild, we don't give a damn how many monkeys they have). However, the order of evaluation will not change the operation of the script and it's usually more efficient to check normal variables than strings. Try to strike a balance between the two factors, and remember to comment the code if necessary.

Rule Five

Use '==' when comparing two values for equality.
Use '=' when assigning a value to a variable.

Rule Six

Beware deprecated commands. These are old parts of the scripting engine that are no longer supported because they have been replaced. Although they may still work, it is very bad form to use them. Examples:

playersays()
showimg @@@ (using showimg to draw text)
setlevel

Rule Seven

Name your variables appropriately. Variables that are prefixed with 'this.' are usually only necessary if the variable's value has to stay unchanged between executions of the script. If you're just storing a temporary variable, don't add the prefix. As well as small efficiency improvements, this will make your script more readable - it allows people to deduce more about a variable from its name.

Rule Eight

If your script is checking multiple possibilities and they are mutually exclusive (ie, they can't both be true), use elseif instead of a string of ifs. It's more efficient (Graal doesn't always need to evaluate all the conditions), and it adds implicit meaning to your code.

(More rules will come if/when I think of them)

;o
mk

Very good. ::Claps::

Re: KSI-GS (Coding Standards)
 

I noticed at the first part you said 'timeout' was a conditional statement. Then towards the end you called it an event. Whats up, dude?

Re: Re: KSI-GS (Coding Standards)
 

Event flags are conditional statements.

Re: Re: Re: KSI-GS (Coding Standards)
 

Hmm, I see.

Re: KSI-GS (Coding Standards)
 

I agree that things such as playersays() and setlevel, etc. need NOT be used, but I think showimg is still valid. To me, I find it easier to use than showtext purely because I've used showimg@@@ for so long. Sometimes when debugging, I'll start with it displaying like text rather than the image, and then change the string to the actual image and it's much easier to edit.
Anyways, I just think that showimg@@@ is the exception there and that it's still fine to use.
---Shifter

Clearly, this position is deprecated and the GST suggests that you do not use showimg @@@ or anything else that has been superceded by more useful devices. This includes old gscript. --- #gscript

Then you don't understand the concept of deprecation.

Define the concept of deprecation

Sorry, but I'm not going to waste my time indulging your ignorance. There's a big internet right at your fingertips, and it has all the answers you want.

I'm a little nicer than Mr. Kai, so I'll tell you what I think :) .

It is easier for the Graal.exe to break down everything between just the commas rather than break down the commas then have to break down the '@' signs. Takes less time and less proccesing power.

I'm not sure if that is correct, just a guess from my common sense vault.

That's not the definition of deprecation. Look it up.

That was why it is easier for Graal to use the new showtext rather than showimg for showing text. Anyone can look it up :\ .

not really true, the code for showtext is probably exactly the same, which is why, unless stefan fixed it, if you use @ as the text graal wont show

He must of fixed it :) .

No. Deprecation is not a reason for an engine to behave a certain way. Look. It. Up.

*feels stupid*

For some reason I thought deprecation had to do with delimeters. Sorry for dropping the average IQ of this thread :( .

S'okay. You presumably looked it up and, if that is the case, some good came out of it. :)

I looked it up. So, yes. Ussually I can just figure out what words mean by the context they're used in. I guess I failed this time.

Why dont you just make a tutorial?:p

Because making a tutorial wouldn't benefit me in any way whatsoever?

sure it would... everyone who read it would attack you saying "YAY KAI!!! YOU MADE A TUTORIAL!!!" and you would never get any peace and quiet ever again...

my turn for input. :)

For for statements, the initial varible you should use is i. If you must nest them, start with i, followed by j, then k, and so on.

NPC Code:

---

for (i=0;i<5;i++) {

}



for (i=0;i<5;i++) {

  for (j=0;j<3;j++) {

    for (k=0;i<1;k++) {

    }

  }

}

---

It's a good habit, but I don't want to throw weight around on stylistic issues. Incidentally, the term "initial variable" seems strange. Why initial?

*shrugs* Just the first word that went to my fingers. I'm watching TV and browsing the forums at the same time, so I'm not putting much thought into wording.

because you are declaring the start of the variable i ???

No, you have it backwards. i is short for iterative variable.

iterativevariables -_- iterative program commands you mean? such as If, For, etc

the i if the for function

for(i =0;i >10;i ++){}

Could be replaced with another letter or even a word as any other variable can ?

As I was saying before he said initial variable I am guessing because ishould be the first/initial letter to use in a for

i just like the letter i...

I don't know what the hell you are talking about. Listen:

i stands for iterative variable. Don't try to correct me until you at least know what 'iterative' means. You could use any variable in a for loop, i is simply used most.

I like to use b in my for loops. But anyways..

I think it should be added where code should be layered according to how how it's used. For example:

NPC Code:

---

if (strequals(#a,SaijinGohan)) {

 if (strequals(#g,Bravo Legends)) {

  say2 Yay!;

 }

}

---

The above is properly 'layered'.

NPC Code:

---

if (strequals(#a,SaijinGohan)) {

   if (strequals(#g,Bravo Legends)) {

say2 Yay!;

}}

---

The above is not properly 'layered'.

Thats my little pet peeve. It just seems easier to help people when its that way.

That's just a stylistic choice. The underlying code will be exactly the same either way.

good god.. dont get into where to put brackets... we all have differant styles of scripting... i for one hate my damned enter key and weasal out of "layering" any chance i get...

Ok fine but I still think it's easier with some kind of format.

Kai said he'd think about how to phrase this after I told him, but he never posted soooo, in the deprecated commands section:
Don't use toweapons unless you're making the script on a server without an NPCserver, OR EVIL MONKEYS FROM THE DEPTHS OF HELL WILL COME ABOVE GROUND AND EAT YOUR SOUL. :)

I requested a disabletoweapons=true serveroption (or it to be globally disabled with the exception of classic). Stefan said he would consider the server option.

or just be careful =|

Mleh. Classic is supposed to be getting a conversion. So all the more insentive to hurry it up.

That really works when stupid Levels Team members get the idea to try to add a weapon with a name that already exists?

That really works when old backup levels with toweapons are added and played on?

:-\

i agree with tseng... ive uploaded old levels and found "toweapons" in there... had a good time getting disconnected about 7 times before i realized it was there too