Creation/Dev/Using Classes Effectively: Difference between revisions

From Graal Bible
No edit summary
No edit summary
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
'''http://www.antiunixmad.com/
[[Category:Scripting Reference]][[Category:Scripting Tutorials]]
Note: Code examples in this article use new engine scripting.
= Why classes? =
Classes are a very useful concept in Gscript. They allow many instances of the same code to be run and even dynamically placed. They are also an effective means of sharing functions between scripts. You can attach them to the player, too, where the player is treated as the current object.


Viper's Graal Issues.
= Using classes as standalone NPCs =
Objects, including NPCs from levels or database NPCs, can join a class. That class is then controlling the behaviour of the object. The class can so act either as level NPC, when being joined from a level NPC, or as database NPC, when joined from a database NPC. Many objects can join the same class, which is useful e.g. for ATMs.


Hello everyone, as of late, many people have been attacking me on the issues and matters, trying to lie about things, bend the truth, and downright spin to make me and others of my cause look bad, in this text document i will discuss and lay to rest the issues that matter.
=== Joining from a level ===
To let a level NPC join a class, simply create an NPC and put:
<pre>this.join("classname");</pre>
The NPC will then join the class once created. When updating a class with RC that is joined by level NPCs, you may have to update the level in order to see the update.
=== Joining using putnpc2 ===
To create a databased NPC, you can use the function putnpc2() on serverside:
<pre>putnpc2(x, y, "join(\"classname\");");</pre>
... replacing x and y with coordinate values, or variable names containing these values. A putnpc2() NPC is called a "database NPC", being that it is databased in the NPC-Server, and does not belong to a specific level. Database NPCs usually receive updates when the script is updated with RC immediately. They can also warp to other levels.
=== About database NPCs (including putnpc2 NPCs) ===
When you are finished with a DB NPC and want to destroy it, you should use this.destroy(); serverside. The NPC will then be totally removed from memory. Note that the class will of course still remain on the server.


I have been involved graal for over three years now, and i used to really like Graal and its admins alot, then slowly after about a year Graal and its admins went in a bad downward spiral, i still stuck with graal in hopes graal would pull itself out of this hole and unixmad would go back to the right path, this however did not happen, instead unixmad and even stefan went fouler and lower than i could have imageined, First with fireing Pachuka and Fuitad, two of the BEST graal admins ever in my view for no other reason than disagreeing with his future plans, then if just fireing them was not bad enough, he threatend to sue them and kill they're families, this was so wrong and bad Fuitad even said he would punch unixmad in the face for saying that if he met him in real life, but that was just the beginning of the downward spiral unixmad foolishly invoked onto graal, he then blatantly STOLE a domain name graal.net from Owl Shimy which costed over 30$ US Dollars, and never gave it back to him and never paid him for the cost of the domain, he also threatend to sue Owl Shimy and kill his family although it was Unixmad which stole the domain from Owl Shimy, then around Graal1.3.1 he blocked off Gservers officially and threatend to sue anyone that ran the former Gservers, although they were released as "Freeware" and actually used to encourage people to use the Gservers, this was a blatant attempt to monopolise , threaten, and intemidate that players that actually helped graal and supported him, he then made claims he copyrighted "Graal" and would contact so called "Lawres" about anyone that used the name "Graal" or had "Graal Files" on there websites, although graal was distributed as "Freeware" or "Shareware" and had no official software copyrights related to it, and that the name "Graal" was actually the name of a holy sacred golden cup used in some religion, and in that he has commited blasphemy against whatever religion has the so called "Holy Graal", then later on Unixmad fired SuperNick, because of his country and his origion and called him an American Asian slut, this was the first sign of racism on the part of Unixmad, towards Graal1.4.1 Unixmad was secretly unwrapping his sadistic plans, he then started claiming credit and claiming to own the copyrights to graal, although unixmad has done nothing but host some stupid weak as servers, and yet Stefan Knorr has done all the real work for Graal, and was the one to make ZeldaOnline , GraalOnline in the first place and has written every bit of codeing for the Graal Client , Gserver, RC, ect, yet unixmad the worthless pile of trash that he is steals all credit for Graal, then in February 2001, Unixmad and Antago release Graal2001 and the start of the "Pay to Play" system, now i have no problem with the fact that it is pay to play, the issue is when you PAY for something you actually expect to get the worth while of your money in this product, but instead they got a shittily made level generated land that was 99% empty, the NPCs were and are laggy as hell, and there were no quests, and there is only two shitty things today for hearts that suck so much i refuse to even call them quests, and to add to that about 40% of everyone that paid and gave unixmad there credit card number NEVER got the accounts they paid 27$ or more for, and those that did clearly got chumped out by a cheap peice of crap that aint worth paying for, it sucked so badly that most people played on Graal Classic still, even those that foolishly paid for pay to play accounts, and in an attempt to "FORCE" people to pay for a shitty product they do not want against they're will Unixmad hired "Tyhm" to deface and ruin GraalClassic in an attempt to make it buggier and less fun than even Graal2001, about this time i was disgusted with unixmad and most of the other admins and decided to downright turn against Graal and for the most part stop playing the peice of crap in general. People starting getting angry, complaining, asking for help, and asking for refunds, of coarse unixmad gave noone a cash refund, and simply deleted and banned "PAID ACCOUNTS" of those who complained, asked for help, or asked for a refund these are PAYING CUSTOMERS, they have the rights of basic service that they PAID for, unixmad promises pay to play players a quality product and customer service, but instead gives them a grade F product and ripps off his customers and delete they're accounts that they PAID HIM money for, his excuse? Credit card fraud, when infact at least 90% of the people he bans for credit card fraud pay legitamately with there OWN credit cards or pay via paypal by check, and yet Unixmad has stolen and used others credit card numbers to buy things for himself on several occassions, he also claims he needs pay to play money to keep graal alive and running, yet there has been evidence that he makes at least 90% profit out of the monies he gets, and that he uses illegal porn ad banners and illegal cookie style web tracking and giveing email adresses of the players and even phone numbers of every player to spam and telemarketting companies without there permission, he even keeps personal player info, includeing email, adress, and phone number on unsecure servers which have already been leaked out, such info about people should not be on a public webserver accessable to the internet in anyway, then after all that Unixmad starts banning african american people, asians, koreans, and or people with images of people of that race from the Graal2001 forums and graal itself, yet again they are paying customers and this is another sickening act of racism on the part of Unixmad and GraalOnline, and then even more disgusting is what Stefan posts on the Graal2001 forums, he makes several anti american, racist, pro terrorist, pro nazi, and pro taliban comments on that post and goes on and on several pages bashing americans, this post was offense, obcene, and disgusting to many people includeing myself . If all that does not make you sick to your stomache or dislike unixmad yet, i am far from done, then Unixmad proceeds to illegally DDOS webservers of mafukie and make threats to him over the phone, and has phone assaulted me over 40 times a day between midnight and 5am, and has made threats to sue dozens of people, kill there families, and shut down innocent websites and servers, while hosting illegal stuff and doing illegal things himself with the use of his own wanadoo.fr servers, stuff which includes child porn, bestiality porn, DVD Piracy, DDOS Attacks, theft of copyrighted materials from gameing companies such as nintendo, Credit Card fraud, theft, spamming, phone harrassment, useage of illegal pirated corperate softwares, all this just to start the list of what Unixmad, Stefan, and they're servers are doing 24/7 for nearly 4 years now , anyone that likes unixmad or thinks he is a good person even after all this is clearly a fool, everything in this document is the truth and why i hate unixmad so much, if you like unixmad after all these sickening things he does, then you are no better than a KKK or Neo Nazi member and should go kill yourselfs, i do not tolerate facists, racists, or nazis, they are all bad people, and unixmad is one of the worst of the worst, and no person with any morales could tolerate or support such a person like Stephane Portha or Stefan Knorr. The people that spin, lie and bend the truth in support of unixmad will always exist, but i will always reveal the truth about unixmad, and EVERYTHING said in this document is true, despite what any assclowns try and say about this, and this supriseingly enough is only 1% of the bad things Unixmad has done, how some people even tolerate, none the less support such a bad person is beyond me... I fight against bad people like unixmad, why? Because unlike many others in this world i actually care about other people, and i will do everything in my power to stop unixmad from hurting graal or its innocent players, many say i want to destroy and kill graal, this is NOT true, i used to love graal, i only wish to stop unixmad's evil sadistic illegal actions and restore graal to the great game it used to be when it was "for the players, by the players" , but if i have to destroy GraalOnline in exchange to stop unixmad's tyranny, it will be regreteable, but sometimes some sacrifices have to be made for the greater good, lets just hope that unixmad drops dead and that sacrifice never has to be made... I love graal and lots of its players, and i wish to someday restore it to the grandness it once had, but bad people like unixmad must be gotten rid of if that is to be achieved...'''
DB NPCs have unique identifiers, which can be read using this.name. This identifier can be used to locate the NPC on the serverside, like shown:
<pre>with (findnpc(identifier))
{
  // foo
}</pre>
<pre>findnpc(identifier).foo();</pre>
This allows other scripts to interact with the database NPCs that you have placed. With the new scripting engine you can also access those npcs directly by using identifier.foo.
 
