Tips for VX Scripters

Due to my recent lack of posted scripts, I've decided to compensate by giving budding scripters like myself some tips you ought to know about using the amazing RGSS2 engine. This guide won't necessarily teach you how to script, but will help you a lot if you already know a little bit. So, let's begin.

IMPORTED SCRIPT CLAUSE

This is one of the most useful things you can do when writing a script, mainly for compatibility patches and versions in other scripts. It's simple, but incredibly effective.
The steps:

• Use the name of your script. For instance, most scripts around have a name the scripter specified for it. They might include their own name or a series of random numbers so there's no chance of it getting mixed up with a similar script.
• Come up with a unique style of the clause if you want. I myself have thought of about 4 ways of writing the clause, but I always stick to the same stock one. It's a very simple clause, and it can be expressed in a large variety of ways.
• Come up with another word for "imported". You don't really have to do this, though. It can be any word, it can even be your name. This is another way of preventing a mix-up with another script. For instance, Jet uses

Code: [Select]

unless $engine_scripts.nil?
  JetEngine.active("Script Name", version)
end

for scripts in his collection, the Jet Engine.

And now, the clause itself.

Code: [Select]

$imported = {} if $imported == nil
$imported["Script_Name"] = true

Yes. It's that easy. However, as mentioned there are many, many ways of saying this. Experiment to come up with your own if you feel inventive enough.

Code: [Select]

if $imported == nil
  $imported = {}
end
$imported["Script_Name"] = true

Is another way I thought of writing it, just now.

Why should I use this?

To be perfectly honest, the reasons aren't that strong. The one that stands out, however, is the fact that maybe your script is incompatible with someone else's or even another of your own scripts. They want to write a compatibility patch included in their script, but it changes something they don't want to change unless the user has both of your scripts. If that's the case, they can use

Code: [Select]

if $imported["Script Name] == true

or similar coding to check if your script is running, but only if you have an imported clause in your script.

MODULES

YES. Use these. They are incredibly helpful, but may take a bit of getting used to. They are simple to create and use. To enter editing a module in a script, use:

Code: [Select]

module YOUR_MODULE

It must be one word, otherwise the editor will yell at you with a syntax error and stop you from playing your awesome game. There are ways of working around this if you want to have a more specified module. For example, in my PAC scripts you'll see that most of the scripts operate configuration in two modules:

Code: [Select]

module PAC
  module BATTLE

for example. There is a simpler way of doing this, however.
You can refer to a module with

Code: [Select]

MODULE::CONSTANT/BOOLEAN/WHATEVER

to pass information over from modules to classes or whatever. Doing this, you can refer to a module withing a module in one line, i.e.

Code: [Select]

module PAC::BATTLE

You can even have classes running in modules, i.e.

Code: [Select]

class RPG::State

and other RPG classes can be seen running throughout the default scripts in the help file.
Another handy tip for using modules is the include command. It's simple; once you're working in a class you can use the code

Code: [Select]

include MODULE

to include all constants specified in the module in the class you're working in.

Why should I use this?

Modules are very useful for configuration. In long or scene-changing custom scripts you'll usually see a module in use. Look at the configuration in one of the PAC scripts, for example, and you'll see what I mean.

LABEL YOUR CODE

This isn't necessitous. It's just helpful. Look through some pro scripters' work, like MA's or Cozziekuns' scripts, and you'll see that they label EVERYTHING THEY DO. They don't add comments in on every line, but if they are making a new class, writing or aliasing a method or initializing constants they'll add in a couple lines to let you know. It's very helpful, because it allows for quick finding of features if you want to see how they do them or if you want to edit them.

Why should I use this?

It'll help you find something you want to change, it'll help others if they want to change your script, it'll help budding scripters learn what you're doing and how - it's overall a gold mine of information in just three or four lines of comments. If I see a script that is just code, with no instructions if applicable or labeling of code where necessary evident at all, I will get a little ticked off at the reader. Often, if I'm bored enough, I'll go through and label it myself.

So, there you have it, scripters. Just a couple of tips to make yours and other scripter's lives easier. I have a couple, more hands-on, tips for people new to the scripting scene coming up, so be on the lookout.

Thanks for reading. Your friendly neighbourhood Pacman.