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.