Bulbapedia

Pokémon data structure (Generation III): Difference between revisions

Article Discussion

Pokémon data structure (Generation III) (view source)

Revision as of 00:02, 27 September 2007

719 bytes removed ,  27 September 2007
Locations in the saved file clearly don't correspond directly to locations in "RAM"... Hell, 0x03004360 is like 48 megs in!
(Locations in the saved file clearly don't correspond directly to locations in "RAM"... Hell, 0x03004360 is like 48 megs in!)
Line 1: Line 1:
Pokémon in the games Ruby, Sapphire, FireRed, LeafGreen, and Emerald are all stored the same way in a 100-byte structure.
Pokémon in the games Ruby, Sapphire, FireRed, LeafGreen, and Emerald are all stored the same way in a 100-byte structure.


For Diamond and Pearl, see [[Pokémon data structure in the DS]].


=Notes=
=Notes=
Line 19: Line 18:
| Font || byte || 18
| Font || byte || 18
|-
|-
| Sanity byte || byte || 19
| Sanity byte? || byte || 19
|-
|-
| OT name || 7 bytes || 20
| OT name || 7 bytes || 20
Line 56: Line 55:


==OT ID==
==OT ID==
The Original Trainer's ID Number. Part of the XOR encryption key for the data section, also used in shiny determination and the lottery. The most siginficant word seems to be ignored?
The Original Trainer's ID Number. Part of the XOR encryption key for the data section, also used in shiny determination and the lottery.


==Nickname==
==Nickname==
Line 75: Line 74:
==Checksum==
==Checksum==
The checksum is of the 48-byte data section in the structure. It is computed by simply adding all the unencrypted values one word at a time. If this value does not match the real checksum, the Pokémon is interpreted as a [[Bad egg]].
The checksum is of the 48-byte data section in the structure. It is computed by simply adding all the unencrypted values one word at a time. If this value does not match the real checksum, the Pokémon is interpreted as a [[Bad egg]].
It is possible to manually [[trade]] a Pokémon from one saved state to the other, eliminating the need for computing checksums, by capturing the machine's memory. VBA does this with its File - Load Game and Save Game functions, but produces a file compressed in the gzip format. If the file is gunzipped, a regular hex editor can copy/paste the 80-byte structure of Pokémon directly from one saved state's Pokémon Storage System to another. The edited file is then re-gzipped, and it is ready for loading into VBA. A drawback of this technique is that if the trainer IDs are different, the Pokémon will be unrenameable in the same way that one traded from another person is; conversely, this may be an advantage if the traded Pokémon levels up faster.


==Padding==
==Padding==
Line 96: Line 93:
* Ruby: 0x03004360
* Ruby: 0x03004360
* Sapphire: 0x03004360
* Sapphire: 0x03004360
* Emerald: 0x02024190 (0x020244EC for US games??) (0x5238 or 0x7238 in save data (US)??)
* Emerald: 0x02024190 (0x020244EC for US games??)
* FireRed: 0x02024284
* FireRed: 0x02024284
* LeafGreen: 0x020241e4
* LeafGreen: 0x020241e4
Line 107: Line 104:
It also applies to stats and level, which are recalculated based on Experience.<br>
It also applies to stats and level, which are recalculated based on Experience.<br>
Thus, there are also 33600 (14*30*80) bytes stored somewhere else in the GBA's RAM to save data on Pokémon in the PC.
Thus, there are also 33600 (14*30*80) bytes stored somewhere else in the GBA's RAM to save data on Pokémon in the PC.
When the VBA's saved state (including memory contents) are ungzip'ed into a 740,000+ byte file and viewed, the 14 boxes of 420 Pokémon are stored in the general region of $038000 $040000.


[[Category:Structures]]
[[Category:Structures]]
[[Category:Game mechanics]]
[[Category:Game mechanics]]
Iliekmudkips
77

edits

Retrieved from "https://bulbapedia.bulbagarden.net/wiki/Special:MobileDiff/191924"