Talk:Pokémon data structure (Generation IV)

TO DO

• 0x08-0x09: List species IDs
• 0x0A-0x0B: List held items
• 0x14: Explain dual purpose of offset
• 0x15: List abilities
• 0x17: List countries
• 0x1E-0x23: Split into individual contest stats (1 byte/stat)
• 0x28-0x2F: List moves
• 0x30-0x33: Split into PP/moveslot
• 0x34-0x37: Split into PPUp/moveslot, describe effects out of range [0..3]
• 0x38-0x3B: Describe bitfield packing of IVs, significance and use of highest two bits
• 0x40-0x41: Describe spot encoding
• 0x48-0x5D: Describe limitations on nickname
• 0x5E-0x5F: List hometowns
• 0x60-0x63: Describe bitfield packing for contests
• 0x68-0x77: Describe limitations on OT name
• 0x78-0x7A: Describe date format
• 0x7B-0x7D: Describe date format
• 0x7E-0x7F: List locations
• 0x80-0x81: List locations
• 0x82: Describe bitfield packing for Pokérus status (contagious/immune)
• 0x83: List Poké Balls
• 0x84-0x85: Describe coding

Checksum

A checksum calculation algorithm is outlined (in Deutsch) at Pokemon Inside. I coded up a version of it in Perl; the first byte of the checksum calculates properly, but the algorithm listed there doesn't seem to work for the second byte. Can anyone shed some light on this? -Tsanth 23:15, 12 December 2007 (UTC)

• Okay, I found the problem: the algorithm described on the page is incorrect in regards to the second checksum byte. The first checksum byte is indeed calculated as [sum of even-numbered bytes in blocks] % 0x100. However, to get the second byte of the checksum, we need to do ([sum of all bytes in blocks] + ([sum of even-numbered bytes in blocks] / 0x100)) % 0x100. Instead of taking the modulus for the second byte, we need the quotient. I just tested it on two pkm files I have on-hand; I'll do some more testing later. -Tsanth 00:00, 13 December 2007 (UTC)

• I found another way to calculate checksum. I analyzed a software, Legal.exe and it use another algorithm. It divides the 80 bytes that describe the pokemon in groups of two bytes (words). The groups are added to each other. You take the last word's bytes. Note: you must adjust the bytes of words (from little endian to big endian), sum it, adjust it again and then divide the result. XX YY ZZ AA BB CC (the 80 bytes) -> YY XX AA ZZ CC BB (adjusted words) -> YY XX + AA ZZ + CC BB (sum) -> MODULE 0x100 (take the last word) -> MM NN (checksum) -Whivel 16:14, 9 July 2008 (UTC)

• I have a Python implementation of the pkm encryption code up here. -Tsanth 06:41, 12 July 2008 (UTC)

• My edits to this article are done for tonight. I am planning a Python-based GUI program to allow viewing/editing Pokémon data (like Pokesav, but the first iteration will deal only with pkm files); in order to make that program, I will have to map the bitfields in the unencrypted data. I am planning to make time to update this article with that information after it's available. -Tsanth 09:32, 12 July 2008 (UTC)

• The method used for Legal.exe & PokeSav have already been explained in the article. -Sabresite 11:17, 9 January 2009 (UTC)

Updates

• Moved general SAV file related information to a new article: Save Data Structure in the DS -Sabresite 11:17, 9 January 2009 (UTC)

Data Block's order

I'm analizyng pokesav. I try to understand encrypt algorithm. I found the system used by ds game for ordering the blocks. i'll test it and may write the algorithm -Whivel 20:45, 9 July 2008 (UTC)

Protection

Why is this page protected? I see an error. Atomix26 18:36, 30 November 2008 (UTC)

It doesn't look protected to me. — Laoris _(Blah) 19:03, 30 November 2008 (UTC)

inverse PRNG?

