Kaphotics

Have you considered if PKHeX is intended to support ROM hacks? PKHeX does not support ROM hacks. PKHeX will not support ROM hacks; it is for mainline&side games only.

Use the batch editor tab to specify a filter to !Language=Japanese !Version=BU That will filter out the GB/VC events as well as any Japanese-Blue version exclusives.

Since repro carts are just a single chip that store both the ROM and the Save File together, usually sequentially, you'll have to dump the entire chip not just what a dumper thinks is the save data. The two files you have uploaded are not anything close to valid save data, so nothing can be recovered from those two files.

Easier to use the batch editor within PKHeX to change every TID/SID then see which are shiny, if any. Then just go trade and hatch the unmodified copy. Still cheating, but whatever floats your boat.

Already reported and fixed: https://github.com/kwsch/PKHeX/commit/c198ab08e0c08bc47bafaa01d0372b731dcf2ce7 Either use the latest development build, or wait until the next stable program release.

The game reverts party forms when booting the game. Store it in your boxes and retrieve it when you want to use it. Be sure to deposit it when you are done using it.

The only way to transfer from 3DS to Switch and beyond is to use HOME. Transfer everything to Gen7, either legitimately or by save editors like PKHeX, then use HOME to transfer into the Switch era, and trade manually. If you are unable to use HOME from the 3DS, then you are unable to bring things forward in a HOME-compatible future-proof way. Injecting manually to a hacked Switch will lack a tracker, and the Pokemon will be unable to be moved into HOME and other games.

If you open it in PKHeX, it will show you all the details for ball and stats. Use the encounter database when generating Pokemon, as the program will set everything up for you from the template. When eggs are created, the game sets the nickname field to that of the species' name, then it sets it to "Egg". Due to how the game overwrites strings, it does not clear the unused characters that are reserved, so the longer name (in this case, Oshawott) is not entirely overwritten by the new name (Egg). The leftover unused characters are called "trash bytes", and since your file dies not match the leftover values expected in this situation, it is flagged by the legality checker. The trash byte viewer/editor is accessible by control-clicking the text box responsible for the name you would like to inspect.

1. Depends on the encounter, and the game the encounter is from. If it is sufficiently random, it doesn't have a type. 2. Tera raids have a detectable correlation. 3. No, because there is no algorithm to enable realtime checks. If people switch boxes in the UI, the program shouldn't freeze for 3 minutes for each Pokemon needing the check. 4. To write checking algorithms, you have to understand how they're generated and then just test the result against the starting conditions. A seed generates values in sequence. PKHeX has numerous of these, and the source code is hosted on GitHub for anyone to read.

Your screenshot of Bulbapedia shows Met Location as bits 0-6. Game of origin starts at Bit 7, ending with Bit 10. So, to discard the Met Level bits, you discard a total of 7. Since there are 4 values squished into a 16-bit value, you have to do the appropriate bitwise operations to isolate the values of each.

1. If the Pokemon is generated with a detectable pattern, then it must have a recognizable pattern in order to be legal. 2. If the Pokemon is generated with a pattern that isn't detectable (sufficiently random) then it won't show a pattern or lack thereof. Patterns that are too difficult to detect in realtime are not checked. 3. See #2; difficult to detect are not checked by the program. Verifying shiny raids and spawned PLA Pokemon with bonus shiny rolls takes a few minutes to bruteforce, and there are no public tools for anyone to use.

Backup files are stored in the bak folder next to the program executable.

Save twice in game.

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.