PokemonWorldMaster1 Posted November 2, 2018 Posted November 2, 2018 So, in the latest update to PKHeX, there was an implementation of more "Shadow Locks", this lock apparently strengthens the legality checking of Shadow Pokemon from Pokemon Colosseum and Pokemon XD. However, I have been unable to find any information online on how to properly generate legal PIDs. Before the update, I used tools such as RNGReporter's Gamecube Time Finder to generate proper personality values, however, this latest update has retroactively rendered my previously legal Pokemon illegal and I haven't been able to fix them. At Kurt's suggestion, I downloaded a program Eligor to generate PIDs, which alongside taking forever to generate a list, also yields me the PID Mismatch error in PKHeX. So I'm hoping that perhaps we can start a discussion or be pointed to a tutorial on how to generate it properly. I have attached my entire database of Pokemon obtained in Colosseum and XD, as well as a picture of my trying to generate a valid Murkrow PID and still getting the error, as well as that particular modified Murkrow. It seems that most of my Colosseum Pokemon were unaffected, with notable outliers being the shadow Makuhita, Murkrow, and Gligar. Whereas in XD, almost all of my Shadow Pokemon were retroactively made illegal. Colosseum and XD Pokemon.zip
theSLAYER Posted November 2, 2018 Posted November 2, 2018 Are you having trouble generating Colo/XD PIDs? Use RNGReporter or Pokefinder (we have then on our downloads area), set the Method to Colosseum/XD and generate it from there...
PokemonWorldMaster1 Posted November 2, 2018 Author Posted November 2, 2018 (edited) 1 hour ago, theSLAYER said: Are you having trouble generating Colo/XD PIDs? Use RNGReporter or Pokefinder (we have then on our downloads area), set the Method to Colosseum/XD and generate it from there... As you can see in this picture, RNG Reporter is still giving me illegal PIDs even when I set the criteria right, and Pokefinder just crashes when I hit generate EDIT: Nevermind, I was putting the IVs for special attack and special defense into Defense and Special Attack instead Edited November 2, 2018 by PokemonWorldMaster1 Made a mistake 1
english09 Posted November 3, 2018 Posted November 3, 2018 (edited) 7 hours ago, PokemonWorldMaster1 said: As you can see in this picture, RNG Reporter is still giving me illegal PIDs even when I set the criteria right, and Pokefinder just crashes when I hit generate EDIT: Nevermind, I was putting the IVs for special attack and special defense into Defense and Special Attack instead What is that program you're using on the left with the title "Gamecube RNG"? I have RNG reporter but I can't seem to find that option for "Gamecube RNG" that you have. Edited November 3, 2018 by english09
Toffoletto Posted November 3, 2018 Posted November 3, 2018 @theSLAYER and @PokemonWorldMaster1, The fact is that not every spread provided by RNG Reporter is legal, because, at least in XD, many of those spreads cannot be actually reached in-game. To know what are the valid spreads, you should also use Ginzaru's tool, xdcheck(it's only in japanese, however). Then, there's still the issue of pokemon caught by using the anti-shiny technique, which are supposed to have not only a valid spread, but also a matching TID and SID: PKHeX still fails to recognize as illegal the pokemon that don't fit these requirements.
Kaphotics Posted November 3, 2018 Posted November 3, 2018 9 minutes ago, Toffoletto said: PKHeX still fails to recognize as illegal the pokemon that don't fit these requirements. PKHeX does check for anti-shiny occurring spreads
theSLAYER Posted November 3, 2018 Posted November 3, 2018 What about using Eligor? It’s specfically For colo XD and it even lets you choose which Pokémon is the intended recipient
Toffoletto Posted November 3, 2018 Posted November 3, 2018 1 hour ago, Kaphotics said: PKHeX does check for anti-shiny occurring spreads @Kaphotics, Hmm, are you sure? Try looking at this Farfetch'd, which was caught by using the anti-shiny RNG method. If you try to manually change either its TID or SID, PKHeX will still flag it as legal, even if it shouldn't be, since its PID, with that nature, is not compatible with every TID/SID combination. @theSLAYER, I did not try out Eligor yet. I could make a test and tell you later if it generates valid spreads. 083 - Fantozzi - 384C9480B1D7.xk3
Kaphotics Posted November 3, 2018 Posted November 3, 2018 20 minutes ago, Toffoletto said: @Kaphotics, Hmm, are you sure? Try looking at this Farfetch'd, which was caught by using the anti-shiny RNG method. If you try to manually change either its TID or SID, PKHeX will still flag it as legal, even if it shouldn't be, since its PID, with that nature, is not compatible with every TID/SID combination. @theSLAYER, I did not try out Eligor yet. I could make a test and tell you later if it generates valid spreads. 083 - Fantozzi - 384C9480B1D7.xk3 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) }}; 1
Toffoletto Posted November 3, 2018 Posted November 3, 2018 25 minutes ago, Kaphotics said: 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) }}; I don't know the specifics, so it's likely that I'm wrong with what I'm going to say; I tried to check that seed with RNG Reporter: it generates that spread after 132 frames, but with a different PID and nature(hasty); in this case, why wouldn't a shiny skip be required to get an adamant Farfetch'd, while keeping the same spread? 1
Kaphotics Posted November 3, 2018 Posted November 3, 2018 7 hours ago, Toffoletto said: I don't know the specifics, so it's likely that I'm wrong with what I'm going to say; I tried to check that seed with RNG Reporter: it generates that spread after 132 frames, but with a different PID and nature(hasty); in this case, why wouldn't a shiny skip be required to get an adamant Farfetch'd, while keeping the same spread? 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
Sabresite Posted November 3, 2018 Posted November 3, 2018 This is the exact kind of situation Admiral_Fish explained to me was the reason for the verification going back. It would definitely be great if PKHex did that too.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now