Creation/Inspection/Playerworld Scripting: Difference between revisions

From Graal Bible
No edit summary
 
(One intermediate revision by the same user not shown)
(No difference)

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.