Like mentioned previously, database NPCs are not specific to one level, and such you can use the warpto() command to move the NPC into a new level:
<pre>this.warpto("levelname", x, y);</pre>
This enables great portability.
 
= Using classes to share functions =
If you write a set of functions that you wish to use in more than one NPC, then you can define them in a class, and let each npc join the class instead of copying the functions into each. It also means that you can update your functions across all your scripts, too.
=== Define your functions ===
Open up your class, and define your functions like you normally would!
<pre>function funcName(parameters)
{
  // code
}</pre>
Then save your class. This will provide these functions to any NPC that joins the class, and will allow you to easily update functions between several NPCs.
=== Using your functions ===
Now, before you can use the functions in your other scripts, you must let the current NPC join the class. Like a level NPC, you use the following command:
<pre>this.join("classname");</pre>
Then, you can use your functions.
 
You can easily let an NPC join more than one class, for example:
<pre>this.join("classone");
this.join("classtwo");</pre>
However, this can cause problems where there is more than one function with the same name. You can specify which class you want to use the function from by using the :: operator. The :: tells the scripting engine to look in that specific class, like so:
<pre>classtwo::myFunction();</pre>
This means that you do not have to worry about using the same function name more than once. If function names are colliding, then the first function found will be used, which means either from the script of the npc itself or of the class joined first.
 
