# Skeetendo

’Cause all games were better on the GBC

You are not logged in.

## #1 2013-06-01 23:48:25

Frezgle
Member Registered: 2011-05-30
Post 15/24

### Tutorial: Manual height/weight editing

I've just figured out how height/weight editing works for PokeDex entries, and I didn't see any thorough explanations or automatic tools on here, so I thought I'd offer a tutorial!
This is for versions of the games where height/weight are measured in feet and pounds - but it probably works in a very similar way for meters and kilograms.

Now, right before the start of the actual text of each Pokemon's dex entry, there are four bytes.
The first two bytes determine the height, and the second two determine the weight.

Example:
Right before Blastoise's PokeDex entry, there are these four bytes
F7 01 62 07

Looking at Blastoise's height and weight, we see that they are 5'03'' and 189.0 lbs (188.5 in later games, but ignore that! d: )

Now, let's single out the first two bytes of the four. These determine Blastoise's height. F7 01 translate to 247 and 1 in decimal. Doesn't seem to have much relation to 5'03'', does it?
That's where a bit of calculation comes in. To start with, pretend the symbols in 5'03'' aren't there, and it's just a number: 503.

Now, understand that the first byte is always going to literally be the value it shows. 247.
BUT, the second byte is actually 256, multiplied by whatever its value is. In this case, it's just 1, so it means 256. If the second byte was 02, it would mean 512, and so on. I think it's a little backwards to do it this way, but I didn't program the game!

To get 503, you just add them together. 247 + 256 = 503. Simple!

And, the weight works the exact same way. Again, treat 189.0 as a number without the decimal place: 1890.
The first byte, 62, translates to 98 in decimal. And the second byte, 07, is 7 * 256, 1792.
Add 98 and 1792 together, and you get 1890!

----

So, once you understand how these values work, putting in your own custom values just takes a little bit of math and reversing the process.
In my hack that I'm working on, Blastoise's spot is being filled in by Samurott. Samurott's height and weight are 4'11'' and 208.6 lbs.

Just like before, I'm going to treat each one as a plain literal number.
To start with, how are we going to get the height, 411, into the proper set of two bytes? Well, first we need to figure out the value of the second byte, the one that stands for multiples of 256. To do that, divide 411 by 256 - you get 1, with a remainder of 155.
So the second byte is going to be 01.
As for the first byte? That's the remainder! All you have to do for that is take the remainder, 155 in this case, and convert it into a hexidecimal byte. I use a Hex <-> Decimal calculator for this because I'm lazy. Anyway, it's 9B.
So, Samurott's height is going to be represented with 9B 01. Always remember that the byte that's multiples of 256 goes second, even though you figure it out first!

And figuring out the weight works the same way again, though it will often be a much larger number. Don't let that confuse you; the math is exactly the same.
256 goes into 2086 8 times, with a remainder of 38. 38 in hex is 26.
So our weight bytes are 26 08.

Putting all of that together, Samurott's height/weight data is 9B 01 26 08.
And that's it! It's a pretty tedious process, but once you get the hang of it it's not hard at all.

Before: After: Offline

## #2 2013-06-02 19:10:45

Miksy91
Member Registered: 2010-10-16
Post 1,685/2,348

### Re: Tutorial: Manual height/weight editing

Frezgle wrote:

Now, understand that the first byte is always going to literally be the value it shows. 247.
BUT, the second byte is actually 256, multiplied by whatever its value is. In this case, it's just 1, so it means 256. If the second byte was 02, it would mean 512, and so on. I think it's a little backwards to do it this way, but I didn't program the game!

In computer programming, there are pretty much two practical methods for representing data - little-endian and big endian data formats.
Big endian data format means that data, as bytes, is represented in "most logical" way, the most significant byte first.

Little-endian, then again, does the exact opposite. In little-endian, the least significant byte is first, followed by the second least significant (which in this case is the most significant byte since the data only consists of two bytes for both of the structures = "1. height +  2. weight").

So there you have two little-endian number presentations of two 2-byte values. Those are F7 01 and 62 07.
In big endian, they would be 01 F7 and 07 62.

And in most cases when you have to work with GB/C, data is represented in little-endian format. This is because it should be slightly more practical to work out with code using data that is in little-endian format instead of big endian. If you think about it, pointers are also "addresses" in little-endian format.

Anyway, this tutorial should be pretty handy for beginners. Good job writing it.

Offline