Talk:Save data structure (Generation II)

Split

The character encoding is not a unique feature of the save data structure. It is used by basically any string in the ROM. Trainer data structure in Generation II uses it and there are other data structures which could be given articles which would also use the character encoding. The character encoding simply does not belong in a section here on the save data structure page. Tiddlywinks (talk) 03:52, 1 April 2014 (UTC)

Seconded. If Character encoding in Generation III gets its own article, then this should as well. Sidnoea (talk) 02:47, 25 December 2014 (UTC)

Thirded. This should really just be donoe at this point - I was trying to find the Generation II charset, and neither the wiki search nor Google could help me. On its own page, it would be much easier to find It would also be much more fitting, as the charset has bearing on more things than just the game's save data. I would move it myself, but... it seems I can't create pages. LpSamuelm (talk) 09:15, 18 April 2016 (UTC)

It's actually been approved for a while, I've just been reluctant to split it off without revisiting it to make it better...somehow. I've gone ahead and split it now, though. Tiddlywinks (talk) 17:12, 18 April 2016 (UTC)

Errors with the data structure / discrepancy with Crystal ?

I have begun checking my Crystal save file just for laughs, and it seems that some entries are not described accurately.

Example :

Ball list :

The map says it begins at 0x2465 with a different ball type Count byte, and then with pairs of two bytes such as NN TT where NN is the number of the object and TT it's ID.

My ball list is currently only 93 Ultra Balls. (thus, count 5D and ID 02)

The thing is that at 0x2465, I get a null byte and then 02, 5D and the terminator for the whole list, FF.

Thus :

00 02 5D FF 00 FF 00 FF 01 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

for the whole list.

After buying twelve Great Balls, this is what I get at offset 0x2465 :

01 02 5D 04 0C FF 00 FF 01 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This means that the count is always -1 of the actual amount and that the item descriptor is of format TT NN instead of NN TT.

It seems that the item bag has the correct count variable (as 19 items translate to 13 in the first offset) but it also uses a TT NN format instead of the described NN TT.

All in all, I believe that there are subtle differences like those between crystal and G/S.

If I missed some endian-ness subtlety, feel free to let me know, all I strive for is to perfectly comprehend how the saves work.

Splatpope (talk) 23:40, 16 April 2015 (UTC)

Well, that's weird... I started a Crystal game and after getting Poke Balls at Elm's lab (and tossing one so I have 4), I checked the save file, and at 0x2465 it says:

01 05 04 FF

My regular items list says:

04 12 01 09 02 AD 02 4A 01 FF

where I have 1 or 2 of a few items. So, for me, it looks like it's always item index then count in an item list entry.

Are you playing an English version of Crystal? Tiddlywinks (talk) 01:33, 17 April 2015 (UTC)

To clarify :

The article claims that entries in an item list are of the format NN TT (0x2466 and 0x2467 for the first item) where NN is the number of items and TT their ID.

What I observed is that they rather are stored in the memory with the format TT NN.

It seems the only difference between our observations is that the total counter at the first byte of the ball item list represents the correct amount in your case, whereas this byte is always one less that the actual amount in my case. Which is strange.

I am playing the following ROM : "Pokemon - Crystal Version (UE) (V1.1) [C][!]" in english, with this savefile : Crystal Savefile

Who knows, maybe you have 1.0 ? Maybe my emulator is messing things up ? Maybe I'm mad ? :v

Splatpope (talk) 13:50, 17 April 2015 (UTC)

(Horizontal lines are not a great way to separate comments; that should be reserved for sections. Responses should be indented one step farther than the previous one.)

I did get a little confused, for some reason thinking that your Ball pocket items were "NN TT" while your regular items were "TT NN", but I understood what you meant about what the article currently says. =P