As this is the only page on which the PRNG is explained, would it be useful to write some information about inverting the PRNG? I did some calculations yesterday so I can write about it, but I'm not sure whether such information (only useful for "rolling back" the PRNG) is in the scope of this page. - unsigned comment from TCCPhreak (talk • contribs)

Something that I've always wondered...

Is the encryption of the data structure the reason why saving a game in Generation IV takes so ridiculously long compared to other games? --Blaziken257 07:57, 11 March 2010 (UTC)

Probably. Furthermore, the save takes even longer than normal when it has to encrypt all of the Pokémon in the PC storage system, which is why sometimes you get the "Saving a lot of data" message (if you go into the PC and make any changes). --Codemonkey85, 16:45, 11 March 2010 (EST)

Evolving

I believe that one 'unknown' value in the data structure has to be at what two levels the Pokémon evolved, which would probably account for 2 bytes. This is because, when going to a move tutor, they will only offer moves that the Pokémon had a chance to learn in their evolution growth pattern. These two values are important for this, as they dictate what moves can be tutored.

It looks like it would be the 0x42-0x43 segment in Block B to me. --TruePikachu 01:07, 6 May 2010 (UTC)

---

I was under the impression that the Move Tutor offered only moves that the exact species of Pokémon you are trying to tutor could learn, leaving out the pre-evolution's exclusive moves. Also, only one byte would be needed for this data anyway.

I'll take a look at some of my Pokémon sometime and see if I can corroborate this possibility, at any rate. --Codemonkey85 - 23:14, 5 May 2010 (EST)

How could it possibly use only one byte? The structure has to remain compatible for all Pokémon, which includes Pokémon in a 3 stage growth process. The Stage 1 -> Stage 2 would be one byte, and the Stage 2 -> Stage 3 would be the other byte. --TruePikachu 01:07, 7 May 2010 (UTC)

The evolution data is not stored in each individual Pokémon. It is stored in the ROM, as base stat data. Also, there are more than 256 Pokémon, meaning that just one index number would take up two bytes, meaning that a 3-stage evolution line would take up 4 bytes. If the data really were stored in each Pokémon, it would only be for the next one in the line. Ztobor 14:09, 14 August 2010 (UTC)

Um, did you even READ my posts here? For example, you have a Typhlosion who you evolved at first oppurtunity. The data would be either 0x0E24 or 0x240E. These are, either edian, 0x0E and 0x24, which, in decimal, would be 14 and 36; the levels that Typhlosion leveled up at. It is useless to supply whatever species (the evolutions all branch out, not in), and that doesn't have level information. However, seeing this again, I have doubts that Nintendo would even try to put this in. I'll check with my Pay Day Persian. --TruePikachu 23:51, 17 November 2010 (UTC)

And-ing pointers with values?

That's a big no-no. "0x25 & 0x01" is equal to 0x01. 0x25 is the pointer, where as 0x01 is a value. You can't mix the two together. Ztobor 14:08, 14 August 2010 (UTC)

However, if you MUST use a pointer, I would personally use the ASM coding version, where, in the above example, you would have (0x25) and 0x01. Either that, or use DATA+0x25, but that's an offset, and could become confusing. And Ztobor, good work with the bitwise operation, but the commonly accepted symbol is "&&", not "&". I am pretty sure that "&" is the boolean variation, which will return TRUE if neither input is FALSE. "&&" is the bitwise function, which will AND together each bit in sequence (bad description), usually for bit masking. --TruePikachu 23:58, 17 November 2010 (UTC)

Sorry, but you have that backwards: "&" is bitwise, "&&" is boolean.[1] --a_magical_me 05:53, 18 November 2010 (UTC)

About the rewording template...

Best thing I could find. If you think there is a better one, feel free to change it. - unsigned comment from TruePikachu (talk • contribs)

Data structure

I've noticed that Project Pokemon has much more details on this. Eridanus (talk) 14:57, 3 September 2016 (UTC)