Kaphotics

Use the Mystery Gift Database in PKHeX.

Wild pokemon in gen 5 have their PIDs modified per the trainer's TID and SID.

The 2->7 transfer feature is only enabled for testing recognition of transferred pkm with the same assumptions as 1->7's transfer code. It helps find edge cases sooner rather than later (when the official method is released). Thus the PKHeX legality checks will have higher accuracy than had we not enabled it

Last updated 7 days ago, didn't hear of it until ~36 hours ago. Edit history doesn't show the file as changed since last week, so it's very likely a misclassification. The teamcity builds are more up to date and have a different dll signature (because the code has been updated with fixes and does not have release optimizations enabled), hence why it may not be flagged the same as the release build.

Thanks, fixed in latest commit! https://github.com/kwsch/PKHeX/commit/212a48933560d48d799886876a1d803d575cc4f2

Works fine for me. You didn't upload a pkm file.

Thanks, stealth update in the latest commit: https://github.com/kwsch/PKHeX/commit/14697f47d31c1e2e493c8104415047ded21b3024 0x6040 was 01 01 01 00 instead of 01 01 00 00, same as 0x2E040.

The offsets won't be the same in the two files; the donor has block 0xC as the first block, thus 0x3000 is block 0 and block 1 is at 0x4000. Copy 0x4298-0x4577 from donor to 0x18298-0x18577, then copy 0x3AF8 to 0x17AF8, then re-save in PKHeX.

PKHeX reads the security key from the 0th save chunk for FRLG at the following offset: case GameVersion.FRLG: return BitConverter.ToUInt32(Data, BlockOfs[0] + 0xAF8); For inventory items, PKHeX reads them as follows from BLOCK 1: OFS_PCItem = BlockOfs[1] + 0x0298; OFS_PouchHeldItem = BlockOfs[1] + 0x0310; OFS_PouchKeyItem = BlockOfs[1] + 0x03B8; OFS_PouchBalls = BlockOfs[1] + 0x0430; OFS_PouchTMHM = BlockOfs[1] + 0x0464; OFS_PouchBerry = BlockOfs[1] + 0x054C; You can probably copy a donor save file from block1 [0x298-0x577] into your own block 1, and then re-save to fix checksums. Copy the Security Key too. Be sure to grab from block 0, and write to block 0. Each block is 0x1000 bytes, and the block number is at 0x*FF4 (being 2 bytes). In the OP save file, block 6 is the first block in the binary. Block 0 is at 0x17000. Block 1 is at 0x18000.

Thanks, added Ice Punch for Feraligatr (since it is also receivable on X/Y). https://github.com/kwsch/PKHeX/commit/a52f88dd5c984e5e6606ac0cb0303e1d81204f3b

GameCube languages: Thanks, fixed in latest commit. https://github.com/kwsch/PKHeX/commit/8d0af0bd5ba71077dc0a9eacb0a612ea2d6b16da Togekiss: hacked to begin with. Relearn Moves are invalid for a Daycare egg; since it was not a daycare egg, it was being assumed as a gift egg incorrectly. Behavior updated, should now resolve both issues. https://github.com/kwsch/PKHeX/commit/9699cdefaedb5b189ac7a8a3b26dc14da349e59a Feraligatr: No handling trainer value, thus never traded away from your OT on X/Y. Tutors are exclusive to ORAS. If it's never been traded away it's either visited a cloned trainer detail trainer (same as OT) or has never been traded = hacked moves, thus the pkm has been hacked. Bigger sign that the OT is cheating as it has never visited another trainer Beedrill: "You can catch Kakuna in Blue/Red on Route 24 and 25 as well as in Viridian Forest. You can also evolve it from a Weedle (which is really what you should do), however, in Red and Blue, a Kakuna evolved from a Weedle will not learn harden. Kakuna is not in Pokemon Yellow." Yellow's move table doesn't have any learnset moves for Kakuna either, so I assume there must have been some patch to the VC game? Or some undocumented behavior?

What year do you have set on your 3DS?

The current name of the Shellder in your party has the terminator character (end of string) as the 2nd character. If you've tried to use an unsupported character, PKHeX will automatically terminate the string there.

Probably the same as this thread, which has been fixed since the last release.

Needs to be adequately researched and documented prior to be considered for implementation.

Batch Editor. Read the FAQ.

If you had the pkm files (or save file) in gen3 format, you can always drag them over to any future generation save file and PKHeX will convert them for you! No need to try and fake the transferred data

Gen5: PKHeX doesn't auto-clear bad nicknames; it only checks for them. PKHeX uses the 3DS wordfilter to check for bad names; there are no records of what the official checks are. Gen6/7: Possible that the OT wordfilters are only enforced in the online trades (set to Sun. / Moon. ??) Bobo = retard/moron in Tagalog Mona = "cunt" in Italian Growlithe/Bad Strings: pk4/pk5 have very minor differences and were not differentiated back in the day (pkm). Probable that the original pkm was misinterpreted as the wrong format, thus using the incorrect character encoding. looks like the name is ⑹rawr!, with OT Jemma. It's being auto-recognized as a pk5 due to the Met Location being 30001 (which is impossible in Gen4). Likely hacked. Legality check from tabs: Legality checking from tabs prepares the pkm data in the event that any property was modified. To check a PKM without using the tabs, you can hold control to bring up the "Legality" option (like View/Set/Delete) in the box view. Pichu: IVs are hacked (5IV, with no PIDIV method) thus not a wild capture, thus an egg.

Raichu/Pikachu: Only place Pikachu can be captured (in Sapphire) is in the Safari Zone. >The Raichu was from an egg >Origin Seed: EB907277 >PID Type: Method_1 definitely not from an egg

Can't tell without seeing PKM data; feel free to clear TID/SID/OT

Possibly you've hacked the PIDIV relationship, thus the only possible encounter is an egg (which can only be in a Poké Ball). Hold control when requesting the legality report, it'll tell you the encounter details.

Crystal is currently GBCartEra only; as in, there's no way to get it on virtual console. Since it's not virtual console, the Celebi Event is thus obtainable (japanese only, but whatever). Transferring to gen7 requires it to originate from a virtual console save, which has not released the event.

Thanks, fixed in latest commit https://github.com/kwsch/PKHeX/commit/e5d7a063af3a7ddb848e6409f3cde2255ca82492

I looked deeper into regulation and I found something interesting: https://pastebin.com/5FwTiami We know that the player has to select a team, and the game has to know if that pkm is allowed or not. I assume if the sublegends/legends list wasn't directly used, then it'd be the bitflag alternative. Since we know the legends are the only ones banned, and only species are banned... (using PKHeX's legends list and c#): bool[] value = (new bool[808]).Select((z, i) => Legal.Legends.Contains(i)).ToArray(); byte[] data = new byte[value.Length>>3]; for (int i = 0; i < value.Length; i++) if (value[i]) data[i >> 3] |= (byte)(1 << (i & 7)); File.WriteAllBytes(@"D:\bans", data); This generates a 101 byte file: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 00 00 00 00 00 00 00 00 00 00 00 00 0E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 07 00 00 00 00 00 00 00 00 00 00 00 98 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D8 03 00 00 00 00 00 00 00 F0 03 00 00 00 00 00 00 00 E0 01 07 I searched thru the decrypted ROM and found it in multiple places. Try clearing the appropriate bitflags everywhere (or maybe just replace this chunk with 101 zeroes). Stop after F0 03 for ORAS (728 bits, 91 bytes).