Kaphotics

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

Block 4 was missing from both main & backup, so that section of box data is gone. Other than that, we can do the same rebuilding/rearranging of blocks to create a new save file. POKEMON_EMER_BPEE00.sav

The script you linked is old and does not handle the fixed gender requirements of the starter Espeon and Umbreon (both of which must be male, and never shiny). Since Eevee is 87.5% male, statistically it'll be "right" more often than not, but it will produce inaccurate results frequently. It works for Eevee, simply because Eevee is not locked to a single gender (and can be shiny). "locks" are a community term for requirements/disallowed features. In this scenario, a "gender lock" is when a Pokémon is only to be generated with a specific gender, and the game generating loop is locked in a repeating loop until it meets the criteria. When an NPC's team is generated, it usually has non-shadow Pokémon before the capturable shadow Pokémon. These non-shadow Pokémon have their own requirements, that cause the RNG to loop until satisfied, being nature and gender locks. In XD, the developers also disallowed shinies from being generated for the NPC (and the player), hence a "shiny lock".

Pretty sure you set the PID to 0 or 1 and the game will interpret that as random / random-noshiny.

Adapt the script to search whatever criteria you want. Keep in mind there are only 2^16 seeds, so you need to consider if it is statistically possible. 5 flawless IVs is 1:2^25, which means a spread probably won't exist.