Jump to content
PokemonWorldMaster1

Generating Legal Colosseum and XD Shadow Pokemon

Recommended Posts

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

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites
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

1180634107_ErrorPic1.thumb.png.1cc65e24cc195c4cac53568e6eb7f5c3.png

Edited by PokemonWorldMaster1
Made a mistake
  • Like 1

Share this post


Link to post
Share on other sites
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

1180634107_ErrorPic1.thumb.png.1cc65e24cc195c4cac53568e6eb7f5c3.png

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 by english09

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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)
        }};

 

  • Like 1

Share this post


Link to post
Share on other sites
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?

  • Like 1

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...