Final PSX Hacking FAQ

From Wiki -
Jump to: navigation, search

This is the Final PSX Hacking FAQ, as written by Lazy Bastard, King Edgar 0, and Liquid Man Zero Hopefully, this FAQ should rid the scene of most PSX hacking questions, and clear the way for a few more good hackers.

Section 1 - Detailed Basics

Could you just do the FAQ without me asking questions?

Yes. Heheh.


Above is the basic structure of a GS code. XX represents the code type. These include 80, 30, D0, 50, and so on (check out the FAQ on code types by CM for a complete list). YYYYYY represents the address. This is simply the location in memory that the code affects. ZZZZ is the value, which is what's at that location.

When you're searching for something, or browsing with the Memory Editor for that matter, the GS displays all addresses as 80 codes, but "80" is not really part of the address; it's just the most commonly used code type. This isn't really vital information to an average hacker, but for those seeking to reach a higher level of skill, it's definitely a bit of knowledge to have.

[ Actually, the "80" is really part of the address. I'm not really sure why exactly, but the proof is (from PlayStation Developer's Guide, v2.5c) :

Most PlayStation applications will run using the address ranges 0x80000000 to 0x80200000 (2 Mb RAM).

Also, this is probably why all psx "cheat devices" use the 80 type.]

An explanation of GS searches

Let's start with Unknown Value searches. When you start a search, the GS takes a snapshot of the area of memory (1-9) you're searching in. You'll then have to return to the game for at least a moment before you can run any searches; this is the case after any search. Anyway, when you run an Equal To Last search, the GS goes through that snapshot, and keeps only the addresses whose values didn't change since the last search. In other words, anything that changed in the game since the last search is discarded. Only those things in the game that are exactly the same as they were before still remain. Inversely, when you run a Different To Last search, the GS goes through its snapshot and keeps only addresses whose values have changed. Greater Than Last searches yield only addresses whose values have increased, and Less Than Last searches return addresses whose values have decreased.

Searches run at any point after the first search are run on what remains of the snapshot. If you start a search, run a Greater Than Last search, and run a Different To Last search, the GS takes the initial snapshot, discards anything that hasn't increased, then discards anything that hasn't changed.

Known Value searches are even simpler. The same snapshot principles apply here, only the snapshot is taken during the first search, and is only kept for a second while the GS runs through it and keeps only the addresses containing the value you "typed in". The second search keeps only the addresses of those values that match your new inputted value. So if you run a Known Value search for "00087", then run another for "00005", the GS grabs all addresses with the value "00087", and then out of those keeps only the ones whose values became "00005". Keep in mind that Known Value searches are in decimal, not hex, so you'll be looking at 5-digit values instead of 4-digit ones. This is because the decimal equivalent of hex numbers like "FFFF" (65535 in decimal) are five digits long. Read the FAQ I wrote on Hexadecimal if you want to know about...well...hexadecimal, heh.

Unknown Value searches are used to find anything for which you don't know an exact value, such as life meters, characters, coordinates, rooms, etc. There are those rare times when life meters work in sections, when rooms or characters are in sequence, and so on; in these instances, you could use Known Value searches, but for the most part you'll use Unknown Value searches.

Known Value searches are used to find something for which you know an exact value, such as HP/MP, lives, ammo, levels for games that are actually divided into levels, and so on.

So if you think a value is 23, run a Known Value search for "00023"; if you think a value has increased, start an Unknown Value search before the next time it increases, then run a Greater Than Last search after it get the idea.

