SciresM

...did nobody read my post that said they're Big Endian PK4s? That's a well-documented format....there's no need to research how they're stored, I already said that.

Hey, there. I've started the process of implementing Gen II support in PKHeX, following my just adding Gen I support. I'm currently working on implementing save file loading/reading for GSC saves -- this is easy for English games, because bulbapedia documents save offsets well for those here. However, Japanese offsets are not so well-documented; I'd like to ask, then, if people could help out by documenting them while I work on implementing the other features required for PKHeX's Gen II support. The Japanese offsets that need documentation for full PKHeX support (both GS and C need offsets): -TID -OT Name -Daylight Savings -Time Played -Player Palette -Money -Johto Badges -TM Pocket -Item Pocket -Key Item Pocket -Ball Pocket -PC Item list -Current Box Number -Pokedex Owned -Pokedex Seen -Player Gender (Crystal only) Strictly speaking, Checksums also need their offset located, but I can take care of that when the time comes.

Someone just has to make an editor, really. As I commented on reddit, Pokemon are just 140-byte unshuffled, Big Endian PK4s. Also their checksums are different, but you could surely reverse that with dolphin if you were so dedicated.

That was, indeed, the case, but then I also wasn't interested in adding Gen 1 support to PKHeX

I wouldn't bother -- I will be adding Gen II support to PKHeX following my finishing Gen I support. I'd also like PKHeX to be "the tool" -- and so the more people wanting to improve it the better

I mean I'm not opposed to updating it, but I'm also not really sure what there is to add? I'm pretty satisfied with Rhydon. Behind the scenes, PKHeX may or may not get Gen I/II support, but I'd bet against it.

Yeah...I'd be happy to implement it, but I can't think of any sane way to differentiate them?

If you edit the nickname/OT, the 00 bytes will go away (and the mew will become illegitimate). If you don't touch the textboxes, the 00 bytes will be preserved.

Haha, not a checksum issue. I recognize saves by checking whether or not their boxes are valid -- turns out this fails if you've never switched boxes. Now recognizes by Party/Current Box validity. Re-download and it should work. I attached the mew from that save, by the way -- interesting that it has all 15 for DVs. I am very amused by the idea that any mew with less than perfect DVs in a Gen I save is illegal. There's also the neat fact that its name/OT has 00 bytes between the JP characters and 0x50 terminator -- that's not the case for any game generated pokemon. tl;dr: Mew glitch Mews are differentiable from event ones.

Saidon corrupts saves due to invalid checksum calculation. That said, I've just added preliminary JP save support to Rhydon. Stuff might be broken -- test it, and let me know!

I don't know how pikasav does it, but I implemented a pk1 as a pokemon list of capacity one. That seemed the most straightforward way to do it, to me.

Eh, those problems are way easier for me to deal with than the lack of offset documentation. I wish I was joking.

Yeah, that tells me where the party is. Now I just need all the other stuff listed here, heh: http://bulbapedia.bulbagarden.net/wiki/Save_data_structure_in_Generation_I

This came about from my implementing Gen I pokemon reading (so that PKHeX will be able to easily convert from Gen I -> Gen VII when Sun/Moon release), and when I realized that the current Gen I save editors have pretty bad UIs. Hopefully it's useful to people!

This is a new save editor for Pokemon RBY, loaning its design (and a lot of its internals) from PKHeX. Open or drag/drop a Gen I save file or a .pk1 Pokemon file, edit, then export the sav/pk1. Currently (as far as I know) only supports US save files, from game cartidges, emulators, or the 3DS VC re-releases. If someone can link me to documentation of the JP save offsets, I'd be happy to add support for JP games. Using the original RBY-style sprites can be toggled from the options menu. Source Code is available here: https://github.com/SciresM/Rhydon And you can download it here: https://github.com/SciresM/Rhydon/releases More images:

Re-download from the first post

Fixed -- Updated exes are available in the first post.

Would you mind joining the PPorg irc to help me debug this? http://projectpokemon.org/irc/

I'll look into it. What's up with your UI, by the way? The text shouldn't be cut off...here's how it looks on my end:

Well, I'm sure most of you thought I'd never do it, but I did it. Modified version of CGSE's updated.

Right, I should probably pay attention to this Anyway, .img is the same as in previous games, FARC struct is update (no more file name tables ) so my extractor doesn't work for all files. A hack got it working, but the files aren't in any meaningful order...needs some work. I still need to update CGSE before I can seriously take a look at this stuff (and I'm kind of swamped with work...it might be a week or two), but in the mean-time:

Literally all that needs to happen for a new version of the modified editor to be posted is "have someone contact SciresM on the pporg irc". I didn't know there was an update, so I haven't updated the modified program. I'll go do that now.

I already have a complete FARC extractor and .IMG converter...I made it forever ago when I uploaded all of GTI's portraits to vg-resource: http://www.spriters-resource.com/3ds/pokemonmysterydungeongatestoinfinity/sheet/63215/

Wrong. I have successfully used ram2sav on AS 1.4 and Y 1.5.

No, all pokemon have that magic PID value. It's not actually used. There's a byte that determines PID generation, and that value is only used if the PID generation byte is set to "Custom". And the dates are random because the sources I got them from actively try to avoid matching the eventual powersaves date.