INTRODUCTION TO THE EVENT INTERFACE
Okay, this is my (modern algebra's) Event Commands Tutorial for RPG Maker XP. It will be split into three parts, each dedicated to its respective tab. I know, it is a very innovative approach; nobody would expect such an unconventional approach, but that’s the way it is. Feel free not to laugh at my jokes – they are sparse anyway and generally aren’t going to be very funny. In any case, this tutorial is meant to explain what each command does and thereby allow you to become better at making events do what you want them to do.
There are three basic types of events: Local Events, Common Events, and Battle Events. You are probably most familiar with local events as those are the events you make within a map. These can only be used and referenced in the map they are made in. You can make as many of these as you can squares and you access them by right-clicking on the map in the event layer and selecting the option to create or edit an event. Common events are really cool (in the incredibly nerdy sense) as they can be used in ANY map and so you can use them for all kinds of cool systems, like Day-Night, Crafting, Weather – anything that might need to be used in more than a single map. You get 500 of them. Battle events are made in the troops tab of the database and I will talk more about them in Part III, as that is where all the battle commands are.
Before we go over the commands, I’ll explain to you the local event input interface. Here’s a picture:
These were badly labelled, so I am going to start with 6 and 7 before going on to the rest
6. Name
Pretty simple, this is where you label your event. This is useful if you ever need to reference this event in another event.
7. Pages
As you can see, you can make new pages, copy pages, paste pages, delete pages and clear pages. Essentially, a page represents a new event. You can have up to 99 pages in a single event. Remember, if the conditions are filled for more than one page, it will always run the latest page. So, if you have two pages in an event with no conditions on either, when you activate that event, page 2 will run.
1. Conditions
This is what determines whether or not the event will run when activated. As you can see, there are 4 possible conditions: Two Switches, a Variable, and a Self-Switch. All of these are discussed in PART I.3, but a brief summary:
Switches have two positions: ON and OFF. As well, you, the user, define through events when each switch is ON or OFF(you have 5000, and you can label each individually). If you check the box in the event interface next to switch, then this event will only run if the switch you specify is ON.
Variables are like switches, except they have more than just the two positions ON and OFF. They have up to 19999999 positions, each represented by a value from -9999999, …, 9999999. If you check this box, then you have to specify a number and if the value stored within the specified variable is greater than or equal to the number you specified, the event will run.
Self-Switch: Like switches, but are only useable within the event and you can only make 4 of them. So, if a Self-Switch is set to A within an event, then it only affects that event. In other words, for any other event, nothing has changed.
For example, if you have page 1 set to run only if Switch 1 is ON and page 2 set to run only if Variable 1 is greater than 10, then if Switch 1 is OFF and Variable 1 is less than 10, neither page will run when the event is activated. If Switch 1 is ON and Variable 1 is less than 10, page 1 will run when the event is activated. If Variable 1 is greater than 10, page 2 will run when the event is activated REGARDLESS of whether switch 1 is on or not. And remember, you can stack conditions. So, you can make it so that a page will only run if both Switch 1 and Switch 2 are ON, and Variable 1 is greater than 10, and Self-Switch A is ON.
2. Graphic
This allows you to set a graphic for the event. You can set a different graphic for each page. To do so, merely double-click the box and it will allow you to choose a graphic from the character sets you have imported, as well as from the map tileset that your event is situated in.
3. Movement
This allows you to set up speed, frequency, and path. The path determines what your event is doing. There are four options: Fixed, which means the event does not move. Random, which means the event moves in an arbitrary manner, Approach, which means the event moves towards the hero, and Custom, which allows you to define how the event moves using the move command interface (which will be discussed in Part II). Speed defines how quickly the event moves and frequency defines how often the event moves per second. For each there are six options, Slowest, Slower, Slow, Fast, Faster, Fastest.
4. Options
This is basically how the event interacts with the player. You can have as many of these checked off as you like. Move Animation means that when the event is moving, it will go through and show animation. So if it is a person, it will show their legs moving only when they walk somewhere. Stop Animation means that the program runs through the animations even when the event is not moving. Think Shining Force 2. This is most useful for some of the support graphics, like fountains or smoke. Direction Fix means that this event will always be facing one direction. When this is not checked, the event will turn towards the hero if the player presses the action key. This essentially disables that function. This is useful for treasure chests and other graphics whose animations shouldn’t change no matter where the player is at the time of interaction. Through allows the player and other events to occupy the same square as this event. It also allows the event to ignore impassable terrain, like water or cliffs. Always on Top means that this event ignores all other layers, or rather, that the event has priority over all other layers. This can be useful for birds and flying objects, etc…
5. Trigger
This is where you determine what it is that activates the event. You can only select one option. Action Button means that when someone walks up to the event (or on to it if the event is set to through) and presses Button C (Enter, Space by default), the event will activate. Player Touch means that the event will activate if the player occupies the same square (or at least tries to if the event is not on Through). So if you are standing next to the event and then press the arrow key to move towards the event, it will activate. Event Touch is similar to Player touch, but where player touch runs only if the player walks into the event, event touch runs even if it is the event which runs into the player. This is especially useful if you don’t want your combats to be random and so you want events to represent battles. Autorun means that the event will run immediately upon entrance into the map (so long as the conditions are fulfilled. If they aren’t it will run immediately upon their fulfillment). Be careful with these, as an autorun stops all other events from running. Parallel Process is functionally the same as autorun, but it does not stop other events from occurring at the same time (hence the name).
That is the interface for a local event. It is slightly different for common events and battle events, but to unsuccessfully prevent boredom I will cover common events in the Preface to Part II and battle events in the preface to Part III. Now, on to the main event! (pun soss for the win!)
PART I
Okay, so below is a picture of Tab 1, illuminated with dark, foreboding colours.
Alright, let’s start with 1.
1. The Input Commands
Okay, so I cheated a little in the naming of them, they aren’t all input commands, however I feel it is justified because about half of them are. You’ll see what I mean.
SHOW TEXT
This is the most important command in all event land. That being said, it is kind of self explanatory and I am sure that if your interest in RMXP is piqued enough to be reading this, you probably already know what it does. For the sake of completion however:
This command opens a box into which you can type whatever you want to appear on the screen. There are a few commands you can use to make it look pretty.
\v[n] Will display the value in variable number n.
\n[n] Will display the name of actor number n.
\c[n] Displays the characters that follow in colour number n. (1 - 7)
\g Displays money window in top right corner.
\\ Will be replaced by the '\' character.
If you want to see what your message will look like in-game, just press F2
If you get an Advanced Messaging Script, you will be able to use more commands, but these are the basic ones that you can always use.
SHOW CHOICES
This is a very important function which allows the player to input his desires … assuming the entirety of his desires can be compressed into a few, one line choices. You write whatever you want into the slots. It then goes to the event commands and you can put whatever you want under each choice and when the player selects that choice, it will run only what’s underneath that choice and then skip to whatever is underneath the Show Choices Branch. This is what it looks like:
The reason I show a picture is to draw notice to the “When Cancel” Handler on the right. You’ll want to change this every time you want more choices than the simple “yes” or “no”, because this determines which choice is selected if the player presses the cancel key (ESC by default). If it’s on disallow, the cancel key does nothing; if it’s on any of the choices, that particular choice is selected; and if it’s on branch, then it will create a handler for when the person presses the cancel key, and you can put whatever you’d like to happen when they do that, much like you do with the other options.
INPUT NUMBER
This command is heavily based upon variables, so refer to the section on variables if you do not understand what they are. It basically lets the player input a number (at the bottom of the preceding message) and it stores this number as a variable. It allows you, the game-maker, to specify a number of digits, and then the user can choose any number which has that number of digits. For example, if you allow 3 digits, then the player can choose any number from 0 to 999.
Related Commands: Control Variable; Conditional Branch
CHANGE TEXT OPTIONS
This allows you to change where the text appears on the screen and whether you want it in a box. This is useful because the effect of a scene can be lost entirely if the text is blocking out all the action.
BUTTON INPUT PROCESSING
This command is also heavily based upon variables, so refer to the section on variables if you do not understand what they are.. Basically, there are a few buttons which correspond to keys on the keyboard. You can access this menu by pressing F1 in Test Mode:
Basically, what button input processing does is it allows the player to press a key, and then it stores the button “number + 10” in a variable. So, what happens if you put it in and the player presses Space? Basically, Space corresponds to C, which is Button 3, so it will store the number 13 in the variable of your choice. You can also input the keys DOWN, LEFT, RIGHT, and UP, which are 2, 4, 6, and 8 respectively. Be sure to identify what is happening to the player as well, because unlike Input Number, no hints are given to the player that he should input a button. This is probably the least broadly applicable function of all the event commands, since there already is a function of the conditional branch which responds to which button is being pressed.
Related Commands: Control Variable; Conditional Branch
WAIT
This one is self explanatory, but you should note that it counts in frames, not seconds. In general, it is about 20 frames per second in regular mode and approx. 40 frames per second in smooth mode – you can check by pressing F2 while test playing, and you can shift between regular and smooth by pressing F1. Also note that it applies only to the event it is called in. Any other events can still run normally.
COMMENT
This is like the Show Text option, but the event skips over it in the game (ie, it doesn’t show up when playing the game at all). You can use it for complicated events to remind yourself what you are doing at any given time. Alternatively, if you are making a demo of an event, you can use it to show other people what you are doing.
2. Let’s call these the “Control” Commands.
If you haven’t realized yet, my naming of these groups is almost entirely arbitrary, as evidenced by the fact that only 3 of the “Input” Commands actually require input from the user.
CONDITIONAL BRANCH
Very important command necessary for practically any complicated event, and incredibly useful even for simple ones, this is probably one of the most useful commands in the game. What this does is it checks a specified condition (a test), and, if true, executes a certain event, and if false, can either execute a different event or it can be used to bypass an event. For example, if you want someone to say “You will die in a fire” if the player is pressing the A button, and you want them to say “Nobody loves you” if the player is not, then the screen looks like this:
And the screen where you set up the tests is composed of four tabs and it looks like this. If you don’t want anything to happen if the test is not true, then just check off the box in the bottom left corner of the setup screen, circled in green.
It’s a bit small, but I’ll just briefly go over each possible condition:
Switch – you can specify ON or OFF, and the command will execute if the switch
is on, or off. Refer to I.3.1
Variable – variables store values, and this command will execute dependent on
the relation between that variable and any other number (or other
variable) you specify. The relations allowed are: Equal to, Not Equal to,
Greater than, Greater than or Equal to, Less than, Less than or Equal to.
Self-Switch – same operations as a switch, but only available within the event
which is using the conditional branch. These will be discussed later.
Timer – Assuming you have a timer going, this condition checks what time is left
on it, and you can make something occur if it is greater than or less than
your specified time. For example, if you set the conditional branch to
Timer: 1 min 0 sec or less, then once the timer hits 1 min, the specified
event will occur.
Actor – This option allows you to run events based on what a specific character is
doing, wearing etc: anyway, a list:
In the Party: self-explanatory. It runs the event if the character is in the party. Very useful for games with optional party members.
Name Applied: Essentially, if you name your hero a certain name, then the event will run. For games where you enter Char Name, this can be used to enable cheats and stuff. For example, if the player inputs GOD mode as his char name, you could have an event give him max stats. More practically, it can be used in conjunction with a dummy hero and the Name Input Processing Command to represent passwords. In other words you can make a hero in the database with no graphic and no stats, and use him as the Name Input and the Password test. I’ll go into this further if I ever get to Name Input Processing, which may never happen as I take 10 lines just to write on a single option within an option of an event command.
Skill Learned: If the specified hero knows the specified skill, the event will run
Weapon Equipped: If the specified hero has equipped the specified weapon, then the event will run.
Armour Equipped: If the specified hero has the specified armour equipped, then the event will run.
State Inflicted: If the specified (How many more times can I use the word “specified” before people start to get annoyed?) hero has a specified state inflicted, the event will run. For example, you could use this to have the option of Cure only available at the temple if your character needs to be cured
Enemy – This is really only useable in combat, and if you use it in the battle section you will see that it labels each enemy for your convenience. You can have it test one of two things:
Appeared: One of the options for setting an enemy in the troops section of the database is to “Appear Halfway”. You can have an enemy appear at any time you like through one of the battle events located on the third tab. This condition tests to see if they are in the battle yet.
State Inflicted: This works the same way as the one for the actor, but instead checks the enemy’s state
Character – This one checks the direction a specified (sweet! The word “specified” saves the day once again!) event is facing. You can use any event that is in the map, and you can use the player as well)
Gold – You can specify an amount of gold and have the event run if the player has less or more (you can choose which) than that amount.
Item in Inventory – This checks if you have the specified item in your inventory and is true when you do and false when you don’t
Weapon in Inventory - This checks if you have the specified weapon in your inventory and is true when you do and false when you don’t
Armour in Inventory - This checks if you have the specified armour in your inventory and is true when you do and false when you don’t
Button Pressed – Remember that picture I showed you in “Button Input Processing”? That screen is where you set up what key each button corresponds to. The keys that the program recognizes input from by default are: A, S, D Q, W, Z, X, C, Space, Enter, ESC, Num0, Shift, and of course, the arrow keys. You can find scripts which allow more keyboard input. So, each of the buttons, labelled A, B, C, X, Y, Z, L, R corresponds to one or more of these keys (also set up in that screen I showed earlier (called by F1 in Test Play)). SO if you set Space to A, then Conditional Branch: A is being pressed means that if the player is pressing Space, the test returns true and the event is executed.
Script – As all script commands are, this can be very useful if you know scripting and entirely useless if you don’t. In any case, this essentially allows you to test ANY condition, as long as you know the proper syntax. For example, if you need 3 of some item for a quest, then you could write in as the condition “$game_party.item_number(<item_ID>) >= 3”, and that would check how many of that item you have and return true if you have at least 3.
Related Commands: Control Switch; Control Variable; Control Self-Switch; Control Timer
LOOP and BREAK LOOP
These two are intricately related and so they go together. They do exactly what you expect them to do, Loop makes an event repeat and Break Loop ends the loop. You MUST have something to break the loop eventually, or else you get stuck in an infinite loop, and those are bad. The best way to break a loop is to make a conditional branch which returns true once the event has run a sufficient number of times. For instance, if you wanted the party to have at least 200 gold at a certain point in the game, but you don’t know how much they have in the first place, you could make a loop which gives them the exact amount of gold they need if they don’t have enough or nothing if they have more then enough. It would look like this:
Loop
Conditional Branch: Gold 200 or more
Break Loop
Branch END
Change Gold +1
Repeat Above
Loops can be far more useful than this of course, and are ideal if you need your event to run more than once.
EXIT EVENT PROCCESSING
This does exactly what it says. If the event runs into this command, then all event commands below it will not be run. For this reason, this command should only be used inside a conditional branch, i.e. if you don’t want the latter portion of the event to run unless some condition is fulfilled. For example, the second text command in the following event will not run unless Aluxes is not normal:
Text: Hello, do you need something?
Conditional Branch: Actor Aluxes is Normal
Exit Event Processing
Branch END
Text: It seems like you have contracted syphilis
This is not a very useful command in my opinion, since it is only useable if nothing else is supposed to happen if a test is fulfilled, and furthermore, it can just as easily work if you were to put what was supposed to happen in the else of the Conditional branch.
ERASE EVENT
Another obvious one, this gets rid of the event. In other words, if you put this at the bottom of an event, than this event will only run once. However, if you leave the map and then come back, you will be able to once again run the event, so this command does not replace the self-switch.
CALL COMMON EVENT
Another useful one, this allows you to select a common event to run at this point in your event. It essentially takes whatever is in your common event and places it into your event at the place you call it. So, if you have, for example, the example I used for loops as a common event, then using this command will call that event and place it into your event. So, if you have this event:
Text: I’ll give you as much money as you need for the inn.
Call Common Event [Loops Example]
Text: There, that should do ya.
This would execute:
Text: I’ll give you as much money as you need for the inn.
Loop
Conditional Branch: Gold 200 or more
Break Loop
Branch END
Change Gold +1
Repeat Above
Text: There, that should do ya.
LABEL and JUMP TO LABEL
These can be used similarly to loops, but I prefer them because they are more broadly applicable. Essentially, they work by naming a label and setting it anywhere within your event. Then, you can use the jump to label command to immediately go to that label. This can be especially useful if, for example, you can select two options that both lead to the same result. That might be confusing, so I will show you how it works:
Conditional Branch: Hilda is in Party
Text: Who do you want to play the minigame?
Show Choices: Aluxes, Hilda
When Aluxes
Jump to Label: Aluxes Plays
When Hilda
Text: Hilda: Oh, all right, I’ll do my best
Branch END
Else
Label: Aluxes Plays
Text: Aluxes: All right! I’m gonna rock this thing!
Branch END
All right, so what that event would do would be if you have Hilda in your party, then it would allow a choice for who gets to play the minigame. Otherwise, Aluxes plays the game by default. Since there are two ways to get to the same event: i.e. you get the message “Aluxes: All right! I’m gonna rock this thing!” if Hilda is not on your team or if she is and you select Aluxes, then without labels you’d have to repeat the same event commands under both possibilities. But, with labels, you are able to write the event only once. This is not particularly useful when there is only one line to the event and it is easy to repeat, but for larger events this comes in handy. Note: You can also exit a loop with a Jump to Label Command as long as the Label you are jumping to is not within the loop.
Hmm… On to 3. I guess they can be called the Control Commands… Damn! I called 2. the control commands… well whatever, ummm… Change Commands will do!
3. Change Commands
CONTROL SWITCH
Okayyy, a lot of people have trouble understanding switches, but that’s a good thing for me, because that means that there are already a bunch of tutorials out there for you guys. So, I will try to be brief and concise, but just in case, here’s a link that might help you if I am not clear enough:
http://www.creationasylum.net/index.php?showtopic=6 Anyway, to put it simply, a switch is like a light switch. If it’s on, the light is on, and if it’s off, the light is off. The function switches serve in RMXP is similar, but as you saw earlier in my explanation of conditional branches, they are used to determine when certain events should run. The Control Switch command is what you use to turn switches on and off. Switches are very important for RMXP as you’ll need them for every event that you don’t want to always occur. That phrasing is little strange, so I’ll use an example. If you want a quest in your game to be, say, some old guy wants you to go kill some old woman and he says he’ll give you a reward. Obviously, you can’t have the old man give you the reward before you complete the quest, and so this is where switches come in handy. Basically, you’ll have to make the old man event have two pages – one where he gives you the quest and one where he gives you the reward. On the page where he gives the reward, condition it on Switch: [Old Hag murdered in Cold Blood] is ON. Now all you have to do to have it switch to this page is after you’re finished doing the foul deed, have a Control Switch command activate which turns the switch [Old Hag murdered in Cold Blood] ON, and you’re done. You have successfully rewarded your heroes for murdering a helpless old lady. Don’t worry, she’s old anyway. If you don’t know what I mean by pages and conditions, refer back to the section on the event interface in the Introduction.
Okay, so that works, but why does it work? Basically, whenever you activate an event, the program runs through and tests every condition that you specify need to be met for that page to be run, and then it executes the latest event which has all the conditions fulfilled. So when you talk to the old man, it tests whether or not the Switch [Old Hag murdered in Cold Blood] is ON. The first time, this test will return false because that switch is not on. In fact, it will return false every time you try to talk to him before killing the old lady, and so every time page 1 will run. Once you kill the old lady, however, the switch [Old Hag murdered in Cold Blood] is turned ON, so now whenever you talk to the old man, the conditions on the second page return true and so the reward page runs. Now, you probably notice that this event is not complete, as if you have understood all this, you will understand that this second page will run every time you speak to the old man, and thus, you will get multiple rewards. You can use another switch to fix this, but in this case, self-switches are ideal, and so we will return to this example when we cover self-switches.
You’ll notice that in the interface for switches, there is an option for single or batch. Single applies the operation (ON or OFF) to a single, specified switch. Batch applies the specified operation to ALL switches within a specified range. For the most part, what you’ll be using is single, but batch sometimes comes in handy, most often with turning things off after a complicated event which required multiple switches. Keep in mind when you are using batch that you have to want ALL of the switches within that range to have the same operation applied to it. You get a total of 9999 switches to use in each project.
Related Commands: Conditional Branch
CONTROL VARIABLE
This is another thing that a lot of people don’t know how to use. They justify this by saying it’s primary use is as a condition, and since they know how to use switches and conditional branches, they say that it is only minimally useful at best. I say, WRONG! WRONG! WRONG! Superman is not coming to save you, and worse still you don’t have a mini Superman to shove pianos at people! Variables are a lot more useful than switches; variables are more efficient than switches in almost every situation and they can even be used in a lot of situations where switches fail. This is one of the most important event commands and even complicated actions can be evented easily through the use of variables. I will try my best to explain them in detail for this reason, and so this is going to be a long chapter.
Without any further ado, I present to you the Control Variables Interface. Get to know it well, for without it your eventing can only be, at best, mediocre:
Okay, as you can see, this has the same interaction as do switches. You can either operate on a single variable or you can operate on a group of variables within a range (with the limitation that you want to apply the same operation to group of variables which are all bunched together. The difference is the amount of operations you can apply to variables. Before we get to that, let me try to explain what a variable is.
A variable stores any value from -9999999 to 9999999. Each one of these numbers is kind of like a position. So, where a switch has 2 positions (ON and OFF), a variable has 19999999 positions. That’s exactly 9,999,999.5 times more positions than a switch. A typical example of the use of variables is as a tool for counting progress in a quest. Let’s go back to the old lady example. Say that the old man doesn’t want you to kill just one old lady, say he wants you to kill three old ladies. Using switches: one switch so that he doesn’t repeatedly give you the quest, ie. Once you accept the quest, he does not continue asking you to do the quest. Then you’d need an additional switch to turn on for each old lady you kill. 3 old ladies = 3 switches. So a total of 4 switches for this quest. With variables, you only need to use one variable and merely use a Control Variables[Old Lady Murder Spree] +1 for each instance where you would normally use a switch.
See, already you should be getting the feeling that variables are awesome. Well Addition is only one of the operations you can use on variables.
The Control Variables Event Command can be split into three distinct parts: Variable, Operations, and Operand. The variable part is where you choose which variable (or variables) you are going to change with this command. The operations part is where you choose which operation to perform (the operations are all listed in the Operations section below). And the operand part is what you are performing the operation with. Essentially this is the number which you are using to effect changes in your variable (example: if you are using the operation add, this is the number that you add to the variable). You can make the operand a number of different things, which I will explain in the Operand section.
Operations
I am going to go over the operations now, and to make things easier, let’s say we are working with a variable called [Test]. Note, however, that this is an arbitrary name. All operations work the same way on any variable.
Set: This basically means “gets the value:” and then in the operand section you choose what value it gets. [<variable>] = [<operand>]So if you choose the constant “3” as your operand, then the variable [Test] = 3. By default, before any operations are applied to a variable it is set to 0.
Addition: This adds the operand to the value currently stored in the variable. [<variable>] = [<current value stored in variable>] + [<operand>]. The current value in [Test] is 3, so if we use the addition operation with constant 2, then [Test] = [Test] + 2, so [Test] = [3] + 2 so [Test] = 5
Subtraction: This subtracts the operand from the value currently stored in the variable. [<variable>] = [<current value stored in variable>] - [<operand>]. The current value in [Test] is 5, so if we use the subtraction operation on [Test] with the operand being a constant 3, then [Test] = [5] – [3] = 2. So [Test] is now storing the value [2].
Multiplication: This operation multiplies the value currently stored in the variable by the operand. [<variable>] = [<current value stored in variable>]x[<operand>]. Let’s say our operand is 4, then using this operation on [Test] = [2]x[4] = 8. [Test] is now storing the value [8]. Now, I will state this in a slightly more complicated way in the hopes that it will help you better understand the next operation, mod. One thing to note about this operation (about all operations really), is that if the result of the operation is greater than 9999999, then the value stored in the variable defaults to 9999999. So if you were to try to multiply [Test] by 2000000, then [Test] = [8]x[2000000] = 16000000, but the variable [Test] receives the value [9999999].
Division: This operation divides the value currently stored in the variable by the operand, and then rounds down to the nearest integer. [<variable>] = [<current value stored in variable>] / [<operand>]. So, with our variable [Test]. It’s current value is 8, and say we take operand 4, then [Test] = [8] / [4] = 2. Keep in mind that it will round down, so if we took the operand 5, [Test] = [8] / [5] = 1.75 = 1.
Mod: I suspect that most of you have no idea what this last one is, so I will take my time explaining it. Mod calculates the remainder after division. Division (a / b) can be written in this form: a = bq + r, where a is the number you are trying to divide, b is the number that is dividing it, q is an integer such that bq is less than or equal to a and that b(q+1) is greater than a, and r is the remainder. You’ll probably benefit more from an example. Let’s say we are trying to divide 8 by 5. [8] = [5]x[1] + [3]. The number mod is concerned with is the remainder, so you can say 8 mod 5 = 3. Another example: what is 7 mod 3? [7] = [3]x[2] + 1, so 7 mod 3 = 1. Hopefully you understand this, but in any case I can’t spend any more time on it so I will just give one last example in terms of RMXP variables. The value currently stored in [Test] is 8. SO, if we apply the operand 6, then [8] % [6] => [8] = [6]x[1] + [2], so [8]%[6] = 2. The value currently stored in [Test] is now 2. Notice also that q (in this case 1) is the value you get when you divide 8 by 6 in variable operations.
Operand
Constant: This is just an integer from -9999999 to 9999999. Pretty simple.
Variable: This allows you to select another variable (or the same variable) as the operand. In other words, if we have two variables, Test 1 and Test 2, and Test 1 = 4; Test 2 = 5, then we could use [Test 1] as the variable we are changing and [Test 2] as the operand. As far as usage goes, [Test 1] = [current Test 1] + [Test 2] and so [Test 1] = 4 + 5 = 9. Note that it is still only the variable you specify in the variables section that is changed, [Test 2] (the operand) is still only equal to 5.
Random: This takes a single number from a range that you specify and uses it as the operand. Each number from within the range is equally likely to be chosen. So, if you specify a range from 1 to 3, then there is approximately a 33.3 % chance 1 will be chosen, a 33.3% chance 2 will be chosen, and a 33.3% 3 will be chosen. This is useful for anything that has no set outcome. For example, you could use it for dice or anything that requires some randomness.
Item: This works by specifying an item in your inventory. Then, the operand takes the value of the number of that item you have in your inventory. For example, if you specify potions, and your party has 2 potions in their inventory, then the operand will take the value of 2. If the party has 3 potions, then the operand will take the value of 3. etc…
Actor: For this, you have to specify both the player character(people you can have in party) and the parameter. You can choose any character and then from that you can choose any of the following parameters which correspond to that character: Level, Exp, current HP, current MP, max HP, max MP, Strength, Dexterity, Agility, Intelligence, Attack, Physical Defence, Magical Defence, and Evasion. The operand takes the value of the number corresponding to the parameter. For instance, if Aluxes’ Strength is 435, then the operand takes the value 435. Note, max HP means max HP for level, and current HP means max HP – the damage he has received.
Enemy: This is a command meant exclusively for combat. When you are not in combat, it takes the value 0. When you are in combat, it has all the same parameters as actor has, but they correspond to the enemy you specify.
Character: This can apply to any event on the map and the player, just specify it in the first slot. Then, you can specify any of six parameters: Map X, Map Y, Direction, Screen X, Screen Y, and Terrain Tag. Map X is the x-position of the specified event. X goes from left to right, from zero to (map width – 1). Y goes from top to bottom, from zero to (map length – 1) That’s probably hard to understand so I’ll post a screenshot: Format: x coordinate, y coordinate. Map width = 4, map length = 4
Screen X and Screen Y are similar to Map X and Map Y but are determined in pixels, not squares. Each square is 32 pixels x 32 pixels, so basically Screen X = 32x(Map X) and Screen Y = 32x (Map Y). Direction assigns a number to the direction the event is facing. As I stated earlier, Down = 2, Up = 8, Left = 4, and Right = 6. So if the event is facing down, the operand takes the value 2, etc…
Terrain Tag refers to the Database. If you look in the database under tilesets, you can set tiles on a map to have tags from 0 to 7. This command takes the tag from the tile the event is standing on and uses it as the operand.
Other: These are all pretty self explanatory. Map ID: operand takes the value of the Map ID #. Party Members: operand gets the number of characters in your party. Gold: operand gets amount of gold party is currently holding. Steps: operand gets amount of steps party has taken. Play Time: operand gets number of seconds the game has been played for. Timer: operand gets number of seconds left on timer. Save Count: Operand gets # of saves.
Some of you may still have doubts. You are looking at this long, boring, mostly incomprehensible section and thinking to yourself, “sure, it was sort of useful for that quest example, but I still think switches can do everything that variables can… WRONG!!! To show you some of the uses for variables, I will build upon my previous example. In reality, if you were an old man who wanted a few old ladies murdered, would you really ask some random stranger who walked into your house? Probably not. For this reason, maybe you want an alignment system like in Fable. Maybe you only want the old man to ask you if you are sufficiently evil that he believes you will do it. This can easily be accomplished through the use of a single variable. All you have to do is make it so that whenever you do a good action, your alignment variable increases and whenever you do an evil action, your alignment variable decreases. To demonstrate how this would work: Let’s say we base the system on a scale from -5000, …, 5000. 5000 is the maximum good and -5000 is the maximum evil. Killing an old lady is fairly evil, so let’s say that subtracts -250 each time you do it. You can easily make it so that you are only granted the quest if your alignment variable is less than -1000 by putting it into the conditions. Maybe also, you don’t want the old man to say the exact same thing every time you talk to him (you use random for this). So now, our events look like this:
OLD MAN (for all: Trigger: Action Key; Graphic: OLD MAN)
Page 1:
Conditions: None
Event Commands:
Text: This day is filthy; rotten! I have a hankering to murder some old women! You with me?
Show Choices: Yes, No
When Yes
Text: There be a three old hags in this city that need akilling me hearties. I am a
pirate! Go now and find them. They do be in shacks near the ocean I say! I give
ye a share of the plunder matey!
Control Variable [1. Pointless Killing!] + 1
When No
Text: Useless Landlubber
Branch End
Page 2:
Conditions: Variable [2. Alignment] is -999 or more
Event Commands:
Control Variable [3: random talking]: Random (1,…,3)
Conditional Branch: [Variable [3: random talking] = 1
Text: Ah, the fluttering of the butterflies puts this old, weary heart at rest.
Branch End
Conditional Branch: [Variable [3: random talking] = 2
Text: We are blessed with fine weather this day.
Branch End
Conditional Branch: [Variable [3: random talking] = 3
Text: AH! Were only my wife alive to feel this Spring air.
Branch End
Page 3:
Conditions: Variable [1. Pointless Killing] is 1 or more
Event Commands:
Text: What are ye layin’ aboot here fer. Go kill them ladies by the wharf!
Page 4:
Conditions: Variable [1. Pointless Killing] is 4 or more
Event Commands:
Text: Aye, ye done well fer a useless layabout landlubber!
Change Gold: + 1000
Text: You got a 1000 gold!
Control Variable: [1. Pointless Killing] +1
Page 5:
Conditions: Variable [1. Pointless Killing] is 5 or more
Text: Ye done well laddie. I’ll make use of yea agin some day I reckon.
Each OLD HAG (for all: Trigger: Action Key; Graphic: OLD LADY)
Page 1:
Conditions: None
Event Commands:
Control Variable [3: random talking]: Random (1,…,3)
Conditional Branch: [Variable [3: random talking] = 1
Text: You seem to be a fine young gentleman
Branch End
Conditional Branch: [Variable [3: random talking] = 2
Text: I hear there is a nice old man in central who loves the Spring
Branch End
Conditional Branch: [Variable [3: random talking] = 3
Text: I was once the Queen of Scotland
Branch End
Page 2:
Conditions: Variable [1. Pointless Killing] is 1 or more
Text: Ay, why is your sword drawn?
Battle Processing: Helpless Old Lady
Control Variable [1. Pointless Killing] + 1
Control Variable [2. Alignment] - 250
Control Self Switch: [A] ON
Page 3:
Conditions: Self Switch A is ON
NO GRAPHIC
NO EVENT COMMANDS
That took a lot of space but I thought a prolonged example would help get the point across: variables are better than switches. There are many, many things which variables can do which I did not include in the example. Explore them a little and almost every event you can think of will become simpler. In any case, if you’ve read through all that and still don’t understand how to use variables, then check out these tutorials:
http://rmrk.net/index.php?topic=14159.0 (for 2k3, but the basics are the same)
http://yamisiterawr.com/variables.php (explains what a variable is really well)
Related Commands: Input Number; Button Input Processing; Conditional Branch; Change Gold; Teleport; Show Picture
CONTROL SELF-SWITCH
Self-Switches are a lot like switches, except they can only be used within a single event, and you can only use 4 within each event (labels A, B, C, D). So, they function exactly as switches do except they cannot affect other events, only themselves. So if you turn ON self-switch A in one event, then Condition: Self-Switch A is ON will ONLY be fulfilled within that event, and not in any other event. Now, I promised that we would return to the example we covered to demonstrate switches. In that example, we ended up with an overly generous old man. He just wouldn’t stop giving your party a reward! In that case we are looking for a specific kind of switch: we need it to stop this event from recurring, but we do not need it to affect any other events in the game. Sound familiar? This is the self-switch. All we need to do is place a self-switch at the end of the second page of that event which turns [A] on. Then, we make a new page conditioned on this self-switch A and in it we have the old man thank your party for your hard work. Popular uses for the self-switch are with treasure chests. It is very easy to make the chest give your party an item and then turn on a self-switch so that the chest no longer gives that item. And all without wasting one of your precious 9999 switches.
Related Commands: Conditional Branch; Control Switch
CONTROL TIMER
It’s nice when they are self-explanatory. This command starts up a timer which counts down from the time you specify. You can specify anything from 0 min, 0 sec to 99 min, 59 sec. You can also use this command to stop the timer at any time of your choosing. To have the current position of the timer interact with your events, use conditional branches.
Related Commands: Conditional Branch
CHANGE GOLD
You use this command to give your party gold. It’s pretty straightforward. You can either increase (a reward) or decrease the party’s gold (payment). Furthermore, the number of gold given or taken can either be set as a constant, or you can change the party’s gold by the value stored in a specified variable. So, if there is a set reward, say 1000 gold, then you can just specify 1000 gold as a constant. However, if the amount of gold you get for a quest is a random number between 500 and 650, then you could just set a variable [Reward] and use Control Variable [Reward] Random (500, 650) and then in the Change Gold command, just specify the increase by the variable [Reward]. Conditional Branches come in useful for decreasing gold: you can make sure you have enough gold by conditioning on “greater than or equal to” the amount of gold you want to take away.
Related Commands: Control Variable; Conditional Branch
CHANGE ITEMS / WEAPONS / ARMOUR
These work the same way Change Gold does, but I just felt I should separate them arbitrarily. In this you specify three parameters: the item, whether you are increasing or decreasing, and the number of that item you wish to take or give. Analogously to Change Gold, you can specify the number as either a constant or a variable. As well, conditional branches can be useful when you are trying to take items away from the party.
Related Commands: Control Variable; Conditional Branch
CHANGE PARTY MEMBER
This command serves the very important function of allowing you to add / remove characters from your party. It is very easy to use. Basically, it allows you to select a hero, and then you choose whether to add him to the party or remove him from the party. One thing that might require explanation is the “initialize” check box. This only applies to when you are adding a hero to the party, and basically what it does is that when it adds the hero to your party, it takes all the hero’s information directly from his database entry (i.e. his initial level, HP, SP, Str, etc…). Basically, you should only have this box checked the very first time you add a hero (I don’t even think you need to have it checked then either, but it won’t screw everything up if you do). If this is the second time you are adding that hero to the party (i.e. he was in your party previously, but then you removed him, and now you want him in your party again), do NOT check the box initialize, as all the levels he gained in his previous time with you will be rendered null. As a general policy, just uncheck the box when you add your party members.
4. The System Commands
These commands allow you to change the settings of your game a little bit. Of all the arbitrary names I’ve randomly assigned so far, I think this is probably the most apt.
CHANGE WINDOW SKIN
The window skin is basically the background for well… windows. It is this:
That may not be very descriptive, but window skins are graphics like this which can be applied to your game. This shows up everywhere you have text, in your menu, in battle, basically everywhere except on the maps themselves. This picture is of the one that comes default with RMXP, but if you search around you will soon find that many avid RPG makers have decided to make their own skins and are sharing them. You can set the window skin in the systems tab of the database. But, if you ever want to change it in-game, then this is the command to use.
CHANGE BATTLE BGM / BATTLE END ME
In case you don’t know, BGM stands for background music and ME stands for Musical Effect. The Battle BGM is the music playing during battle and the End ME is the music that plays at the victorious conclusion of a battle. Both of these are originally set in the System Tab of the Database, but these commands allow you to change them in game
Related Commands: the Sound Commands
CHANGE SAVE / MENU ACCESS
Damn, these commands are all boring. Blue is way too cool a colour to waste on these lame commands … Anyway, what these commands do are either enable or disable their respective options. Disabling Menu Access means, quite simply, that you are not able to access the menu from the map (you can still call it though through Call Menu Screen). Disabling Save Access means that when you go into the menu, the option to save will be greyed out and un-selectable. Just like with disabling menu access, the save scene can still be called through Call Save Scene. To re-enable either, you use the same command and just choose enable instead.
Related Commands: Call Menu Screen; Call Save Screen
CHANGE ENCOUNTER
As I am sure you know, you set encounters in the map properties screen each time you make a new map. Well, this command allows you to disable and enable these encounters. This is perfect for any map which changes from a place with enemies to a place without them or vice-versa. For example, if zombies are infesting a town, it is your party’s job to rid the town of them. After you finish the quest, you obviously do not want zombies to still randomly attack you in the streets, so you use this command to disable encounters.
Discord
Light Style