= Using "player classes" =
Player classes are classes joined by players. A player-joined class treats the player as the current object (this.). Also, you can create functions available to other scripts through the player object, for example, creating a function that damages the player called doDamage() and then calling it from any script using:
<pre>player.doDamage();</pre>
This allows the player to be treated easier using different functions.
 
=== Join the class ===
You can let the player join the class on serverside like this:
<pre>player.join("classname");</pre>
You could do this in your Control-NPC to, say, join the classes whenever the player logs onto the game server.
 
Player classes are no different to ordinary classes - you should edit them in RC the same way as you do with normal classes.
 
=== Define your functions ===
For functions to be useable by other NPCs, they must be public:
<pre>public function funcName(parameters)
{
  // code
}</pre>
This means that other NPCs can run the function, for example:
<pre>player.funcName(1, "Hello!");</pre>
Non-public functions will not be useable from outside the current script, so you can define normal functions to create a function that you don't want to be called externally, for example:
<pre>function funcName()
{
  // code
}</pre>
 
=== Using your functions ===
If your functions are public, then other scripts can easily call the functions that you have defined in your class, for example:
<pre>player.funcName();</pre>
 
=== this. object ===
Player classes work in a different focus, where the current object (that's the '''this.''' object) becomes the player. So, if you wanted to change the player's chat text in a player joined class, you would use the following:
<pre>this.chat = "Chat text!";</pre>
Calling functions using this. will also call functions from player joined classes, for example:
<pre>player.join("classname");</pre>
<pre>this.playerFunction();
this.anotherFunction();</pre>

Latest revision as of 14:49, 16 February 2010

Note: Code examples in this article use new engine scripting.

Why classes?

Classes are a very useful concept in Gscript. They allow many instances of the same code to be run and even dynamically placed. They are also an effective means of sharing functions between scripts. You can attach them to the player, too, where the player is treated as the current object.

Using classes as standalone NPCs

Objects, including NPCs from levels or database NPCs, can join a class. That class is then controlling the behaviour of the object. The class can so act either as level NPC, when being joined from a level NPC, or as database NPC, when joined from a database NPC. Many objects can join the same class, which is useful e.g. for ATMs.

Joining from a level

To let a level NPC join a class, simply create an NPC and put:

this.join("classname");

The NPC will then join the class once created. When updating a class with RC that is joined by level NPCs, you may have to update the level in order to see the update.

Joining using putnpc2

To create a databased NPC, you can use the function putnpc2() on serverside:

putnpc2(x, y, "join(\"classname\");");

... replacing x and y with coordinate values, or variable names containing these values. A putnpc2() NPC is called a "database NPC", being that it is databased in the NPC-Server, and does not belong to a specific level. Database NPCs usually receive updates when the script is updated with RC immediately. They can also warp to other levels.

About database NPCs (including putnpc2 NPCs)

When you are finished with a DB NPC and want to destroy it, you should use this.destroy(); serverside. The NPC will then be totally removed from memory. Note that the class will of course still remain on the server.

DB NPCs have unique identifiers, which can be read using this.name. This identifier can be used to locate the NPC on the serverside, like shown:

with (findnpc(identifier))
{
  // foo
}
findnpc(identifier).foo();

This allows other scripts to interact with the database NPCs that you have placed. With the new scripting engine you can also access those npcs directly by using identifier.foo.

Like mentioned previously, database NPCs are not specific to one level, and such you can use the warpto() command to move the NPC into a new level:

this.warpto("levelname", x, y);

This enables great portability.

Using classes to share functions

If you write a set of functions that you wish to use in more than one NPC, then you can define them in a class, and let each npc join the class instead of copying the functions into each. It also means that you can update your functions across all your scripts, too.

Define your functions

Open up your class, and define your functions like you normally would!

function funcName(parameters)
{
  // code
}

Then save your class. This will provide these functions to any NPC that joins the class, and will allow you to easily update functions between several NPCs.

Using your functions

Now, before you can use the functions in your other scripts, you must let the current NPC join the class. Like a level NPC, you use the following command:

this.join("classname");

Then, you can use your functions.

You can easily let an NPC join more than one class, for example:

this.join("classone");
this.join("classtwo");

However, this can cause problems where there is more than one function with the same name. You can specify which class you want to use the function from by using the :: operator. The :: tells the scripting engine to look in that specific class, like so:

classtwo::myFunction();

This means that you do not have to worry about using the same function name more than once. If function names are colliding, then the first function found will be used, which means either from the script of the npc itself or of the class joined first.

Using "player classes"

Player classes are classes joined by players. A player-joined class treats the player as the current object (this.). Also, you can create functions available to other scripts through the player object, for example, creating a function that damages the player called doDamage() and then calling it from any script using:

player.doDamage();

This allows the player to be treated easier using different functions.

Join the class

You can let the player join the class on serverside like this:

player.join("classname");

You could do this in your Control-NPC to, say, join the classes whenever the player logs onto the game server.

Player classes are no different to ordinary classes - you should edit them in RC the same way as you do with normal classes.

Define your functions

For functions to be useable by other NPCs, they must be public:

public function funcName(parameters)
{
  // code
}

This means that other NPCs can run the function, for example:

player.funcName(1, "Hello!");

Non-public functions will not be useable from outside the current script, so you can define normal functions to create a function that you don't want to be called externally, for example:

function funcName()
{
  // code
}

Using your functions

If your functions are public, then other scripts can easily call the functions that you have defined in your class, for example:

player.funcName();

this. object

Player classes work in a different focus, where the current object (that's the this. object) becomes the player. So, if you wanted to change the player's chat text in a player joined class, you would use the following:

this.chat = "Chat text!";

Calling functions using this. will also call functions from player joined classes, for example:

player.join("classname");
this.playerFunction();
this.anotherFunction();