codemonkey85

Well according to Bulbapedia, the Pokemon data checksum "is computed by simply adding all the unencrypted values one word at a time". Are you having trouble doing that?

It's safe to say an invalid Gen V species will not be allowed into Transporter.

It is true - the whole reason we use decrypted PKM files is because COM (creator of Pokesav) did it. He didn't do many things correctly, but we learned some of his bad habits all the same. Really? Cleaner than just defining the binary layout in a multi-tier structure then creating a pointer at the memory location of the save file? I find my way so easy to work with in code! struct pokemon_obj : pkmunencryptblock,pkmblocka,pkmblockb,pkmblockc,pkmblockd {}; //... struct box_obj { // size: 0x1000 public: std::array<pokemon_obj,30> pokemon; // uint16 : 16; uint16 checksum; byte buf[0x0c]; box_obj() { memset(this,0,sizeof(box_obj)); } }; //... struct bw2savblock_obj { // //... std::array<box_obj,24> boxes; // size: 0x18000 //... }; Then I get to do nifty stuff like: std::cout << "The Attack IV of the Pokemon stored in Box 1, slot 1 is " << sav->cur.boxes[0].pokemon[0].ivs->attack << "\n";

I know enough about Pokemon GBA save files to tell you a hex editor is going to be pretty useless here. Pokemon GBA save games are divided into a number of blocks, which are rearranged to be "out of order" so that the data you're looking for won't necessarily be where you expect it. Plus, even with an unscrambled save file you'd still have to fix all checksums before the game recognizes any changes.

So pkm is the byte array containing the PKM data and 0x38 is the offset for the IVs, right? This is the syntax for BitConverter.ToUInt32: 'Declaration <CLSCompliantAttribute(False)> _ Public Shared Function ToUInt16 ( _ [b]value[/b] As Byte(), _ [b]startIndex[/b] As Integer _ ) As UShort This is what you are doing: UInt32 Stats = BitConverter.ToUInt32([b]ARRAY[/b], ([b]startIndex[/b] << 0)); See the problem yet? You're shifting the index, not the value at that index. You need to fix your parentheses, I think: UInt32 Stats = BitConverter.ToUInt32(pkm, 0x38) << 0); You do realize [0-31] is the range of values, right? That doesn't go in your code.

Agreed. Any more posts about "what's the point" will be deleted - this is now a contribution thread.

Nintendo 3DS Friend Code: 2750-1320-9316 Pokémon Y Name: Mike Friend Safari Type: Electric Friend Safari Pokémon: Pachirisu Helioptile Galvantula

Seeing as the hexagon is used to represent the Kalos region in other places, this makes sense.

I know a guy who is working on an open source library dealing with save files across every generation. I'm sure his implementation would have no problem handling your use case. https://github.com/ncorgan/Pokemon-sim If you were a programmer, this would be a great place to start.

People, remember what Bond, said. Direct contributions only. This is still a work in progress, and when it is ready for people to use you will know about it. If you don't mind, a better use of your time and resources would be to document the index numbers of new moves and new abilities as you dump the data.

If you're referring to 0x04 - 0x05, I believe those were runtime flags in the previous games that indicated whether or not data was encrypted. One was for box data and one was for party data.

I'm not. Anyway, thanks for this! I threw it into the veekun spreadsheet for the time being - which I highly recommend people refer to when trying to discover new items and things.

The move IDs of moves from previous generations are most likely all the same index numbers as in previous generations (they have been so far anyway). For reference: http://bulbapedia.bulbagarden.net/wiki/List_of_moves However, if you wish to contribute index numbers for new moves, by all means...

Yikes. Thanks for the head's up. Good luck man. I think we're all pretty excited to start getting some real data (well I know I am).

Pretty sure it's 4.0. The backend library is vanilla C++ so I could compile a version for Linux / Mac if people need it. This is just a bare-bones editor for those experimenting with the new format. If you want something polished... wait a while.

Here is a link to the PKX Editor I have created: https://www.dropbox.com/s/bmklyrwq4lwsv7q/PKX%20Editor.exe

Any chance you could upload the straight binary data? I've been curious about these but haven't gotten properly setup to get them. EDIT: In case it's any use to anyone here: as of now the backend functionality for the PKX editor I've been working on is done. All that's left to do now is rearrange the UI and add labels so things actually make sense. I modeled my program after the structure reported by Mat and Xfr, and verified myself that encryption and shuffling work, so anyone who's been able to extract / inject PKX files should find this helpful. The source is on my GitHub (https://github.com/codemonkey85/PKMDS-G5/tree/master/PKX%20Editor). I'll post a binary (for Windows only) later. It will require the .Net Framework for the time being.

Something interesting I noted today - it doesn't look like unicode names like OT name and nickname have terminators (FF FF) anymore.

No.

Well technically... But for the record I think opening this functionality up to the public is a terrible idea.

For that matter I have also added the structure and encryption to my PKMDS library on GitHub. I plan to spend some time figuring out where more of the data is (ribbons, etc.).

Thanks to Mat and Xfr, I have added very early support for Gen VI PKX files - the general structure is outlined and the encryption / shuffling is supported at this time. You can find the structs and methods in pkmds_g6.h and pkmds_g6.cpp.

Well we could just modify some PKX files (the species ID specifically) and send them back to the game and see what happens. If there are any additional Pokémon to be discovered, this seems like a way to get it done. For that matter the same thing applies to items / Mega Stones, etc.

I updated the veekun-pokedex.sqlite file today. Find it at its new home on Dropbox: https://www.dropbox.com/sh/2etuv926vyey5ou/jeAXk1qDXc

Just a quick notice - I updated the Qt application to include some memory fixes (thanks to a Githubber named Antidote). You can grab the update at the usual link.