# Gw Temp

## Tutorial - 'Advanced Variables' by slackerboy

An item about RPGMaker 2000 posted on

### Blurb

Bitflags, complex operations, and a scrolling menu!

### Body

INTRO

I'm not going to waste your time with any legal stuff, simple because I don't care where this tutorial ends up. I mean, I wrote it to help people! And you can check out my game site at http://www.gamingw.net/projects/apox/

The first part, BASICS, is for people new to variables. If you already have a good understanding of variables, skip ahead to VARIABLE MANAGEMENT for some more complex ideas. VARIABLE MANAGEMENT explains using variables in depth. The USES section describes applications of some of these nifty little functions.

*Note - You can use whatever variable numbers you want. I just use some as examples.

BASICS

If you*ve taken Algebra, then variables are much easier to understand. A variable is a slot that can hold different values. Lets say we create *var[0001]item#*. We can modify that variable just like we could modify a number like 2 or 3. If we add 8 to 2, we get 10. If we add 8 to var[0001]item#, we get 8 more than whatever it was before that operation.

In rm2k, there*s quite a bit you can do with variables. Firstly, there are 6 operations you can perform. *Set* simply sets the variable equal to a number. *+* adds a number to the variable. *-* subtracts a number from the variable. *** multiplies the variable by a number. */* divides the variable by a number, but it also cuts off the remainder. For example, if you do 5 / 2, you get 2.5, but rm2k cuts off the .5. Lastly, *Mod* divides the variable by a number, but does the opposite of divide; it keeps only the remainder. Doing 5 mod 2 is the same as 5 / 2, except instead of cutting off the .5, it cuts off the 2. So, 5 mod 2 is 5.

VARIABLE MANAGEMENT

Firstly, always name your variables something relevant to their purpose to help you manage them. In rm2k, there are three sections of the variable management screen. the *variables*, *set*, and *operand*.

-The first part, *variable*, is what variable(s) is being modified. The simplest, also most common usage is just choosing one variable in the top box. That one variable gets whatever number added, subtracted, or whatever. However, in this top part, the *choose variables* part, you*ll notice two other options. The second option, range, can be quite useful. If you need to set a lot of variables to *0* because the player is exiting part of your CMS, use range and choose the first and last of the group that is to be modified. Whatever operation you choose to perform on a range of variables, it does the option on each variable individually. So basically, if you want to add 4 to variables 1 to 10, use range with the first number as 1, the second as 10. Also, a much more complex feature is the *variable variable number* option. This, in short, does an operation on variable number var[****]whatever. So rather than using variable number 3, 8, 28, 476, 4532, or any other set number, you can store the variable number into a variable

-*Set* was explained in the last paragraph of the BASICS section, so refer there if you need to.

-*Operand* is a very important section. The operand is the number that the variable is set to or that is added, subtracted, multiplied, divided, or moded by. Most of the time, you will be using *Set* under operand. This simply performs the operation with that number. Like if you have var[0001]item# selected at the top, *** selected in the middle, and *set* at the bottom with 3 in the textbox, var[0001]item# will be multiplied by 3. The operand can also be another variable. It can also be a random number between two numbers. It can also be the amount of a certain item you have or the amount of a certain item you have equipped. It can also be a certain hero*s Level, EXP, HP, MP, Max HP, Max MP, Attack, Defense, Mind, and Agility. It can also be the item number of a hero*s equipped weapon, shield, armor, helmet, and other (accessory). It can also be different event properties, like the map ID number the event is on, its X or Y coordinates, the events X and Y coordinates relative to the current screen position, and a number based on which direction he event is facing. Note that rm2k uses upper left based coordinate tracking. If an event is in the top left corner of the map, his X and Y would both be 0. When making the operand *beyond facing* (facing direction) of an event, look at the numpad on the keyboard. Up=8, Left=4, Right=6, and Down=2. The operand can also be miscellaneous things like the amount of money you have, seconds left on a current timer, the number of characters currently in your party, number of saves, battles, battle victories, defeats, and escapes, and even the current MIDI tick position! Like, a 4/4 MIDI on beat 3 of a given measure would make the number 3.

USES

Now that I've gone in to probably more depth than I needed to, I'll explain some clever things variables can be used for.

Firstly, many event commands in rm2k have variable options. The input number command stores a number in a variable, just as enter password does. You can also change a switch whose number is stored in a variable. You can set a timer to a variable. Also, you can add a variable amount of money or items. with items you can even have a variable to store the item number that you are adding. There are some more useful......... uses, too. With a CBS and/or CMS, it is necessary to store the hero's X, Y, and Map ID into a variable. Also, for cursor movement in a CMS or CBS, you can display or move a picture to certain coordinates that can be stored into variables. Or if you*re using a charset for the cursor, you can use set event place with variables as well.

Enough of that rant. You can find what commands have variable functions. You can set a variable to a random number to make a slot machine quite easily. I once made a little slot machine minigame thingy in which three random numbers were added together. The higher it was, the better an item you got. This was used with fork conditions, of course.

You could also do a simple little mini-game in which you, for some reason, have to press the enter (spacebar) button repeatedly very fast. You would use a parallel process event with an enter command (only boxes checked are *wait til key hit* and *decision (5)*), after which you would have a command that adds 1 to a certain variable. Then, you*d use a fork condition to make sure the variable is greater than or equal to (above) whatever the specified number is, lets say 50. You could use this in conjunction with a timer. When the mini-game starts, start the timer. An auto-start event, with the *timer* box checked and with 0 in both the textboxes, would contain the fork condition to check if the variable containing the number of times you press *decision* and the code that either gives you a prize or tells you that you failed.

Fork conditions with variables and other things are very useful as well. It would be impossible to make a CBS without variables and fork conditions. There are many shortcuts you can take with coding by using variables efficiently. However, it's very difficult to explain that to someone; it's something you pick up after practice.

BITFLAGS

Man, are these useful. Rather than having about 225 switches in my game to track which skills the main character knows, I had 25 variables! Bitflags store different exponential values added together. This was also a *tip of the day* at gaminggroundzero, so I thought I'd acknowledge them for giving me the idea, although they didn*t explain it very well. Lets say I have 7 switches that I use to show what skills my hero knows (S=switch):

S[0001]fire

S[0002]thunder

S[0003]blizzard

S[0004]water

S[0005]quake

S[0006]drain

S[0007]osmose

Since these are switches, they can be either ON or OFF. Instead of using all of these switches, I can store them all (ON or OFF) into a bitflag. A bitflag is one variable. It uses increasing exponents of 2 (it also can use 1):

1 - S[0001]fire

2 - S[0002]thunder

4 - S[0003]blizzard

8 - S[0004]water

16 - S[0005]quake

32 - S[0006]drain

64 - S[0007]osmose

Those are the exponential values assigned to each switch. If I want to turn S[0003]blizzard ON, I would add 4 to the biflag (var[0008]BITFLAG). If I want to turn it off, I subtract 4. This is the same for all the other numbers and their corresponding switch. If I want only S[0003]blizzard, S[0005]quake, and S[0007]osmose to be ON, the bitflag's value would be 4+16+64, 84.

You may be wondering: How do you get rm2k to know which switches are on? Reading the bitflag is not too complicated once you understand the concept and why it works. If I have S[0001] through S[0006] ON, the bitflag value would be 63; LESS than 64, the value of the next switch. When reading the bitflag, you use a series of subtract operations followed by fork conditions as well as setting another variable to the bitflag:

<>var[0009]EXTRA set var[0008]BITFLAG

<>var[0010]EXTRA2 set var[0009]EXTRA

Those first steps simply set two extra variables to the bitflag incase the result of the subtraction turns out negative and so we don*t lose the original value of the bitflag. This is important because right now we are not changing the bitflag, just reading it. As noted earlier, the bitflag would only be greater than or equal to 64 if S[0007]osmose is ON. Let's say you want to show a message if the character already knows the skill. You*d need to read the bitflag:

<>var[0009]EXTRA - 64

<>FORK - var[0009]BITFLAG >= 0

<>message: You know osmose.

<>var[0010]EXTRA2 set var[0009]EXTRA

<>ELSE

<>message: You don*t know osmose.

<>var[0009]EXTRA set var[0010]EXTRA2

<>END

This is one of the 7 fork conditions in the reading of the bitflag. It first checks to see if the result is greater than or equal to zero. It only would be if 64 had been added, indicating that S[0007]osmose is ON. It also then sets the second extra variable to the first extra. The way I do it, which I believe is the most efficient, the FIRST extra variable is the one that subtracts all the numbers to see which switches are ON. The SECOND extra variable is used to set the FIRST extra variable to incase the result of the subtraction is negative. one important thing to understand is that if the result of the subraction is greater than or equal to zero, the variable doing the subtracting (var[0009]EXTRA) stays the same. The other variable (var[0010]EXTRA2) is then set to the result of the subtraction so that if the result of the subtraction was negative, you can set var[0009]EXTRA back to whatever it was before the subtraction. The entire coding of the process of reading the bitflag is below:

<>var[0009]EXTRA set var[0008]BITFLAG

<>var[0010]EXTRA2 set var[0009]EXTRA

<>var[0009]EXTRA - 64

<>FORK - var[0009]BITFLAG >= 0

<>message: You know osmose.

<>var[0010]EXTRA2 set var[0009]EXTRA

<>ELSE

<>message: You don't know osmose.

<>var[0009]EXTRA set var[0010]EXTRA2

<>END

<>var[0009]EXTRA - 32

<>FORK - var[0009]BITFLAG >= 0

<>message: You know drain.

<>var[0010]EXTRA2 set var[0009]EXTRA

<>ELSE

<>message: You don't know drain.

<>var[0009]EXTRA set var[0010]EXTRA2

<>END

<>var[0009]EXTRA - 16

<>FORK - var[0009]BITFLAG >= 0

<>message: You know quake.

<>var[0010]EXTRA2 set var[0009]EXTRA

<>ELSE

<>message: You don't know quake.

<>var[0009]EXTRA set var[0010]EXTRA2

<>END

<>var[0009]EXTRA - 8

<>FORK - var[0009]BITFLAG >= 0

<>message: You know water.

<>var[0010]EXTRA2 set var[0009]EXTRA

<>ELSE

<>message: You don't know water.

<>var[0009]EXTRA set var[0010]EXTRA2

<>END

<>var[0009]EXTRA - 4

<>FORK - var[0009]BITFLAG >= 0

<>message: You know blizzard.

<>var[0010]EXTRA2 set var[0009]EXTRA

<>ELSE

<>message: You don't know blizzard.

<>var[0009]EXTRA set var[0010]EXTRA2

<>END

<>var[0009]EXTRA - 2

<>FORK - var[0009]BITFLAG >= 0

<>message: You know thunder.

<>var[0010]EXTRA2 set var[0009]EXTRA

<>ELSE

<>message: You don't know thunder.

<>var[0009]EXTRA set var[0010]EXTRA2

<>END

<>var[0009]EXTRA - 1

<>FORK - var[0009]BITFLAG >= 0

<>message: You know fire.

<>var[0010]EXTRA2 set var[0009]EXTRA

<>ELSE

<>message: You don't know fire.

<>var[0009]EXTRA set var[0010]EXTRA2

<>END

There you have it. The simple process of reading a bitflag. You may also want to set the extra variables back to zero, and if you made switches as examples, get rid of them. That's the whole purpose purpose of making the bitflag anyway! Of course, you can do whatever you want inside the fork conditions, as long as you set all the variables correctly. In my game, I read the bitflag at two points in my skill menu. The first time simply checks if you already know the skill. The second time does that while checking to see if you have enough SP to purchase the skill and then actually doing the process of purchasing it. If you haven*t noticed yet, bitflags are quite useful. One may even call them nifty :P

One clever thing I did with variables that I am particularly proud of is my scrolling item menu for my game, The Apocalypse. Note, however, that this is NOT for n00bs. Some gurus might not even understand it, especially with me trying to explain it *cough*. Anyway, there is a variable for each possible item slot, I1-I15, variables number 271-285. There is also I1ON-I9ON, I1#-I15#, and I1ON#-I9ON#. Lots of variables, but it lets me optimize coding more easily. These are for the items that are on the screen at a given time. Each item that you can have has an ID number. At the beginning of the setup, it checks which items you have through a series of fork conditions. If you have the item, it adds 1 to var[****]#ofitems. Also, it sets another variable, var[****]CALC, to that number. Then, it adds 270 to that number. Then, I take var #(var[****]CALC) and set it to the ID number of the item. So, if you have an Apple (ID of 1), the first fork condition, it adds 1 to var[****]#ofitems, making it 1. Then, sets var[****]CALC to var[****]#ofitems. Then, it takes var[****]CALC, 1, and adds 270, making it 271. Then, it takes var #(var[****]CALC), or var(271), which is var[0271]I1 and sets it equal to 1, the ID number of Apple. So the variable I1 becomes 1 if you have an apple. I1 is a slot, as are I2-I15, I1ON-I9ON, I1#-I15#, and I1ON#-I9ON#. I1 holds the ID of the first item on your list. If you don*t have apple, it would go on to the next fork, checking if you have any Oranges. If you have at least one, it makes I1=2. But, if you have an Apple AND an Orange, #ofitems would become 2, making CALC=2. Then, it would add 270, making it 272, and var[0272]I2 would become 2. This goes on for the 15 different items viewable on the menu. Also, it*s important to manage the I1ON-I9ON slots. As you scroll the menu, var[****]screenlocation changes. As the menu scrolls down, I have to swap the values of the variables.

I1 ___ I1ON___

I2 ___ I2ON___

I3 ___ I3ON___

I4 ___ I4ON___

I5 ___ I5ON___

I6 ___ I6ON___

I7 ___ I7ON___

I8 ___ I8ON___

I9 ___ I9ON___

I10___

I11___

I12___

I13___

I14___

I15___

Notice that the first 9 items you have show up when the scrolling menu is at the top. I10-I15 are below the scrolling menu, so you don*t see them. If you scroll down one space, I2-I10 will be on the screen. I1 will above the screen and I11-I15 will be below, so you won*t see them. When the menu is scrolled like that, the values are swapped. Rather than I1 corresponding with I1ON (like in the diagram), I2 will correspond with I1ON. So, the first item on the list would now be the second item you have.

CLOSURE

I'm going to leave it at that because the scrolling menu gets REALLY complicated. I may write a separate tutorial about it. I'm sorry if I confused you; it's actually incredibly simple once you get the hang of it. I hope it helped a bit.