Codr

Yes, both things could be done. This has actually been requested before, but I still don't understand the point of producing multiple PIDs.

I just updated PokeGen's code generator to produce a shorter code that will work on the Action Replay with full customization. There was an issue with the way it was previously writing the data, and that error is present in Bond's modified code as a result. I suggest using beta 28 of PokeGen now.

A few errors were corrected after the original upload of beta 28. If you're experiencing issues with codes, redownload the program. 3.0.0b28 FIXED: Black/White Pokédex codes were writing extra data where they shouldn't have been. The extra data was harmless as far as I can tell. It may have overwritten the save count for the save file, however. FIXED: Dragging a .pkm file into a slot would cause that slot's data to not be updated in the save file. (Found by Cuber.) FIXED: Location lists for French and Italian had some entries listed as ((null)). They're now the appropriate values, although French is still untranslated. FIXED: Changing languages with the target game set to Black/White would cause the box list to be limited to 18 instead of the intended 24. FIXED: A typing error in the update code was causing the socket to be closed and reopened unnecessarily. FIXED: "Seen all" in the Pokédex was causing "Caught" to be flagged on all Pokémon. (Found by Sjru.) CHANGED: The code generator no longer combines codes. Instead, each code is selectable from a list after being generated. For XML files, each code is also separate now. CHANGED: Code names in the XML file are now more verbose. CHANGED: Pokédex codes are now significantly shorter and will function on the Action Replay hardware.

This will be fixed with the release of beta 28. Some other problems and resolutions were found/made to warrant a release earlier than I expected.

You don't have to export anything. Desmume saves the save file to a .dsv file (as was mentioned) in the folder you have configured in "Path Settings" for "SaveRam". If you're loading your game with a save state, you're not utilizing the save file and obviously won't see any changes.

PokeGen doesn't do this. "Tapping" the Pokemon image does.

...Bond says his code works on the AR?

That wouldn't be possible in a lot of cases due to there not necessarily being a large group of consistent bytes to write.

Bond isn't copying completed source code and presenting it as if he created it. So because it's free, there has to be no respect for someone's time and effort? Also, the argument "it's free, it's ok" is pretty easy to interpret as expressing guilt.

It can only be shortened by about 167 lines at most. You simply can't remove data without removing the guarantee that everything is written as it should be.

That option only refers to the save file checksum. It has nothing to do with the checksum involved with Pokemon data.

Yes, I haven't gotten around to it yet. Not that a release is likely soon.

This thing has garbled data in the box slots. Again, this isn't PokeGen's fault.

Wondercard support is actually on the table right now. It's just waiting on the fix for language display. I don't agree that adding more makes it more "bogged down" if it's done in an unobstructive way. The tools menu, for example, is basically out of the way, yet can have whatever added to it without consequence.

You don't have to leave the PID finder blank. The game doesn't care what the PID is. A Pokemon can't NOT have a PID, so of course PokeGen gives it one regardless of what you do. No data is hidden. The game doesn't care what the extra bytes are set as, if that's what you were referring to. The PokeGen section is NOT for getting help with "legality" issues, since that's very clearly what you're asking for here.

It's not intended to mark them as caught too. I just never noticed it was happening.

Obviously not, it's not doing what you're wanting. My tests say otherwise. I'd be interested in seeing exactly what steps you took from opening the program to produce the "incorrect" result. Since you're intent on being offended by my claims, let me explain something for you. They don't come from arrogance. They come from comparisons. Even setting the layout of the two aside, PokeGen does everything properly and has things that Pokesav lacks. (Speaking strictly from a Pokemon-editing point of view, as I always have on this topic.) All I can say here is "wow, wtf". Or perhaps the way someone who has to constantly deal with people not helping themselves with the slightest bit of common sense. This includes lazy/stubborn people. This has (mostly) nothing to do with the size of the dialog. I'll put it simply and say that dynamically sizing the controls to allow for text of varying widths from different languages to fit isn't the easiest task ever. Also, let me point out that this is already documented, had you bothered to look. I do accept opinions of others. However, there are times when people aren't even considering alternatives. This happens often. I can't even respond to the attitude comment because it's so ridiculous. How many of these people have taken the time to figure something out for themselves before posting? Very, very few. Nobody here is obligated to treat them well at all, and certainly not for trying to use someone else's time to save their own.

What I said is true. People are the same way with upgrades of software ALL THE TIME. They don't want to take the minimal amount of time it takes to learn to use something new, or they have some arrogant idea that what they're using is somehow superior despite everything saying otherwise. That explains everything. I couldn't help myself. I had a feeling that I knew what was going on, and I was right. Your pointless devotion to Failsav is your problem. Pokemon data has a bit that indicates gender, along with the PID. Why it's like that, I couldn't tell you. After testing with, you know, the superior program, I determined that Failsav doesn't set this bit properly based on the PID you provide. Your PID may have been saying male, but the bit said female, and apparently the game uses that bit to determine how the Pokemon evolves, not the PID. PokeGen doesn't fail in this way, so if you want properly-generated Pokemon, use it and stop being stubborn/lazy.

Wanting to use Pokesav is nothing but stubbornness, laziness, or both. There really is no reason to use it for editing Pokemon. It has NOTHING that PokeGen doesn't, and has less, actually. (Btw, this is for your claim of the lack of "type" 1 or 2.) I guess this is easier to read than an intelligently formed sentence too right? No. Its layout is not better by any definition. As for the actual problem, I honestly don't know, without looking it up, how Burmy works for sure. So I can't really say what's going on if it's not a PID issue. (Assuming you correctly dealt with that.)

I'm only responding because made me laugh. The PID controls gender. (At least as far as evolution is concerned.) Pokesav has no option for this, unless I missed it. (Which is certainly possible, given that the layout has no logic applied to it whatsoever.) So... use the superior program and do what you want easily.

Oh, from a file into a box. As usual, I missed that the first time I read it. Yes, that wasn't properly fixed with the rest of those changes. Edit: It's fixed in the next version.

Are you using beta 27?

The notion of the two words being different is idiotic. The source of the data is completely irrelevant. It only matters to people who can't get over the concept of data not having a "soul" attached to it.

This is actually one of the things that's high up on the list. It could use some updating, that's for sure, but I hadn't really given it much thought. It's tricky to determine stuff from codes accurately.

There are things planned. It just takes time (sometimes lots of it) when working on the program isn't someone's primary goal with their free time.