Kaphotics

Emulator is misbehaving by not giving you a fresh save data when initializing.

Restore a backup. PKHeX automatically saves a backup of every save file you load into the program.

The games will always update the abilities back to whatever their correlation requires when evolving. Ability index is the lowest bit of the upper half of the PID for Gen5 origin, and the lower half for previous games, just like PKHeX checks for.

Ruby: 1110000100011000, discarding 7 bits (use the >> operator in the calculator), is Since Version is only 4 bits, the lowest 4 bits are 0010, which is "2", for Ruby. For your Mew: 399E is 00111 0011 0011110; 0011 is "3", for Emerald.

If read as a 16-bit number, it is 0xE118. https://en.wikipedia.org/wiki/Endianness

If you are reading the data from a save file, then you need to jump through the same decryption & shuffling steps that the games use. Dumped PKM files can be whatever format the program wants to dump them in, and it's most convenient to dump things in the decrypted and unshuffled state. Compare your output to what the game displays (or other programs) to test your implementation. You can even write unit tests to assert that you are reading the expected values from the structure.

1. Anything that can be transferred from GO can exist as a dumped file. But it doesn't make anything notable enough to need to upload to the site. 2. You answered your own question.

https://projectpokemon.org/home/files/category/221-pokémon-go-home-transfers/

Each set of games stores data in its own format; while there may be similarities, offsets can differ. You need to identify which format(s) you would like to support, and implement readers for each. Species can be read as an integer, then localized to whatever language based on a string list for that language. Nickname can be read from the data, depending on how the game encodes strings (gen6+ use UTF-16 with \0000 terminators). There are quite a few open source implementations in various languages; here's a Python one for LGP/E which is the "Gen7b" format of PKM data. https://github.com/Lincoln-LM/PyNXReader/blob/cb15cf5935fdcb8de9b8a9c268d87bc161d3af9a/structure/PK7b.py You'll need to break down each of your "needs" into smaller and smaller needs. Parsing the nickname? Need a reader, and need the offset to get the Species ID, then need a list of strings to localize the value to a display string. Parsing the ball? Need a reader, and need the offset to get the Ball ID, then need a list of strings to localize the value to a display string. See the pattern and reusable parts? I would recommend opening a pk* file in a hex editor, so you can "feel" what you're actually telling the program to do. Files are just data, and understanding (without code) how that data is stored is essentially a prerequisite to understand what you need to reimplement your understanding as code.

No.

Depends how much you want to read, and which formats you wish to support. pk* files are normally saved in their decrypted & unshuffled state. You can probably ignore that, but here's gen4's reference. For reading the byte array into a structure, however you want to do it. To read species, you need to read it from the correct offset. Gen6's reference. Converting to json isn't really advisable; there are so many properties.

Because you have not saved in-game prior to taking that save file off your device. Try it on literally any other editor and you'll get the exact same result, indicating it's not an issue with the editor.

You need to save in-game and not rely on save states to retain your progress.

Going from a long name to a short name would result in leftover text, hence trash bytes. The program is merely saying that the data it expected isn't there. It is "fishy" because it is possible to progressively rename it one character shorter at a time, thus having no trash bytes. But people do not really do that.

PKHeX does not support ROM hacks.

Anything is possible, you can always try it and see. It is usually better to start over when changing immutable values about your trainer data.

I recommend finding another working save file for Emerald, then just copy that file's Block 4 to overwrite yours.

You can backup NDS saves using Checkpoint to your SD card, then use FTPD (or the MicroSD management if it's a New3DS) to wirelessly transfer the file between your computer and console.

Why can't you just edit the dumped Diamond save file and drag & drop between PKHeX windows? The program will convert for you; no need to manually try and recreate all the details.

Oops, I forgot to fix the checksums. Just take the file I uploaded and open & export within PKHeX to have it fixed. (also attached a "fixed" one since I did it anyway) Pokemon - FireRed Version (USA, Europe) (Rev 1).sav

Use PKHeX's encounter database to create one from template. Changing the PID/IV afterwards to something you prefer would require you to have a valid PID/IV in mind, which would require using an external tool to search for one.

Not a valid save file / ROM file dump.

Actually yes; block 4 is the tail end of the game progress block. You can try zeroing that block out and re-exporting with PKHeX.

Blocks A-D are stuck with an old revision (18) while the rest of the save blocks are at 29-31 Other than that, we can do the same rebuilding/rearranging of blocks to create a new save file (attached). Pokemon - FireRed Version (USA, Europe) (Rev 1).sav

Block 4 is the first box & half of box 2. Every other block is present, so everything about game progress is there. I uploaded a fixed save for you