It's sometimes a good plan (it's standard procedure for me) to run an Equal To Last search right after the initial snapshot, when nothing has changed yet. This is in order to eliminate addresses with values that constantly change many times per second (sometimes called "randomized values", even though they're not truly random), and to eliminate things such as time.

Contrary to uneducated belief (heheh), all values, even "randomized" ones, represent something in the actual game, even if most are too complex or have too small an effect for anyone to understand. The exception to this is empty memory sectors: large areas of memory filled with either the value "FFFF" or "0000". "FFFF" in large numbers more commonly represents something that's just not in use right now, and even "0000" does that sometimes, so it's not always safe to assume that large chunks of "FFFF" or "0000" are empty sectors.

Anyway, back on subject; let's use our imagination and hack an infinite lives code.

We have 9 lives (we're a cat!). We know the value we're searching for, so let's run a Known Value search for "00009". This done, we'll return to the game, do nothing, and now run a search for "00009" again to narrow the results. This is the same as running an Equal To Last search. Now we lose 1 life, and run a search for "00008". Next, we'll gain a life, and run a search for "00009". Continuing this pattern, we should eventually narrow the search down to a few results, and test these results until we find the address that controls how many lives we have.

For the sake of another example, let's say we just couldn't seem to find that address. Perhaps the memory sees that "9" as 109 hex, and starts numbers at 100 hex for some odd reason, or has some other wierd system. In any case, we have no idea of what value to search for. We'll have to run an Unknown value search. Starting back where we were (with 9 lives), we start the search, do nothing, and run an Equal To Last search. Now we lose a life, and run a Less Than Last search. Next we gain a life and run a Greater Than Last search, and continue this pattern until we have a few results left. After testing all of these results, if we still haven't found our code, we'll move on to the next area of memory and do the same thing we just did, and then the next, until we've either found the code, or searched through the entire memory. If we don't find our code after all this, one of two things (or both) has happened: we've either made a mistake at some point, or we're wrong about how we think the memory works in this game. Now we either give up, start over with the same method, or try to think of a different way to hack the code.

Moving on...

The best GS hackers rarely ask "How do I hack this code?". This isn't because they have years and years of experience, or because they've already read how to in an FAQ; it's because they understand how the memory of the Playstation, and other similar processors, works. King Edgar 0 coined a name for this understanding, calling it "The Ultimate Method". Don't let the name deceive you though; it's really a lack of need for methods, heheh. And since KE was the first hacker to really ponder over this understanding, I'll let him have the floor now...

Section 2 - Ultimate Method

A brief history of the ultimate method

Let us take a journey back to the later half of 1999. The PSX Hacking scene was at it's peak. Many different people from many different places were coming together to create original and interesting codes to extend the playability of the games we loved. As the number of hackers increased, so did the number of new people. In order to teach the new people how to hack, many websites and FAQs were started to give them information on how to hack various types of codes. This seemed to work for a short time, but a major problem would became apparent shortly.

Method hackers and abaxialism

The problem was a simple one to understand. As more people learned to hack using different single methods to hack different types of codes, they shifted away from the old method of hacking. That is, they shifted away from the old center of hacking knowledge, and altered the axis of the hacking world itself. These "Method hackers" were good at what they did, but that was the end of their abilities. To hack a new kind of code they had to be taught the "method" for that particular type of code. This greatly restricted their hacking ability, and in time helped bring about the so called dark ages of console hacking.

Nachos, egg roll bandits, and the ultimate method

Now we have entered the very early days of the year 2000. Method hackers run rampant, the golden age of the ubb is drawing to a close, and old style hackers are searching for a way to teach method hackers how to let go of their restraints and hack without methods. The older hackers had been doing it since the beginning of the scene, it seemed natural to them. However it was not so with the newer hackers (with a few exceptions). The new hackers needed a method for everything. Without methods they couldn't do anything. It was an understanding of this that made the answer simple. Disguise the lack of methods as a method itself. On January 16th 2000 I took the next logical step and gave the new "method" a name, while adding it to the "Dope RPG hacking faq" that Heh[]Heh and I were working on at the time.

(That faq was well known for it's lighthearted approach at hacking, using a good deal of the space to talk about the best hacking snacks, and how to "steal" egg rolls from Chinese buffets).

Naming and birth of the ultimate method

There I sat, pondering what name would be proper for a method/non-method of this sort. It would be 2 plates of nachos and 4 IM discussions later before I would arrive at the decision name it the "ultimate method". I used this name for a few reasons. First and foremost, it would attract the attention of method hackers. After all, how could someone who relies on methods pass up the ultimate method? Secondly, it was quite true. Because the ultimate method is a lack of methods it is nothing.. but the name implies that it is everything. Look at it this way... The ultimate method replaces all other methods, it takes up every ounce of space in the "hacking universe". Therefore there are no other "methods" left to compare it with. Since there is no way to compare or measure this ultimate method, it can be seen as either everything or nothing. Which works out perfectly. Even though the ultimate method DOES cover everything, it is a complete lack of methods. Everything and nothing at the same time.

Now that I look back upon that day I wish I would have had the insight to call it the Zero method. It carries the same implications as the ultimate method (although reversed), and because the last character in my nickname is "0" it is even more interesting.

The dark ages and incompleteness

Now the ultimate method was out in the open. Although many hackers had used it for years, it lacked a name until the first release of the Dope RPG hacking FAQ. Unfortunately all that the faq included was an introduction to the ultimate method. If a method hacker wanted to walk down the road of the ultimate method, he or she only had a very general sense of where that road was, and no directions when it came to what turns to make. Even to this day the ultimate method hasn't been fully explained. One possible reason is that perhaps it can't really be explained. Everyone learns differently, so is it that strange to assume that the road to the ultimate method is different depending on who you are? Unfortunately the sand had run from the hourglass, and console hacking was about to enter it's dark ages.

They came quick, and they hit hard. The UBB was merged with the DexDrive UBB and the resulting mess drove most of the hackers away from for good. Most of those that didn't quit hacking migrated to the GSCCC. It seemed that the method hacker problem was worse than ever. It was hard to find people that used the ultimate method, most seemed to cling to method hacking because it was easy for them. During this time the mindset of the entire hacking community seemed to change. There were less and less group projects. Interesting codes were becoming a rarity. Many bad things came together to become 1 horrible thing: The dark ages of console hacking. When you compare the dark ages of console hacking to the wonderful days of late 1999, you can see a drastic decrease in the amount of interesting non-cheat codes being produced by the community. In the golden days of late 1999 you could see many interesting codes produced in 1 day, and from only one hacker. Sometimes a hacker would hack for 5 hours straight and each hour head over to the UBB to report his or her progress and post codes. Perhaps even seek a little help or turn the work into a group project so even more could be discovered from his or her initial discovery. However in the dark ages of console hacking it was not uncommon to see 2 or 3 weeks go by without an interesting code being made available to the public. With that simple comparison it is easy to see why the thought of the golden days of late 1999 brings up a lot of nostalgia in older hackers.

Section 3 - Code Types

What I intend to do, is explain what code types exist, and if I can, how they work. At the very least, there is a full list of all GameShark (Action Replay, GameBuster, depending on where the device is from) types, and possibly some of the Caetla (most likely, also clones of it) and Xploder (Xplorer, X-Terminator, Code Breaker, depending also on where the thing came from) types as well. If all goes well, this will be less confusing than say... CM's FAQ, or if nothing else, more detailed. s

Something that may be of use to some people, is, that GS and Xploder style carts can use nonexistent RAM addresses. So, you can use just about anything between 80000000 and 807FFFFF, if you want. Though, some addresses above 80200000 will cause problems, most won't, but some will. I have not tested this on a GS v1.x, or a Caetla, as I have neither one. This might not work on whatever you're using, but it's likely that it will.

Most codes will have a structure like this:

PSX Hacking FAQ structure.PNG

The "TT" is where the code type is defined, "XXXXXX" is the address that the code does something with, and "YYYY" is where the value the code uses is. Besides a few types, there are some exceptions to this. On an Xploder or Code Breaker, the second "T" is used to tell if a code is default on or off. If the first line in a code has a 0 there, it's a default on code (so, if you select that game, all the codes with a 0 there will be activated). If that's an 8, instead of a 0, the code will be default off. As far as I know, there are no other exceptions, besides some types (that will be explained, in some sort of detail below).

Something you should know, is that not all codes work. Some codes that should work (i.e, they are in a valid memory area, and are overall correct codes that have no reason to not work) just won't. This is most common on a GS Pro (v3.0 to v3.2), especially hacked versions of the cart.

Speaking of hacked versions... Some codes may cause very annoying side effects when used with a hacked cart. Final Fantasy VII is probably the worst about it, as using some codes and saving (even with the codes off) may near permanently corrupt a card.

General Types

These are the ones that should work on anything. By that, I mean pretty much any hardware that can use codes can use these. So to start, I'm going with the most common sort of code , the 80 type.


This type, 80, simply inserts all four digits of the value, and keeps it set to the entered value (or at least tries to, some games change too often for this to work correctly, but that's entirely an unrelated thing...) For example:

8009A05C 0041

This would write 0041 to the RAM address 09A05C. The value can be anything from 0000 to FFFF, and the address should be something between 000000 and 200000 (hex of course), but has to be even. By even, I mean in hex (in case you don't know, that would be 0, 2, 4, 6, 8, A, C, or E). In general, a code of this sort is called 16-bit (or that it affects a "word"), that being how many bytes it deals with (in this case, writes). You should be able to use this on any device as many times as you can fit.


A 30 type code is very similar to 80. The biggest difference is it's an 8-bit code (half of a 16-bit code, or half-word). On this kind, only the last two digits of the value are used. One of these is:

300DB0D5 00D9

If all goes well, this one would put D9 at the location 0DB0D5. As with 80, you can use this on probably everything, as many times as is possible to fit it. For 30, you can use the any address 80 can, but it does not have to be an even.


Hmm... I guess D0 now... D0 is the "do if true" type. What it does is, if the value at the address is the same as the one that's in the code, the next line is done. If it's not, nothing will happen. This should look something like:


The X's are the address, and the Y's are what value it looks for at that location. The address has to be even, and the value 16-bit. This will work only with 80, 30, 1*, 2*, D*, and E* types as the next line. You can't use one of these to trigger a 50 line. This, and all D* & E* types are limited to 63 (of all D* & E* types) active at the same time. Also, this type may not work on some CDX devices. Example:

D0198420 1859

This would do the line after the value at the address 198420 is equal to 1859. This can be easily converted to work on an Xploder/Code Breaker by just changing it to 70, instead of D0.

GS/AR v2 Types

These are code types known to only (well, most of the time anyway) work on any GS style device. If you don't have a GS, or similar, you still might be able to use these, so if you want, try it on your "cheat" device of choice to see for sure. Xploder/Code Breaker can't use these, but have similar types that these can be converted to. These might not work on a version 1 (v1.0-v2.1) cartridge, but I may be wrong about that. Although, codes of these types may not work very well, or even at all on a CDX (as in, a GS or whatever on a CD). I don't have a CDX, so I can't find out for myself and mention it here.

D1: The D1 code type. What it does is, if the value at the address it has is not the same as the one in the code, it will do the next line. This is pretty much the opposite of what the D0 type does. Most likely, this is what it should look like:


From what I've seen this should work on anything newer than a GS v2.2 (I'm not sure what the equivalent PAR version is...) Everything else about this sort of code is the same as the D0 type. Example:

D10625FC 4100

This would do the line after it if the value at the address 0625FC is not 4100.

D2: D2... Most likely, this will do the line after it if the value at the address it has is less than the one entered. Otherwise, it is the same as the D1 type. And the boring example:

D2062602 00C8

For this, if the value at 062602 is less than C8, then the next line is done.

D3: D3 will do the next line if the value at the entered address is greater than the one in the code. Otherwise the same as D1 and D2. Bleh... and yet another example:

D30B7582 270F

In this example, the next line will be done if the value at the address 0B7582 is greater than 270F.

E0: Now for the E0 type... bleh... The only difference between the E0/1/2/3 types and the D0/1/2/3 types is; that the E* ones can use any address, even or odd, and only check for one byte, instead of two bytes. Oh yeah, these sort may have trouble with older (than v2.4) carts. If it doesn't work, try changing it to D0. An example, for the E0 type:

E0062603 00FF

This would do the next line if the value at the address 062603 is equal to FF.

E1: Example for the E1 type:

E11F8905 0019

This would do the line after it if the value at the address 1F8905 is not equal to 19.

E2: E2 type example:

E209427D 0069

(Bleh... again with the "This would do the..." thing...) This would do the next line if the value at the address 09427D is less than 69.

50: A slight pain in the ass sometimes, but can save quite a bit of time and/or space.

80NNNNNN 0000

XX - Number of times to repeat YY - # of bytes to jump from last address ZZZZ - Value to increase address NNNNNN - Address to start from





GS/AR v3 Types

The types in this section will most likely only work on a GS v2.41 or later (up to v3.2) or equivalent. Some of these may work on a CDX, though I can't be sure which ones, if any, actually do.

D4: The D4 type is the "Universal Joker Command." It looks like:

D4000000 XXXX

Use regular Joker command digits for the X's. This will only work on GS versions 2.4 to 3.2. Not only that, but it's known to cause problems with certain games (Gran Turismo at least). The example:

D4000000 1000

This would do the line after it if you pressed the Up button on a controller. (1000 is the value for Up)

D5: D5 will turn all codes on. I mean every code that was "on" when the game was loaded. Uses the regular joker command digits. Should look like, but it doesn't matter besides the first two digits, and the last four.:

D5000000 XXXX

An example:

D5000000 0001

For this, if you pressed L2, all active codes would be turned on. This would have no effect if the codes were already active though.

D6: Well... the D6 type is the same as the D5, only it turns all codes off. Example:

D6000000 0002

Using this, pressing R2 would turn all active codes off. If the codes are already off, they would stay that way.

C0: Blaw... C0. It's pretty much a D0, only it affects every code, not just the next line. So, if the value at the address it has matches what was entered, all codes will be active. If it's not, no codes will be active. I'm pretty sure that once the value has matched, all the codes stay on. All C* code types are limited to 30 at the same time. Will not work on anything lower than GS v2.4, also might not work on CDX versions.


C0039580 9471

With this, all the lines after it would be done if the value at the address 039580 is 9471.

C1: C1. Delays turning on all codes until a certain amount of "time" has passed. The exact length of time this may be depends on the digits entered and the game being loaded. 1000 (hex) could be anything from 2 seconds to an entire minute... [I have a feeling it's based on something stupid, such as frames, or something. But now I'm thinking it's got something to do with the setting of VSync (this being always set to either 0, 1, 2, 3, or 4). VSync if I'm remembering right, is how the PSX keeps the frame rate locked (or tries to at least).]

An example:

C1000000 1000

This would leave all codes off until "1000" something has passed. This could be anything from a few seconds to quite a number of minutes. This would probably be long enough for most games to load if they have problems with codes.

C2: Copy bytes code. Makes a duplicate of the data in one place in another.

Xploder Types

70: For all purposes, this is exactly the same as the GS D0.

90: Equivalent to D1, in all possible functions and features.

Valid Code Combinations

Originally, I wasn't going to do this part, but something someone had posted made me realize that this is really needed.

80 - Has no effect past it's own line. Works with all other code types, except C1.
30 - Same as 80.
D0 - Effects the line after it, works only with 80, 30, D0, D1, D2, D3, E0, E1, E2, E3, 50, C0, and C2. You can't use a 50 or C1 line after it under any circumstance.
D1 - Same as D0.
D2 - Same as D0, and D1.
D3 - Same as D0, D1, and D2.
D4 - Same as D0, D1, D2, and D3.
D5 - Other lines above or below it have no effects on it. Functions in any place.
D6 - Same as D5.
E0 - Same as D0, D1, D2, D3, and D4.
E1 - Same as E0.
E2 - Same as E0 and E1.
E3 - Same as E0, E1, and E2.
50 - Requires an 80, 30, 10, 11, 20, or 21 line after it. Will have no effect if any D, E, or C0 line is above it.
10 - Needs a D0, D1, D2, D3, D4, E0, E1, E2, or E3 line above it. Lines below do not affect it.
11 - Same as 10.
20 - Same as 10 and 11.
21 - Same as 10, 11, and 20.
C0 - Has no effect if there's not a line below it.
C1 - Effects no other lines, can be placed anywhere.
C2 - Lines above can affect it. Valid lines above are: 80, 30, D0, D1, D2, D3, E0, E1, E2, E3, and C0. Needs a 80, 30, 10, 11, 20, or 21 line below it.

Section 4 - Mathematics


An often overlooked aspect of GS hacking is simple mathematics. Any hacker, especially one aspiring to work on advanced projects, should have a working knowledge of hexadecimal and conversion between it and decimal. And it's good to understand the idea of mathematical conversion between versions of the same game. But beyond that, most fall short.

So what else is there?

There are quite a few things in GS hacking that involve mathematics, but I'll cover only one that I feel is important. This can be a difficult topic to explain, so I'll start with an example. If at some point you become totally confused, don't worry. I expect that to happen; just continue reading.

You're hacking for a brand new game you just bought, Metal Gear Fantasy Alpha (which doesn't actually exist, and now that I think about it, kinda sounds like a porno with robots...heheh). Let's say, for fun's sake, that this game's a combination of an action game, an RPG, and a fighting game. Right now you're in the middle of a battle with three enemies. You stretch out your arms, push that button, and flare up your GSPro. After a few minutes, you've hacked a modifier for the first enemy's health bar, and you're feeling pretty proud. Congrats, man. Or woman. Or whatever. So now you move on to hack a mod for the second enemy's health bar. Cool. So now you're gonna hack the health bar of the third enemy. You push that button, start an unknown value search for - wait a minute. You just get an idea? If not, that's OK; you're still learning, that's why you're here. Anyway, I sure did, heh. OK, let's look at the two addresses you've found so far.

1st Enemy Health Bar Mod - 80095564 ????

2nd Enemy Health Bar Mod - 80095638 ????

Now assuming that all three enemies were programmed with the same amount of information, it's safe to assume that their info also takes up the same amount of space in the memory. I'm sorry if this sounds confusing; I'll try to make an analogy. There are exceptions when working with data, but say you have three brand new steel barrels. They're made of and contain entirely the same substances, and have equal weight and height. It's safe to assume they have equal circumference (distance around the barrel).

Anyway, assuming what I said is true, and that either there is no data between that of the enemies or that the data between enemy one and two takes up the same amount of space as the data between enemy two and three, you can now finally make a useful assumption: that the distance between any two equivalent addresses of enemy one and two should be the same as the distance between any two equivalent addresses of enemy two and three.

So the distance between the 1st Enemy Health Bar Mod (80095564) and the 2nd Enemy Health Bar Mod (80095638) should be the same as the distance between the 2nd Enemy Health Bar Mod and the undiscovered 3rd Enemy Health Bar Mod. And why is this useful? Well, grab a calculator that can work in hex (the one that comes with Windows will work fine, as will any scientific could even add and subtract in hex without a calculator at all - read my FAQ on hexadecimal, if you'd like), and find the difference between the two addresses you have.

95638 - 95564 = D4

So the difference between those two addresses is D4. Not only that, but this is the difference between any two equivalent addresses from one enemy to the next. Looking back to what I said before, add D4 to the address that modifies the 2nd enemy's health bar (80095638). You'll get 8009570C. Guess what? That's the 3rd Enemy Health Bar Mod. You've just hacked something without using a GS, or hell, even a PSX.

OK, you happen to be excited about this new game, so you notice that your enemies also each have a magic bar, and you set about to hack those. You do the push button, flare up thingy you just did a minute ago, and hack a 1st Enemy Magic Bar Mod - 80095562 ????. Well, you already know that D4 is the distance between any two equivalent addresses from one enemy to the next, so add D4 to that address, and you instantly get the 2nd Enemy Magic Bar Mod - 80095636 ????. Now add D4 again, and you've got the 3rd Enemy Magic Bar Mod, 8009570A ????. Now this idea's finally starting to pay off.

This may seem like a simple time saver, and it is in that example. But when something more complicated needs to be performed, you'll suddenly have a good tool in your hand where you thought there was a simple time saver.

For our next example, let's say you saved up 50 bucks helping the old lady across the street take her trash out for a month (you swindler, you), and went down to the store and picked up a game you've been wanting for a long time, Resident Frontier VII (which also doesn't actually exist), 66% RPG and 33% Survival Horror. You play it for a few hours, and you get to the part where you're out on the world map, and the big, evil mutant goldfish is trying to find you and eat you, and it has way more HP than you do. You'd rather not fight her, and she could teleport from the other side of the world where she's just broken free from Parasol Corporation's illegal labs to being only a few steps away from you at any moment. You suddenly have an idea. If you could hack her coordinates, you could stick her in one spot for as long as you want. You have a dilemma, though. Since she warps, and only makes a jump or two to get to you after that, it's not really an option to hack her coordinates. You shrug your shoulders, pause the game, and pop open a can of Pringles as you ponder over what to do.

This seems impossible. In reality it isn't, of course, but it may seem like it is the first time you hack something like this. That's OK; you're beginning to delve into the world of somewhat advanced hacking here. If you get confused and have to read this more than a few times before you understand it fully, that's OK. You're still doing a far shot better than about 90% of the GS hackers around, especially the run-of-the-mill method hackers with their damn abaxialism (heheh).

Heh, well, there are only a few scattered sprites on the world map. Sprites, in case you don't know, are simply characters and objects that have an action or move at some point in the game. They exist in towns, on world maps, and even in battles, and they're in every game I can think of. But for right now, there's you, the jeep you have, which you can get in and out of, the goldfish, this ship that goes constantly between your continent and the next, which has nothing to do with what you're hacking, and this dragon which flies around in the skies that you'll fight later on in the game, which also has nothing to do with what you're hacking. The data for the sprite you control, in pretty much any game, is first in the memory, before that of the other sprites. Next usually comes things like your vehicle or animal you ride, and after that it's a grab bag of whatever else exists (your controls, if you're wondering, are usually in a totally different area of memory). Getting any ideas yet?

Using the same idea you used when you hacked those codes for your old fav, Metal Gear Fantasy Alpha, you decide that the information for each sprite probably takes up the same amount of space, and is arranged the same way. So if you were to find the coordinates for one sprite, and then for another, preferably the next, you could solve for the coordinates of the others. Before I continue, let me briefly explain the three types of coordinates.

X - West to East, or East to West

Y - North to South, or South to North

Z - Up and down, heh. Your Z coordinate is your elevation level, or how high in the air you are.

Now, since you control yourself, heh, you set about hacking your own coordinates. You walk north, and run a Different To Last search. You then walk east, being careful not to walk north or south, and run an Equal To Last search. You walk south, and run a Different To Last search again. You may be wondering why I'm not running Greater Than Last searches as I go north, and Less Than Last searches as I go south. Well, in some games, coordinates increase as you go south, and in others they increase as you go north. Once you know which way the particular game you're hacking works, you can then use Greater Than Last and Less Than Last searches with confidence. You could use them anyway, and just try one way, and if that fails, try the other, but doing things like that should be held as a last resort, in case you can't succeed any other way. Anyway, now you do some other thing that doesn't make you move north or south at all, and run an Equal To Last search again. You continue this pattern, and eventually you've hacked your Y coordinates. You now do the opposite, and hack your X coordinates. Next you start a new search, walk up a hill, and run a Greater Than Last search. You then walk down the hill a little, and run a Less Than Last search. Then you walk down the rest of the way, and run another Less Than Last search, and walk back up, and run a Greater Than Last search, and so on, eventually finding your Z coordinates. Good job.

Next, you get into your jeep, and do the same thing entirely, until you have X, Y, and Z coordinates for it, too. Let me lay out a set of results for you:

Your character

X Coordinates - 80094BBA ????

Y Coordinates - 80094BBE ????

Z Coordinates - 80094BBC ????

The jeep

X Coordinates - 80094C60 ????

Y Coordinates - 80094C64 ????

Z Coordinates - 80094C62 ????

You may wonder why the address for the Z coordinates is between the addresses for the X and Y coordinates. I wonder this too, heh, but it's usually the case. [ I think this is because of how a lot of things I've seen use X for width, Y for height, and Z for depth, even though it seems to make slightly less sense to do it that way. I know most 3D modeling programs use that system for coordinates. It makes perfect sense that games would do the same thing, as that's most likely what the programmers were used to seeing. ]

Now, you find the difference between your X coordinates, and those of the jeep. It turns out to be A6. This is, then, the difference between any two equivalent addresses of your character and the jeep. If you don't believe me, find the difference between your Y coordinates and the jeep's Y coordinates, or do the same with Z coordinates. It's A6. We can't say for sure if it's the difference between the equivalent addresses of any sprite and the next (or previous), since we don't know if the data for any other sprites is between that of your character and the jeep (if it was, the difference between your character and the jeep would be larger than the difference between any sprite and the one after or before it, because the next sprite after your character wouldn't be the jeep, but some other sprite). There are two things you could do about this. If the distance between the data for your character and the jeep is small enough, as it is, you could use the Memory Editor and look at everything between the two, to see whether or not anything resembles another set of coordinates. Or you could simply assume A6 is indeed the correct difference between any sprite and the next, and try it out. The latter is usually my favorite, especially if I'm in a hurry to find one thing. So, staying in your jeep, look in the memory at all of your coordinates, and write them down. I'll make some coordinates up:

X Coordinates - 80094C60 5376

Y Coordinates - 80094C64 7393

Z Coordinates - 80094C62 1063

Now, if you found another sprite's coordinate mods, and used these digits with them, you'd probably be right in assuming you'd put them in the exact spot you're at right now, from wherever they were at before. This noted, in case adding A6 once gives you the coordinates of the goldfish, which you definitely do not want to suddenly be at the same spot you are, you move away from the spot you're at. Now add A6 to all of those addresses. You'll get

X Coordinates - 80094D06 ????

Y Coordinates - 80094D0A ????

Z Coordinates - 80094D08 ????

OK, before you modify this poor sprite's coordinates, save your game. At this point, before you have much experience, I don't want to walk you through writing other parts of the memory down so you can change things back in a moment if you need to, so saving is the best thing for now. If you eventually discover and invent your own shortcuts, great. And if you really can't think of any, e-mail someone on the GSHI staff. Anyway, let's move on.

Using the Memory Editor, look at the three addresses you just found a moment ago. Did anything happen? Good, I was just kidding; nothing was supposed to happen. Heheh. Anyway, get those values you wrote down, and plug'em into the three addresses you just solved for. Now return to the game. Damn, it's the dragon. Well, it's a good thing you just saved, because since you didn't write down the original coordinates for that dragon, you might as well reset, or go die or something (in the game, mind you), so you don't have to make up new coordinates to try with the next sprite.

Now you've reset and loaded your save. You add A6 to those new addresses (those of the dragon), and plug in those values again. And this time it's the goldfish! Don't worry; she can't hurt you - she's stuck in that spot. A job well done. Change her coordinates and move her around if you want to. She's totally under your control now, as is any other sprite on the map.

I'm too lazy to give any more examples right now. You should have a pretty good grasp of how useful simple mathematics can be in GS hacking, if you're willing to use your head. Good luck with it all.