Kaphotics

https://github.com/kwsch/PKHeX/blob/c666183e6c19430667cc854716cce4f0d2293504/PKHeX.Core/Saves/SAV7.cs#L198-L264

pkm related issues should now be fixed; can you elaborate on the d&d for save files?

Unable to replicate on the current commits; appears to have been fixed shortly after the last release. https://github.com/kwsch/PKHeX/issues/1082

You have to use the RBY Origin Game options

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

fixed in latest commit https://github.com/kwsch/PKHeX/commit/858aa5068921a8d95a507639e545a7aa9aff60e9

PKHeX assumed pre-filtering could select a precise encounter prior to checking moves; the EncounterGiftMatch list and EncounterStaticMatch list are evidence that it's not 100% possible. I'm thinking that the main encounter matching setup needs to be refactored to more of a yield-return ienumerable pattern. With that setup, multiple encounters can be checked. The static/gift workaround will end up being simplified so that the entire legality check first yields valid encounters then checks moves. If all moves are valid then the encounter passes, leading to remainder of the checks, else it will try the next encounter. Overall logic flow: IEnumerable to yield possible encounters Pre-move check rejection scenarios (invalid encounter slots/types) Move Checks Final Checks Will need to make the rejection loop flexible enough so that post-move checks can be inserted. Will also need to have a way to peek at the next possible encounter; if none, the flow will continue through the remainder of the checks as there is no other encounter to compare against. Won't be straightforward as the program has to be able to restart for the next encounter.

prior issue here: https://github.com/kwsch/PKHeX/issues/978 now disabled location check for crystal pkm in recent commit (2h ago): https://github.com/kwsch/PKHeX/commit/113001f28055776287f2065745001413dffb08fa

Not legal, is illegal. PKHeX doesn't match it to the ranger manaphy egg gift -- the current conditions (shiny/met data) do not agree with each other.

Same error, same cause. The custom text you have entered cannot be encoded for the game to use. Do not use backslashes \ in your text lines, only use them for control characters (\r).

Re-read the error message. Your custom text is invalid.

I'm able to see "Fairy Memory" in the held items dropdown... not sure what the issue is.

https://github.com/kwsch/PKHeX/commit/f0dcf2b6b23e816a3998aea6a5db6b5862441c45 been fixed since last release

Are you using the latest release or the latest commits? The recent .NET standard commit broke some data get/set operations.

https://github.com/kwsch/PKHeX/issues/1158 parameter is still able to be manually specified

Gen3 events are currently not supported, as there is no 'template' data like wc6/wc7/pgf/pcd/pgt to compare to. Eventually there will be a spec defined so that PKHeX can recognize these events.

It's a new Invalid legality message pertaining to RNG legality. When PKHeX finds that the pkm is impossible to obtain from the game's RNG, it'll flag it with that message.

Hold control when checking the legality, pay attention to the end for gen3/4 pkm PKHeX rerolling is mostly random (keeps nature/gender/form)... if you really care about PIDIV legality just find a valid PIDIV with RNG Reporter or leave the valid PIDIV alone. Finding a new valid PIDIV while respecting nature/gender/shininess/IVs/form/encounter slot legality is highly improbable and requires a lot of logic; PKHeX will probably never do this as PIDIV-encounter legality is very restricting.

>legal until edited Legality working as intended View the verbose legality report; all XD/C pkm are required to have a valid PIDIV else they will be flagged.

Right, because the MovePP/PPups storage only uses 1 byte for each move. 2 bits for PP up count (0-3) 6 bits for Current PP (0-63) When PP is 64, an &= 0x3F sets it back to 0 as 7 bits are needed to store '64'. Will need to see how the pkm actually stores 64 PP... ============== http://bulbapedia.bulbagarden.net/wiki/Power_Point#Base_value_alteration fix'd https://github.com/kwsch/PKHeX/commit/63b3c8b020509d6c1bcebd6d02756b76da576593 thanks for reporting!

fixed, thanks for reporting https://github.com/kwsch/PKHeX/commit/84d901f64701c78d829718bf4e7d7115ed0ff9bc

Changed the exe-filename detection to an input argument. Make a bat file with the contents: start pkhex hax exit 0 , and put it in the same folder. To boot into hax mode, just double click the bat :)

exefs editors require the exefs to be unpacked and available according to the folder structure shown in the first post.

Looks like it's related to some sort of hardcoded reference; the crash happens in loading the mgdb binaries: "The located assembly's manifest definition does not match the assembly reference." System.IO.FileLoadException occurred HResult=0x80131040 Message=Could not load file or assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) Source=PKHeX.Core StackTrace: at PKHeX.Core.Legal.RefreshMGDB(String localDbPath) in C:\Users\Kurt\Documents\Visual Studio 2015\Projects\PKHeX\PKHeX\PKHeX.Core\Legality\Core.cs:line 175 at PKHeX.WinForms.Main.refreshMGDB() in C:\Users\Kurt\Documents\Visual Studio 2015\Projects\PKHeX\PKHeX\PKHeX.WinForms\MainWindow\Main.cs:line 1369 at PKHeX.WinForms.Main..ctor() in C:\Users\Kurt\Documents\Visual Studio 2015\Projects\PKHeX\PKHeX\PKHeX.WinForms\MainWindow\Main.cs:line 149 at PKHeX.WinForms.Program.StartPKHeX() in C:\Users\Kurt\Documents\Visual Studio 2015\Projects\PKHeX\PKHeX\PKHeX.WinForms\Program.cs:line 80 at PKHeX.WinForms.Program.Main() in C:\Users\Kurt\Documents\Visual Studio 2015\Projects\PKHeX\PKHeX\PKHeX.WinForms\Program.cs:line 36 @evandixon

The game stores two sets of Friendship/Memories; one for the Original Trainer, and one for the latest (not OT) Handling Trainer. A Pokemon will now always remember its first trainer, and will remember the last trainer that had possession of it. The pkm format stores a 0 or 1 to point to which values should be used: 0 = OT, 1 = HT. Since the OT info is for a different game (different version), it should never be 0 if it is transferred to a future format. The OT values are forever frozen, and never to be modified. PKHeX also uses this restriction for memories; a past gen PKM can never make a memory with the OT as memories did not exist while it was with its OT. 99.9999% of the time, a similar ID/SID/OT is due to hacking, thus it should be flagged. I am not aware of anyone who has RNG'd their ID/OT to match a past game ID, but have encountered specimens that can be flagged with this logic. Change the OT/ID info to something that does not match your current save file, then make yourself the handling trainer (HT name text). Rather, just let PKHeX set that for you (which it does automatically).