Talk:Pokémon data structure (Generation IV)

inverse PRNG?

• TCCPhreak> 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.

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

• 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)

• 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)

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.

Data structure

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