Kaphotics

Correct CP is only used for display purposes, so the '10k cap' doesn't affect anything in battle/etc.

The calculated CP can't go above 10,000 in-game; PKHeX's calculated CP didn't recognize this -- now fixed. https://github.com/kwsch/PKHeX/commit/65febae12548b9457ba4316f912c47fc6231f0b7 Game code (disassembly) for reference:

PKHeX is programmed in c#; the games are not. There are certain calculations that are done using floating point which end up with different results (between the two programming languages): Until a workaround is found, there may be some inaccuracy in the calculations (+/- 1 or ~0.0001)

Thanks, fixed: https://github.com/kwsch/PKHeX/commit/1c0b2488ef323b4cca00fd7562dfe7c8d971f1e7

You're probably doing something wrong when you're restoring the save data. If something was (simply) wrong with PKHeX, there'd be a flood of reports.

Edit them in HxD or any other hex editor. Reference structure is at the bottom of here: https://github.com/kwsch/PKHeX/blob/029e0e0a0801d2d6075bcca32cb6a0736deb1543/PKHeX.Core/Saves/Substructures/Gen7/GP1.cs

That's probably not saved in the PKM data, it's likely in the save file which gender it is. I don't think anyone has found where that info is stored. The game shouldn't have to dig through the pkm storage to find your starter, then to check the gender. It's likely precomputed and stored for easy reference

Read the source code, or find a website that lists the new game's data.

Read the changelog.

Please elaborate.

You can import & export gp1 files, and dump the current contents. Whatever is in the editor is what's currently available.

example: folder name, tab, path.

The batch editor is the go-to for finding what properties are named; they're the same as those used in the Advanced Search. =PKRS_Strain=0 ^ never infected

I looked into the savedata stored for GO transfers, and the Move IDs are retained. If you've transferred things already, just leave them there. We may have this as an 'event gift' format file that can be shared and injected into save files.

Older versions (back 8~ months ago) cleared OT affection when it shouldn't have; but maybe you hacked in the ribbon, idk Sure, ignore the wordfilter. It's just a warning I guess.

1) gen6 contests set +20 to OT affection. Not having valid OT affection with the ribbon = flagged; working as intended. 2) will have to add edge case handling, wasn't aware of this 3) the 3ds word filter is active for all generations as a general use precaution.

PKHeX uses this site's event gallery to validate mystery gift encounters; if it's not in the repo then PKHeX doesn't know about it PKHeX checks for 100% matches for gifts... would have to be contributed (or added fake-legal gift data) for it to be recognized!

@Sabresite @theSLAYER Could also be that their wiki is wrong. Not sure about the card validity.

And yet it still has its Crystal met data, which should have been wiped on Gen2->Gen1 transfer before you taught it Reflect. Hacked; working as intended.

Done: https://github.com/kwsch/PKHeX/commit/d5c22b1e510b9b7cb02c745008709e91d1bacf6d

Hmm.... I used RNG Reporter to generate this list of possible lock frames. start @ -129 tid/sid +2 50166/18532 25f493e5 @ -127 5 25F493E5 Serious eddaf479 @ -116 16 EDDAF479 Hardy 86 B9270E4D Hardy 102 811C9F7C Hardy 14a61dfe @ -7 125 14A61DFE Quirky 127 C9AC37EC Quirky shadow 134 9480B1D7 Adamant Traversing forward we can see it would match the first 2 members, but would stop at the 14A61DFE. +7 from that would be frame 132 with a PID of A15BAA59. I dug a little deeper, looking at PKHeX's PIDIV matching. Holding control when requesting the legality report gives me this: Encounter Type: Static Encounter (XD) (Farfetch’d) Location: Mt. Battle (C) Citadark Isle (XD) [076] Origin Seed: 37EC9A38 PID Type: CXD Using that seed, the first PID generated in RNG Reporter is A15BAA59, therefore, this was detected as an antishiny XD spread. In PKHeX, the PIDIV is detected first (with some leeway provided for antishiny spreads). PKHeX only tests the shadow locks, but doesn't back-check the eventual shadow mon. Looks like there's another step that PKHeX doesn't do (final shadow validation). Will have to add on some new stuff to flag any more invalid cases

PKHeX finds it possible to generate starting with seed 68d088a7 with no shiny skips required; the NPC TID/SID take the next 2 frames, then the pkm are generated from there. It could be that the Farfetch'd shadow locks are documented incorrectly instead generated team data: 68d088a7 @ -129 (start) tid/sid +2 25f493e5 @ -127 eddaf479 @ -116 14a61dfe @ -7 shadow mon public static readonly TeamLock XFarfetchd = new TeamLock { Species = 083, // Farfetch’d Locks = new[] { new NPCLock(282, 12, 0, 127), // Gardevoir (M) (Serious) new NPCLock(368, 00, 1, 127), // Gorebyss (F) (Hardy) new NPCLock(315, 24, 0, 127), // Roselia (M) (Quirky) }};

PKHeX does check for anti-shiny occurring spreads

Since the last release earlier this week, certain shadow checks were updated. As I previously noted, the release had incorrect data for Snorlax and Electabuzz. Suicune was probably not legal on older versions (it does not have any shadow checks), hence me stating that PKHeX doesn't recognize the met location as legal (which will have to be updated for).

Snorlax and Electabuzz should be fixed with the latest release; Suicune is probably an undocumented met location.