Send me your Pal Parks!!

[Sabresite]

Everyone, please send me as many pal parks as you can which come up as INVALID on legality checker. I want to test the new legality checker for D/P, Pt, HG/SS trash bytes.

You may email them to Sabresite [a@t] projectpokemon [d0.t] org or attach them to this thread.

DO NOT SEND ME POKEMON THAT ALREADY SHOW UP PROPERLY IN LEGAL B54.

DO NOT SEND ME POKEMON THAT WERE HACKED OR MODIFIED, ONLY LEGITS PLEASE.

The best way that everyone can help is to breed/catch Pokemon and name them with 1 letter, "A" and then pal park 6 at a time.

I need THOUSANDS for testing!

Thanks everyone!

[Infi]

I nicknamed 6 pokemon "A" and then pal parked them over, 4 of them showed invalid trash bytes.

Here you go.

PP-Sabre-03..pkm

PP-Sabre-04..pkm

PP-Sabre-01..pkm

PP-Sabre-02..pkm

[Sabresite]

Thank you, actually yours have been very helpful. It seems that the next digit after the end of the name is a wild. Please keep them coming, this should help me identify the problem with D/P.

Also I didn't identify the digit that is responsible for determining the slot that was used until RoC jumped on board to help. So if possible, please pal park and send all 6 that way I can record the slot digits.

[Kokusho]

I am writing a program that emulates pal park, doing this I have acquired information about trash bytes that you could be find useful.

If we call the six transferred pokemon, respectively, from first to last, A, B, C, D, E and F. We will have that:

- A will have constants trash bytes that depend on the game in which pokemon are transferred (as we already known)

- B will have at offset 0x4C (the next digit after the end of the name) the first 7 bits of A offset 0x84. It will have at offset 0x54-0x55 a pseudo random number (to read backwards, example B8 D2 must be read D2B8=53944), multiple of four, which have a 0xF8 range. It will have at offset 0x50-0x51 a number (to read backwards) that is related to 0x54-0x55 pseudo random number, in fact offset 0x54-0x55 value minus offset 0x50-0x51 value is a constant number which we will call Kb, the value of constant Kb depend on the game in which pokemon are transferred. The remaining bytes of trash bytes are constant and depend on the game in which pokemon are transferred.

- C will have the same structure that have B, but it will have in offset 0x4C the first 7 bits of B offset 0x84. It will have at offset 0x54-0x55 the same number of B, this pseudo random number in fact is the same for pokemon that are transferred together. It will have at offset 0x50-0x51 a number related to B offset 0x50-0x51 number, obtained from B offset 0x50-0x51 value plus 0xEC . So the constant number Kc (obtained in the same mode of Kb) is different from Kb (Kc=Kb+0xEC), but the value of Kc (that have the “C pokemon”) depend on the game in which pokemon are transferred, exactly like Kb .The other trash bytes are the same of B.

- D will have the same structure that have C, the value of their trash bytes are obtain from C in the same mode that we have used with C to obtain its trash bytes value from B.

- E and F, same of D.

I’m looking for a relation between Kb, Kc, Kd, Ke, Kf constant and pseudo random multiple of four number at offset 0x54-0x55, but for now I am unlucky.

I'm sorry for my bad English..

but hope that my information are useful

pkm..zip

Edited May 3, 2011 by Kokusho

[Infi]

Okay, from now on I'll upload all six.

Here you go, 02-06 are invalid.

BOX4_01-06..zip

[ieges]

I'm sorry for my bad English..

but hope that my information are useful

Your English isn't bad

[Sabresite]

The problem with your findings in terms of legality is that without checking multiple pokemon from the same "litter" (pal parking), I cannot determine what the RNG is currently at. Hell, even with all 5, I might not be able to. Therefore you have to go with the possibilities and make a table (which is finite, thankfully). Good findings none-the-less though.

[Infi]

08-12 are invalid.

BOX4_07-12..zip

[Kokusho]

some other pkm, they are all "B pkm" (2nd pkm transferred on six), there is also a table with the random value of each pkm

2nd transferred .zip

[Infi]

14-17 are invalid.

Edit: Added BOX4_19-24.zip - 20-24 are invalid.

BOX4_13-18..zip

BOX4_19-24..zip

Edited May 7, 2011 by Infi

[xfr]

It has been brought to my attention that using an emulator (namely, Desmume) can yield different trash bytes than retail systems.

Namely, I have been shown slot 1 pokémon from emerald and leafgreen that were pal parked on desmume (on a german platinium rom) that had trash bytes ending in \x6C\x1A\x0C\x02... instead of the usual \xA4\xA1\x0C\x02... on retail systems.

Be wary of this when researching pal park trash bytes.

[Sabresite]

To which 4th gen game? Because I do have people using desmume... and that is why I need people to send me their ACTUAL pal parks (in lots of 6 please).

EDIT: Oh you said platinum rom, okay I will check it out.

You are correct xfr. Do you have the proper ending bytes for platinum and hg/ss for each language? Reign who was taking care of the trash bytes was using desmume.

[ReignOfComputer]

Looks like I'll have to redo the entire collection. This affects all games, all regions?

Also, where does the game apply the Trash Bytes, after the capture in Pal Park, or after the transfer from GBA?

[Sabresite]

If I remember correctly, its applied when its xferred.

[marcos9191]

I developed a corrector trash bytes for 5th generation (named "TB Fixer BW", written in java). Even with that and made ​​some tests recently, on Friday or Saturday, upload the new version, which corrects imported pokemon third and fourth generation (egg, capture, pal park, ...), and also fix the 5th generation. The current version corrects the 5th generation and eggs imported from d-p-pl-hg-ss.

You can find it here:

http://projectpokemon.org/forums/showthread.php?19106-Release-TB-Fixer-Black-White-(version-4)