codemonkey85

Thread unlocked. Feel free to re-post links after confirming that they do not link to pirated material. (I didn't notice any when I glanced through them, but just be sure!) Also, good luck with this, as it is beyond my knowledge. :\

Ah, that would make sense. I'm willing to bet that's how it works. tkdtju, why don't you just add the Pokémon you want to add, and use PPSE to edit the 'Dex? Seems like it would be a lot easier.

Whoa. That's awesome! Great to see progress being made on this. Regarding our own private GTS servers, I think that would be awesome for ROM hackers trying to create their own Pokémon "economy".

Um? So you mean if you (somehow) used Pokesav to capture a Starly in the Pal Park, bearing in mind Starly cannot legally be found there, you want to know where that Starly will show up as "caught at"? Pokémon from the Pal Park typically show up as being either from Kanto or Hoenn, but for Starly, I'm not sure what would happen. You'll probably get a glitched out summary, or perhaps it will say it arrived from Sinnoh. I dunno. Why exactly would you do that anyway? In any case, the Pokémon would be registed in the Pokédex in the same way no matter where you caught it.

Well, my theory was always that the Pokémon were stored the same exact way on PBR that they were on the NDS, but when I looked at the data on the Wiimote, I could not for the life of me locate or make sense of any Pokémon data. I figured at that point that the data was encrypted a second time by the Wii. I know that data stored on the Wiimote is usually not encrypted, so that makes me think it's PBR that encrypts the Pokémon. And then on top of that, the Wii save file itself is, as Poryhack said, also encrypted. So getting to that Pokémon data is, um... challenging.

The Gameboy Pocket was not a new console, it was a redesign of the original system. The Gameboy Color, on the other hand, featured new hardware, like a color screen, an IR transmitter / receiver, and an updated graphics engine. Just a nitpick. I dunno, I kind of like two screens. Since the DS folds down, it's a nice way to get more screen space without sacrificing portability.

Nor would I, unfortunately, especially considering the project idea I once had for transferring Pokémon between a Wii remote and a PC via bluetooth. Bear in mind that the Pokémon in the PBR save file are also (probably) encrypted and shuffled in the same manner as on the DS games, so locating the Pokémon and figuring out the encryption scheme is probably even harder than already stated. :\

And I maintain (until I am proven wrong which is likely) that the (inferred by me) ambiguity of the term "Nintendo DS title" could lend itself to the next-gen Nintendo DS. Assuming the naming convention goes that way, which, given the plethora of Gameboy platforms, seems plausible.

Hey guys, here's some more stuff!

Good point. Also, hey, what's this?

Actually, I think Mewtwo_EX (or someone) posted that info before I even put this article out... and I didn't even notice it until after it was too late. However, technically, could they be referring to a new DS? A DS II or something? I don't read Japanese, so I dunno how subtle the difference would be between referring to the current model and a hypothetical new one. Any thoughts, Guested?

Yeah, but it's probably not a bad idea to link to the original source, which I didn't do.

You guys don't realize that the game card architecture is rather different for HGSS, as compared to previous NDS Pokémon games? 'Cause it is. And as a result, the methods for backing up retail saves that worked before do not work with the new carts. Don'tcha think Poryhack would not have started this thread if they did work? From this post forward, any posts that refer back to old methods of save-backing that don't work will just be deleted. EDIT: I find that a bit odd considering how immensely popular HGSS is / was. But then again, perhaps someone will pick up the pace once the US versions are released and a ton more people have the actual hardware in their hands.

You want ROM Editing, actually. This would alter the game's code itself. If you manage to link to someone else's game with your modified game, only you would be able to see the changes being made to the sprites; as for the types, I'm not really sure what that would do in a linked setting. FYI, this has nothing to do with whether you're playing on an emulator or a console.

Well, don't let your project get in the way of your homework. And FYI, I'm generall most productive during the day, when I can think more clearly because I'm not falling asleep at the computer. Let me know if you have any trouble writing out the RNG and stuff.

There aren't any "traces" from importing your save from an R4 to a retail cart, as far as I know. And saving twice won't necessarily remove any "traces" anyway; as I said before, we don't know the full structure of the save file. Some things may never be overwritten even by a full save. As for Pokesav, I can promise you that it doesn't work 100% the way the game does in terms of reading and writing save files, so there's always the chance that it can mess something up. I can also tell you that I have personally written software that loads and saves files in a more accurate manner, but my software is still prone to errors I may not even know about. Like I said, if you're in doubt, just don't do it. EDIT: I second everything Poryhack says.

greentea, I think you should go back to those links from my earlier post and read the information on the wiki carefully. The last one I posted was a link to the exact functions used to determine which blocks are more current, and there is nothing to do with a date. To wit: Bear in mind that the Hall of Fame block had not been thoroughly examined when I wrote this, and for all we know the footer is checked for that block as well. However, the information there is only written to when the Hall of Fame is being updated right after a victory against the Champion, so it tends not to matter much.

But like I said before, you really need to look at both halves in order to determine which one is more current. After you figure that part out, then yeah, for your purposes you will only work with the current half.

If the feed includes a link back to the original post, then it would be just fine! Most posts are just text anyway.

Don't forget guys, the hardware that Miyamoto was referring to is still being speculated. We don't know for sure if it's a new home console, a new handheld, or what. Heck, they could be building a new E-Reader for all we know (hope not!).

That's not quite right... the save file is split into two equal halves. One half is a backup of the other half. Each half consists of three blocks; one "general", one "storage", and one "hall of fame". (It sounds like you had the right idea though.) I think you need to at least check the footers on those blocks to make sure you're reading the correct information though, as they are all linked together in one half of the save file. Don't forget that one of those storage blocks is not "current", and is only a copy of the previous save. The two blocks should not be expected to be identical. Also, each storage Pokémon is 136 bytes long; the first eight bytes are unencrypted data (the PID and checksum basically), and the last 128 contain the encrypted data, which is everything else. Once you apply the RNG to each 2-byte (not bit) word, you can split those words into the unencrypted bytes. The data should be the same length, just now it is unencrypted. The "pv" is the personality value, or the PID, of the Pokémon in question. I'm not entirely sure what this question means, but you apply the shuffling algorithm to the encrypted data only, so you skip past the first eight bytes and unshuffle the remaining 128 bytes in four groups of 32 bytes each. That's the idea.

Personally, I don't think a record of arrays hardcoded into the software is a good idea. I think you should look at doing a binary database, which can be small, fast, and easily updateable / extendable... not to mention I believe using arrays would cause your program's footprint to be much larger than necessary.

If that's your goal, then I suggest you build a Pokémon class structure to hold the properties for the stats you are interested in. Then you could build a fairly simple search algorithm to seek out and / or sort those properties by their numeric values. In my software, it looks something like this: Dim PKM As New Pokemon = SaveFile.StorageBlock.Boxes(0).StoredPokemon(0) If PKM.IVs.Attack = 31 Then MessageBox.Show(PKM.Nickname & " has a perfect Attack IV!")

Wow, that was quick. I see there are RSS feeds available for the forums. Nothing yet for individual threads, but awesome progress!

Very true, although it sounds like greentea is only (currently) interested in the Pokémon themselves. The save file in its entirety is, as we all know, quite a grand undertaking. Heck, Diamond and Pearl have been out in Japan since September '06 and we still don't have their save file mapped out entirely yet.