Creation/Inspection/Playerworld Scripting: Difference between revisions
No edit summary |
|||
(3 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
' | [[Category:Scripting Reference]] | ||
=== Introduction === | |||
So, you've created your playerworld and decided that you want an inspection to check that things are in order, before being moved to Hosted. There are various requirements for playerworlds to pass inspections, and scripting is a quite important part. | |||
=== Why inspect scripting? === | |||
We inspect scripting because it helps to protect your playerworld. There are people out there who will take advantage of the Graal client, and careful scripting methods can help to reduce the amount of damage that can be done by using client hacks and such. | |||
There are a few things which will be looked for upon a scripting inspection, and in this article, we'll cover the basics of what the inspection team will be looking for. | |||
=== Guidelines === | |||
Make sure that your scripts follow the guidelines set here. It will increase the chance that your inspection will pass, and it will help your server overall. | |||
==== Security ==== | |||
Make sure that your scripts are '''secure'''. | |||
Following are a couple of things that you can do to enforce security in your scripts. | |||
* If you are checking for staff flags, i.e. clientr.staff, then make sure that the checks are on the serverside. The first example is good, the second example is bad. | |||
---- | |||
<pre>function onActionserverside() | |||
{ | |||
if (params[0] == "warpto") | |||
{ | |||
if (clientr.staff) | |||
{ | |||
// do warp stuff | |||
} | |||
} | |||
} | |||
//#CLIENTSIDE | |||
function onPlayerChats() | |||
{ | |||
if (player.chat == "warp") | |||
{ | |||
triggeraction(0, 0, "serverside", "weaponname", "warpto"); | |||
} | |||
}</pre> | |||
---- | |||
<pre>function onActionserverside() | |||
{ | |||
if (params[0] == "warpto") | |||
{ | |||
// do warp stuff | |||
} | |||
} | |||
//#CLIENTSIDE | |||
function onPlayerChats() | |||
{ | |||
if (player.chat == "warp") | |||
{ | |||
if (clientr.staff) | |||
{ | |||
triggeraction(0, 0, "serverside", "weaponname", "warpto"); | |||
} | |||
} | |||
}</pre> | |||
---- | |||
* If you are going to have staff flags, then make sure that they are clientr. flags so that the client cannot edit them and take advantage. | |||
* Try to avoid "open-ended" triggeractions. By "open-ended", we mean that you should make sure that your checks are more obscure, or expecting more. The first example is good, and the second example is bad. | |||
---- | |||
<pre>function onActionserverside() | |||
{ | |||
if (params[0] == "firstparam") | |||
{ | |||
player.setLevel2(thislevelname, x, y); | |||
} | |||
}</pre> | |||
<pre>function onActionserverside() | |||
{ | |||
player.setLevel2("levelname", x, y); | |||
}</pre> | |||
---- | |||
==== Efficiency ==== | |||
Make sure that your scripts are '''efficient'''. | |||
Here are some guidelines which can help to promote efficiency. | |||
* Avoid using timeouts on the serverside unnecessarily. It might be better to check for an event instead. | |||
* Avoid using fast times on the serverside at all. A timeout should not be any faster than 0.5 on the serverside. | |||
* Avoid updating a large multitude of clientr.vars at the same time. These all need to be sent to the client. You can use non-prefixed vars if the information does not need to be accessed by the client. | |||
* Try to avoid sending a multitude of triggeractions at a high speed from the clientside. Sending one triggeraction per second should be plenty for whatever use. Any faster is probably overkill. The same effect occurs with updating client.vars. | |||
* Don't use serverr. flags unless you need to. serverr. flags are fed to the client quite often, even when they aren't being used, so only use them if you know that they are values that will be used regularly. For storing values for use on the serverside, using a database NPC might be more effective. | |||
==== Scripting Style ==== | |||
Make sure that your scripts can be '''worked with''', and are '''readable'''. | |||
* Consider divising a sensible scripting format for your scripts and sticking with it consistently between scripts. If you aren't sure of a sensible format, then consider following a scripting format like those set out in [http://forums.graalonline.com/forums/showthread.php?t=61805 Skyld's Script Formatting Guidelines]. | |||
* Avoid mixing old scripting engine and new scripting engine code in the same script. It makes it much harder to understand. |
Latest revision as of 12:42, 7 April 2011
Introduction
So, you've created your playerworld and decided that you want an inspection to check that things are in order, before being moved to Hosted. There are various requirements for playerworlds to pass inspections, and scripting is a quite important part.
Why inspect scripting?
We inspect scripting because it helps to protect your playerworld. There are people out there who will take advantage of the Graal client, and careful scripting methods can help to reduce the amount of damage that can be done by using client hacks and such.
There are a few things which will be looked for upon a scripting inspection, and in this article, we'll cover the basics of what the inspection team will be looking for.
Guidelines
Make sure that your scripts follow the guidelines set here. It will increase the chance that your inspection will pass, and it will help your server overall.
Security
Make sure that your scripts are secure.
Following are a couple of things that you can do to enforce security in your scripts.
- If you are checking for staff flags, i.e. clientr.staff, then make sure that the checks are on the serverside. The first example is good, the second example is bad.
function onActionserverside() { if (params[0] == "warpto") { if (clientr.staff) { // do warp stuff } } } //#CLIENTSIDE function onPlayerChats() { if (player.chat == "warp") { triggeraction(0, 0, "serverside", "weaponname", "warpto"); } }
function onActionserverside() { if (params[0] == "warpto") { // do warp stuff } } //#CLIENTSIDE function onPlayerChats() { if (player.chat == "warp") { if (clientr.staff) { triggeraction(0, 0, "serverside", "weaponname", "warpto"); } } }
- If you are going to have staff flags, then make sure that they are clientr. flags so that the client cannot edit them and take advantage.
- Try to avoid "open-ended" triggeractions. By "open-ended", we mean that you should make sure that your checks are more obscure, or expecting more. The first example is good, and the second example is bad.
function onActionserverside() { if (params[0] == "firstparam") { player.setLevel2(thislevelname, x, y); } }
function onActionserverside() { player.setLevel2("levelname", x, y); }
Efficiency
Make sure that your scripts are efficient.
Here are some guidelines which can help to promote efficiency.
- Avoid using timeouts on the serverside unnecessarily. It might be better to check for an event instead.
- Avoid using fast times on the serverside at all. A timeout should not be any faster than 0.5 on the serverside.
- Avoid updating a large multitude of clientr.vars at the same time. These all need to be sent to the client. You can use non-prefixed vars if the information does not need to be accessed by the client.
- Try to avoid sending a multitude of triggeractions at a high speed from the clientside. Sending one triggeraction per second should be plenty for whatever use. Any faster is probably overkill. The same effect occurs with updating client.vars.
- Don't use serverr. flags unless you need to. serverr. flags are fed to the client quite often, even when they aren't being used, so only use them if you know that they are values that will be used regularly. For storing values for use on the serverside, using a database NPC might be more effective.
Scripting Style
Make sure that your scripts can be worked with, and are readable.
- Consider divising a sensible scripting format for your scripts and sticking with it consistently between scripts. If you aren't sure of a sensible format, then consider following a scripting format like those set out in Skyld's Script Formatting Guidelines.
- Avoid mixing old scripting engine and new scripting engine code in the same script. It makes it much harder to understand.