I've found a "Rev A" that also matches that "Ver 1.1". And comparing that ROM to the original, the first difference is in the game's header, where the version number is indeed 0x01 in Rev A/Ver 1.1 and 0x00 in the one I played (and the next three bytes sound like checksums or something, so they're different too). After that, there appear to be a relatively small number of differences in a few places, except between 0x172EAD and 0x17368B where there seem to be a bunch of differences. I don't at the moment know whether all the differences are in code or if some of them might be data structures.

Anyway, I did the same thing in Ver 1.1 (4 Poke Balls) and got this at 0x2465:

01 05 04 FF

And at 0x2420 (regular items), I have:

03 12 01 09 02 AD 01 FF

(I missed a bit compared to before.) So, it looks alright to me. I'm playing the ROMs on Visual Boy Advance. If you're using a different emulator (or even—maybe especially—if you aren't), maybe you could start a new game ("temporarily") and do what I've done, and see if you still get weird values written in your save file or if you get the same thing I did; perhaps it's a bug or something that only happened because of some specific circumstances in your current save. But if it still looks weird, I guess it'd have to be something about the ROM you have, or (remotely possible?) about your computer somehow. Tiddlywinks (talk) 17:22, 17 April 2015 (UTC)

°°°

Starting a new game with the same rom on VBA-M until the point where Prof Elm's assistant gives me the 5 balls gives me a correct first byte for the ball item list. At this point, I think there's something shady happpening during the game at some point that causes it to be different, I'll test a new game on my regular android based emulator and see if a new game gives us anything good.

Could you verify a 1.0 savegame and see if the string for the Unused Red's name is at the correct place ? In my saves, it appears at 0x202C instead of 0x201C, right after the string for the Rival's name.

Actually, data is arranged like this :

NN ... 50 50 50 50 ...  86 91 84
91 84 83 50 86 91 84 84 8D 50 8C 
86 91 84 84 8D 50 8C 8E 8C 50 CD
(separated in 11 bytes intervals since that's the length of those name strings)

Where NN are the bytes containing the rival's name.

It spells :

*RIVAL'S NAME* - terminators - "GRE"
"RED" - terminator - "GREEN" - terminator - "M"
"GREEN" - terminator - "MOM" - terminator - (anything after and including CD isn't string data)

Needless to say, none of those unused names are referenced at their right place in the article.

I really believe that all content of this page pertaining to Crystal should be verified and compared between version 1.0 and 1.1

Splatpope (talk) 23:08, 17 April 2015 (UTC)

As far as what you wrote above, I don't see any (significant) difference with 1.0. (Fun fact: it looks like the game initializes the non-player names by copying 11 bytes from a place in the ROM. That explains the repetition of names, and also the random data after "MOM".)

You're right, it should be checked. It's also worth considering, though, that those unused names were added by one person. What I mean is, it's always good to check; but in this case, it's also possible that the unused names (and perhaps Options) are the outliers. Tiddlywinks (talk) 01:08, 18 April 2015 (UTC)

Daylight savings offset

I'm using the German version of Pokémon Gold to test things with and play around and I found the daylight savings offset to be 0x2050 instead of 0x2037.

Changing the dst at mom's does not affect 0x2037 but instead 0x2050 switches between 0x10000000 and 0x00000000, so I guess it might be correct. - unsigned comment from Meta (talk • contribs)

Adding explanatory sections for Money and Trainer ID

My recent changes to this page were removed by Tiddlywinks, and I do not understand why. The explanation given was "Anyone's who's wandered in here and can understand any of this is likely to understand simple binary numbers just fine." The point of my changes is to explain things so that people who are new and don't understand it.

It is not obvious at all, unless you've been working with sav data before, that the money or trainer ID are stored as multiples of powers of 2, for example. Try to remember what it was like when you were first starting to decipher save game data. The entire point of this page is to enumerate its structure.

Building a sav game editor now, it would have been helpful if this page had information on these missing categories. They didn't, so I figured it out myself and wanted to contribute that back to the community.

Here is the the diff. How is the lack of information better? Thank you for the feedback.

GgNkLhjBmLgjOmEVEnzK (talk) 02:22, 22 February 2016 (UTC)

Near the top of the page in the first section, it says:

Unless otherwise noted, integer values occupy the specified number of bytes, and are big-endian and either unsigned or two's complement.

with links to the Wikipedia pages on those topics. It's already stated. What you added is the definition of unsigned big-endian. --Abcboy (talk) 02:28, 22 February 2016 (UTC)

Ah, I understand now. I am not used to working with hexadecimal. It's fairly obvious now, but it wasn't when I started a few days ago. What do you all think of adding a little example up in the first section? Yes, there are links to Wikipedia pages, but the problem with those pages (and Wikipedia in general, particularly for technical subjects) is that they are not very useful unless you already are familiar with the concepts. A short, worked example takes up minimal space and would complement the definitions well. GgNkLhjBmLgjOmEVEnzK (talk) 04:42, 22 February 2016 (UTC)

I just think it's not our job. It could perhaps be plainer than "big endian" and "unsigned"/"two's complement", but, if, say, the concept of RGB came up in an article, we wouldn't try to explain it right there in detail, we'd just link out to RGB and that'd be fine. If anything, the solution would probably be in better links (like perhaps Integer (computer science) or binary number). Tiddlywinks (talk) 05:07, 22 February 2016 (UTC)

Where's the Pokegear Stored?

The save file structure doesn't include any section on how the pokegear phone numbers are stored. The options is pretty big (8 bytes!), so are they stored in there? In fact, why isn't that section talked about at all? What settings go in there?

Kanto Badges

In GS, they're right next to Johto Badges, not sure about Crystal. Eridanus (talk) 08:37, 2 April 2016 (UTC)

Checksum Inconsistency

The following statement appears in the page:

Normally, Pokémon are deposited and withdrawn from the Current Box list, which is within the checksum-validated region of the save data. When switching boxes, the data from the Current Box is copied to the corresponding PC Box data, then the data from the switched-to PC Box is transferred into the Current Box data.

However, the text of the page indicates that the checksum region covers 0x2009 to 0x2D68, and the PC box list starts at 0x2D6C, so they clearly do not overlap. From my own independent tests, the checksum formula and memory locations are correct, but the clause "which is within the checksum-validated region of the save data" should be removed. Isharacomix (talk) 10:40, 27 July 2016 (UTC)