for eggs in gen 4, they do (rand() * 100) /65535 and compare it to 20/50/70 as percentages. rand stretches from 0-FFFF, so that makes a percent out of the rand return for easy comparison.

in gen 5, they do if(rand(1600) < (20/50/70) or (40/80/88)) depending on whether or not you have the round charm.

they should have adjusted the values since they're not using them as percentages anymore, but they didn't so you end up with an 88/1600 percent change of an egg at the absolute best. this is as opposed to 70% chance of an egg at best and 20% chance at worst in gen 4.

since there's no round charm in bw1, that means there's at best a 70/1600 chance of an egg, or around a 4.3% chance.

Posting here to give some sort of info on Gen 3 (FRLG) RNG.
I'll list my points.
1) In FR/LG, every frame has an assigned 2 Byte SEED at the memory address 2020000 in the RAM
2) These SEEDs change with every save file. This means that if I have 2 save files of two Fire Red games, then, let's say- frame 2000 won't yield me the SEED of 5070, on the second game if it does so in the first game. This however, is dependent on the save file itself.
I'll post some more once I locate a frame w/ the SEED that has the Shiny Spread I ID Abused for. If you want to know how I found these results, then I'd be happy to answer them later. Although, I think that this info is somewhere else as well which I failed to see.

(looks as if mingot referenced the safari's & 0x1F in this post). dunno if the ARNG is what does the lottery numbers, but if it's the same as HGSS one might be able to predict the Safari/Swarms for future dates... but soft resetting until you get the desired swarm/safari is probably the easiest, heh.

I just did some research and learn some stuff. Although this may not be very useful, I thought, I'd share it with you.

I wanted to know how the pickup-stuff works in-detail. Originally, I planned to change the function so it would give me items more often (I already patched my Pokeradar and VS Seeker to faster charging methods - using the sun instantly instead of running 50 steps).
Checks for pickup are done at the end of a battle. As the PRNG is cycled like crazy during battle, it seems impossible to precalc or preset the value for those checks.

For the record: I used an english Pokemon Diamond, the simple debugger from free iDeas and four Lv100 Pickup-Slaves.

First, I needed to find the pickup-function. As it needs to call the PRNG I searched for any place in the game that might call 0x0201B9EC (the random function). Those turned out much too many.

So I breakpointed into that function near the end of battle and searched for a savestate in which changes to the seed change the pickup results:
I found a rather small margin: when the screen starts fading to black, it's too late. "wild pokemon fainted" is too early, "own Pokemon gained exp" is too early but not by much. I think it was about 70-80 frames after the exp message that the pickup-results were frozen.
Luckily, I found a state in which I could manipulate the pickup-results by manipulating the seed - so the checks must be done later.

Next, I breakpointed the PRNG and checked where it returns to. It's to be expected that one of them does the pickup-check after it fetches a random number.
I got lots of 222F026. It seems like this is a "do nothing but still cycle like crazy"-function for battle. I also found myself in 2239272 four times and in 2239280 two times. As I got four pickup-slaves with two picking up items (for the seed I savestated), this was a good candidate.

The call to the PRNG from 2239272 is followed by a division by 0xA (ten decimal); the remainder is kept (number between 0 and 9). It is checked against 0, if it is non-zero, the function is done. The interesting thing only happens at zero, which is in (about) ten percent of all cases - the pickup chance stated in literature.
I manipulated the division to always have zero remainder (divide by 1) and all of my pickup-slaves collected stuff.

Naturally, the "which item was found"-part of the function only is called on success. This is the call that returns to 2239280. The random number is divided by 0x64 (100 dec) and again, the remainder is used further - allowing a simple compare to the limits/percentages.
I tried to follow that function any further but got stuck in some strange loop. Instead of iterating just some offsets (like the columns of the pickup-table), it iterated a lot more (does it check on level, too?). I hoped to find a spot where I could force a specific item on the pokemon - maybe even change the pickup-tables - but then gave up.
Instead, I tried to find out which number (remainder of division) resulted in which item:

(I didn't check every number. I just assumed that 0x05 to 0x17 are the same as 0x00 and 0x1D. For each item change, a range was tested. eg. 0x30,0x31,0x32,0x33)

This is strange in two ways:
First of all, PP Up and Max Elixir have the same number of values, thus should have the same percentage. Yet, tables (bulbapedia, smogon) often list one of them with 5% and the other with 3%. Of course, it's possible that the chances are different on other levels but I highly doubt that. Gen5 tables seem to already be corrected to "4%+4%". Is there reason to assume that Gen4 is different? I cannot find any sources for the 3%+5%, even the official Pokedex2 treats them the same.

Also, TM26 is the item that arrives at the Lv91-100 tier, yet has a smaller number. All other items are "shifted in from the right when upgrading pickup level tiers". Of course, this is merely cosmetical.

Epilogue: Regarding the "*about* x percent":
Random is a number between 0 and 65535 so modulo 100 is mapped to
* 0-35: 656 times each
* 36-99: 655 times each
resulting in lower values appearing "a tiny bit more often". In case of selected items, this makes the rarer items "a tiny bit" more rare - 0.9994506% instead of 1%

In case of the "do I get an item at all?", this works in the player's favour
(0-5: 6554 times each; 6-9 6553 times each) - the chance is 6554/65536 ~= 10.0006103% instead of 10.
You could say that over the course of 655360 pickup tries you get four items more than with a real 10% chance. Yet over the course of 6553600 *successful* pickups, you've been cheated out of 36 "very rare" items each (should have gotten 65536, got 65500 instead)
On the other hand: once you've got the first ten leftovers and TM26s, you could be kinda happy that they don't appear more often.

So yes, it's "about n percent" but it's so close to n percent that it's okay to not care.

Sorry for double-posting. I think analysing another game is worth a second post.

Today, I tried the same stuff for Pokemon Emerald or - to be certain - on a german "Smaragd"-version. I don't think that the english or japanese version is very different although the offsets may differ. This time, I had 5 pickup-slaves on Lv100.

One PRNG was at 0806F620 but it always returned to the same caller (08010ED1). I think, this is the "cycle like there's no tomorrow" PRNG. Breakpointing here didn't help me manipulate the pickup-results.

At 0806F5CC (so slightly before that) was another PRNG, using the same memory address as seed and using the same parameters - but "sometimes" returning to a different function.
08038A3F and 080007BF were seen more than five times, so they were wrong. 08055D61 does something with the random value and 0xA - this looks suspicious.
It passes both values to 82FD920 - This seems to be division for Emerald. In contrast to Gen4-Division, it only returns the remainder (module) in R0.
Like in Gen4, rng mod 10 is checked against zero. Again, changing the load instruction to use 0x1 instead of 0xa resulted in pickup always succeeding.

Similar to Gen4, another random number is fetched. It is then passed again to 82FD920 (further strengthening the "division"-theory). And again, I breakpointed afterwards and checked which numbers result in which items.
Will it have the true 3%/5% ratio the "uncommon" columns? Or will it turn out that all of those internet-tables are wrong and it is and always will be 4% for both?

00-1D Hyper Potion, 30 values, 30 percent

1E-26 Rare Candy, 10 values, 10 percent

27-31 Protein,

32-3B Revive

3C-45 HP Up

46-4F Full Restore

50-59 Max Revive, 10 values, 10 percent

5A-5D PP Up, 4 values

5E-61 Max Elixir, 4 values

62 TM26, 1 value, 1 percent

63 Leftovers, 1 value, 1 percent

I'd love to see a different result. I'd love to believe that those tables got it right at least for the first game using a level-based pickup-table.
I don't like the idea that all those tables on the Internet simply copied a wrong information and it spread. Maybe I can contact some of those site maintainers and convince then - maybe even edit some wikis myself, but I think those numbers have spread too far to correct them everywhere.

Can anybody tell me where this 3%/5%-idea came from? Can anyone confirm that the Lv100-pickup-Pokemon are a special case and 4%/4% is only correct for them? I plan to repeat the tests with lower-level-Pokemon but if anyone else has information on this, I'd be grateful.

On a sidenote:

I tested Diamond, Pearl and Platinum for their pickup lists and found them in the game (detailed offsets are found in the bulbapedia discussion). As it turns out, quite some tables on the internet are wrong - listing a revive in the Lv1-10,1% percent - the game says it's a hyper potion.

I decided to check the info for the first game introducing Pickup - of at least of the first games: Sapphire (english). I strongly guess that Ruby and other languages are the same.

The responsible RNG was found rather quickly at 08040EA4 (just search for the multiplicative component of the generator and you don't get many hits in the game code).
It returns to 080005B9 - far too often. It also returns to 0800FD03 - far too often.
The return to 0802AFE5 has a familiar R1=0A and branch to somewhere. This time, the modulo-division is in 081E0EB0.
Again, there is an 0A21 in 0802AFE8 which can be changed to 0121 for experimentation. From there on every pickup try will be successful (something modulo 1 always is zero).
RNG is called again and returns to 0802AFF9. Again, we have a modulo-division by 0x64, resulting in a number between 0 and 99.

00->1D Super Potion (0016)

1E->27 Full Heal (0017)

28->31 Ultra Ball (0002)

32->3B Rare Candy (0044)

3C->45 Full Restore (0013)

46->4F Revive

50->59 Nugget

5A->5E Protein

5F->62 PP Up

63 King's Rock

I tried to find 1600170002004400 a number of ways (and alternations) in the image but couldn't find it. It turns out, the table is stored a bit different here:
Starting at 001FAD06 (in image, not in memory), there is a 10-row table consisting of the item number first and a compare value, second. The rnd-mod-100 has to be higherOrEqual all of the previous compare values but lower than the current compare value to get the current row's item.

Example: You should find

16001E00170028
in the image - which is to be read as
* if the rndMod10 is lower than 1E (00->1D), give item 0016 (Super Potion)
* if >=1E but < 28, give item 0017 (Full Heal)
* if >=28, continue table

The last entry is strange as it seems to be "if <0x100" instead of "if <0x64" but this seems to be a "catch-all" for the case of modulo not working (or some hackers interfering).

Regarding the compare values: 1E,28,32,3C,46,50,5A,5F,63 translates to
30,40,50,60,70,80,90,95,99, resulting in probabilities 30,10,10,10,10,10,10,5,4,1 - so the widely-spread tables are correct, this time.

For Leafgreen (german version), I decided to go a slightly different path.
I found some "too-often" return addresses (801167F and 800079D) as before and filtering them out, I quickly found 0802CE55 for the pickup check and 0802CE72 for the item-choosing. This time, 0802CE58 has the 0A21 which can be manipulated for 0121 for easier pickup experiments.

But instead of trying out all the possible numbers (or relevant and interesting ones), I just saw that the item-choosing fetches from 08250748 - which translates to 0250748 in the image - and read the information from the table there. If you want to check the table in other languages, try searching for 8B000F0085001900.

8B000F00: If <0F, Oran Berry

85001900: if <19, Cheri Berry

86002300: if <23, Chesto Berry

87002D00: if <2D, Pecha Berry

88003700: if <37, Rawst Berry

89004100: if <41: Aspear Berry

8C004B00: if <4B: Persim Berry

2A015000: if <50, TM10 (012A)

45005500: if <55, PP Plus

44005A00: if <5A: Rare Candy

6E005F00: if <5F: Nugget

A3006000: if <60: Spelon Berry

A4006100: if <61: Pamtre Berry

A5006200: if <62: Watmel Berry

A6006300: if <63: Durin Berry

A7000100: if <256: Belue Berry

This gives the compare values 15,25,35,45,55,65,75,80,85,90,95,96,97,98,99 resulating in percentages
15,10,10,10,10,10,10,5,5,5,5,1,1,1,1,1.

So, like in Sapphire, I can relax and gladly sign the well-spread-table.

Next plans: checking Emerald with low-level-pickups, try to find percentages for the Battle Pyramid (those are missing on bulbapedia).

Next plans: checking Emerald with low-level-pickups, try to find percentages for the Battle Pyramid (those are missing on bulbapedia).

Click to expand...

Let's make this (rather) quick:
german emerald, again. Using three Pickup-Slaves (one being an evolved clone of another).

In order not to die, the first pokemon's values were set to 999 each. Thanks to Äona for posting the right addresses (near 02024544) in the mogelpower-board. I had a moment of stupidity and didn't find them myself.

8055C95 still is used for the "pickup at all"-check so 8055C98 0A21->0121 works as usual.
81AA61B is used for determining the item itself. The following are for the first round:

00-1D Hyper Potion (30 values)

1E-27 Fluffy Tail (10 values)

28-31 Cheri Berry (10 values)

32-3B Ether (10 values)

3C-45 Lum Berry (10 values)

46-4F Revive (10 values)

50-54 Bright Powder (5 values)

55-59 Shell Bell (5 values)

5A-5E Max Revive (5 values)

5F-63 Sacred Ash (5 values)

Afterwards, I checked the slots for the first seven rounds. This time, I only checked the "border" values (00,1E,28,32,3C,46,50,55,5A,5F).

As the results matched the one on bulbapedia, I decided not to waste time with the higher rounds:

First slot always is hyper potion. Makes sense, as you might need quite some of them in the pyramid

Third slot is the most interesting. It starts with berries against the kind of special condition that the pokemon on this round like to inflict: Cheri against Paralysis, Pecha against poison, Rawst against burn. Then it gets strange: Lum against wasting PP (leppa seems more suited)? Chesto against Levitation? Lum against freeze? The rest is just lum berrys up until round 20, then it starts with Cheri, again.

Fourth slot is Ether. You need to recharge PP a lot.

Fifth slot alternates between Lum berry (quasi-full-heal) and Leppa (quasi-ether). This means that starting with round 7, the lum can be in two spots.

Sixth slot alway is revive as ko-ed Pokemon should not end your challenge.

Eigth Slot also has a four-round-iteration: Shell Bell, Choice Band, Focus Band, King's Rock. The shell bell was my reason for trying the pyramid and I was pretty disappointed when I couldn't keep it with me afterwards (after my Hoenn-clocks died with their batteries, this was the second-to-last method to get shell bells. Last one is XD Mt. Battle)

Ninth Slot is Max Revice and Full Restore, alternating.

Last Slot is Sacred Ash and Max Elixir, alternating.

I also think that the special bag for the pyramid is too small - I often had to throw away masses of sacred ashs and leftovers - that really hurt.

Still to do: Emerald, Lowlevel-Pickups, Heartgold/Soulsilver: checking percentages and slots.

Regards,

TCC

PS: Apart from the percentages, I could confirm Emeralds pickup table: 0d000e0016000300 is easily found, although the 15006e00bb00-part belongs to the "rare" slots.

Every 128 steps the MTRNG is called and there's a 50% chance to increase happiness. If happiness <200 +2 if not +1. 1 more is added for luxury ball and another one if it has a met location of your current location. Happiness increase is *1.5 if sooth bell. Since this is called for each Pokemon in the party this is how we are able to advance IVRNG frames every 128 steps.

sub_21823F8 is called every time you take a step, it updates the counter and if the counter is 128 it resets to 0 and calls sub_2020CF0 for each of the Pokemon in your party.

sub_2020CF0 calls the MTRNG and if it's upper bit is 0 then it calls sub_2020D54 to actually increase the happiness.

sub_2020D54 pulls the current happiness. It sets a counter to 0, If it's >= 100 +1, if it's >= 200 +1 again. That counter is then indexed into a table at 02090569, which has the values {2, 2, 1} meaning we get +2 for 0-199 and 1 for 200-255. Then it checks for luxury ball and +1 to the gain if it is. There's another similar check for if the met location is your current location (pulled at the beginning of the subroutine by calling sub_2018CAC) which also adds a +1 if the Pokemon has it. If the Pokemon is holding a Sooth Bell then it multiples the total gain by 150 and then divides it by 100. Then it finally adds the total increase, capping the max happiness at FF.

Pokémon from My Pokémon Ranch are generated entirely by the Wii game. The DS is not even connected when you do the trade, and the .pkm is generated and save there. I was able to rip Hayley's Pikachu from the Ranch save without having connected the DS after trading it.

Edit: The Phione isn't in the save as soon as Hayley asks for the Leafeon. Presumably it gets generated at some point after it gets deposited and saved.

WonderCard Initial Frames(Note that initial frames discussed here are the frame advancements that occur after the seed's initial PID frame advancements, but before the actual RNG calls which are used to build the Pokemon are made.)

WonderCards are not actually defined as 'normal' (Pokemon generated after 22 PID frame advances, either both gender and nature are locked, or both are random) and 'GLAN' (Pokemon generated after 24 PID frame advances, gender is locked, nature is random). There's just one generation method that varies depending on the card details. From my testing -- using the Mystery Egg WonderCard released in Japan a couple months after Black / White was released (one fixed IV, fixed gender, fixed nature), the 2013 movie ticket pre-order MewTwo (two fixed IVs, fixed nature), and various other cards I still have on my games -- the initial frame advances can be broken down as follows.

Advance 8 frames.
For every unfixed IV, advance 2 frames. (Up to 12 advances)
If the gender is fixed, advance 2 frames.
If the nature is not fixed, advance 2 frames.

It turns out that the above corresponds to 2 advances per RNG call made during the actual card generation.

We know that in other cases (DR genies, something else I can't recall...) that the game generates a Pokemon and throws it away before generating the one you receive. When The Agonist recently saw with the 2013 Movie MewTwo that it started 4 frames earlier than a 'normal' WonderCard, I believe it was Kaphotics who suggested that for WonderCards they might be generating two Pokemon and throwing them away before generating the one you receive (2 fewer RNG calls with 2 fixed IVs, times 2). Somebody who can look at or step through the code could verify it, if they're interested, but I did some testing and it looks to be the case.

First of all, here is the WonderCard generation logic. All RNG calls are from the PIDRNG, of course.

For each unset IV, generate an IV in the normal order. No RNG call is made for an IV that is fixed. (Up to 6 RNG calls)

Two RNG calls are made, the use for which are currently unknown. (2 RNG calls)

Make one RNG call for the base PID. (1 RNG call)

If the gender is locked on the card, an additional RNG call is made as part of the process (previously described in this thread) of modifying the PID to force the required gender. (Up to 1 RNG call)

If shininess is being forced or prevented, the PID is modified according to previously documented methods. (0 RNG calls)

If the ability is locked, the ability bit in the PID is modified appropriately. Pokemon with only one ability or with the hidden ability activated (if specified in the card details) have their ability bit forced to 0. If the ability is not locked on the card and the Pokemon has two possible abilities, the ability bit is flipped as per normal Pokemon PID generation. (0 RNG calls)

One RNG call is made, the use for which is currently unknown. (1 RNG call)

If the nature is random, one RNG call is made to determine the nature. Otherwise, the nature is forced to that set on the card. (Up to 1 RNG call)

Below are some of the cards I tested to check the variation in initial frame advances.

Lucky Pass Power +++/S changes the chance to meet a shiny from 1/8192 to 2/8192 (one extra reroll for PID). Compound with the shiny charm's 2 extra rerolls and it's 1/2048.

Also~~

Our work was inconclusive with Lucky Power + and Lucky Power ++, but we found that Lucky Power +++ and Lucky Power S invert encounter slots in the locations with 12 encounter slots. Slot 0 become slot 11, slot 1 become slot 10, ... etc ... slot 5 become slot 6, ... slot 11 become slot 0.

Click to expand...

Can't really confirm myself, these pass powers have to be given from another game and fade when you turn off the game (ie, no emulators). Easy to confirm by comparing RNG results to predicted (which is what was done).

How to view the exact PID and IVs of Pokémon in 5th gen on retail carts without saving.

This requires two DS consoles, as well as two 5th gen games, and the ability to access the GTS.

1) Disable the option to save before IR.
2) Do a battle with the other game with the desired Pokémon you want to check in the party.
3) End the battle quickly, and save the battle video on the other game.
4) Upload the battle video to the GTS and get the number.
5) Go to Pokécheck and upload the battle video to the VS. Player.
6) Scroll down to view the exact PID, IVs, and EVs of all Pokémon involved in the battle.

With the option to save before IR disabled, the game that doesn't upload the battle video never saves. This will be most useful for Roamer and Entralink RNG captures. The ability to upload battle videos to Pokécheck's VS. Player is not hampered by the inability to upload Pokémon to Pokécheck. However, battle videos can't be deleted, so other people will forever be able to see any involved Pokémon if they know what to search for.

The first thing to notice (which I myself failed to notice) is that different versions have different nazos, a RNG parameter depending on the game version and the DS type.
Some searching returned these results:

ds w2
209AF28
2039E15
2200050
22000A4
22000A4

ds b2
209AEE8
2039DE9
2200010
2200064
2200064

3ds w2
209AF28
2039E15
27A5E90
27A5EE4
27A5EE4

3ds b2
209AEE8
2039DE9
27A5F70
27A5FC4
27A5FC4

Note that I have only used the 3DS W2 one, and the rest hasn't been confirmed to work.

Remember that in the picture, I have used a wrong combination of DS type and nazo, so that the returned results are incorrect. If you don't turn on C-Gear, you will not want to check the box of C-Gear advance either. In my final trial which succeeded, I did not turn on C-Gear.

This is pretty much all you have to do. After a seed is generated, you can copy the seed to RNGreporter and generate a Chatot test pattern. I have used the save progress pointer test, which does essentially the same thing.

After you have prepared the parents ingame, deposit the father in the Day Care first, and then the mother. I haven't tried Ditto, but iirc it is counted as mother.

Walk until you get an egg.
Do NOT take the egg, but rather head into the Day Care house, and save by the door.

Hard reset, and first set the month on your DS to the month of the target seed.
Idk if this is necessary, but some have reported frame advancements at season change. Load the game, go out of the room and then in again to refresh the season. Save by the door again.

Hit your target time, and perform the chatot/whatever test to verify the seed.

Head out of the room and talk immediately to the Man.
Still, do NOT take the egg, but allow a new egg to be born later.

Walk until you get a new egg. This egg should have your target IVs and nature etc.

Note that here the Nature of the egg is determined together with IV rng, while PID only tells shininess/gender, iirc

There are several Wnpcs in the area;
With repeated testing I have found an advancement of 6 works well for me when you go out of the room then immediately turn to the Man by holding the left and A button.
For greater fault tolerance there is always the option of searching for consecutive shiny PID frames, although without Masuda and/or Charm those may be very rare.

Would it be possible to make an English translation to this program? Unfortunately I'm not able to read Japanese text. And, with it in Japanese I can't read/understand all the options it has and therefore enjoy the program to the fullest. :(

I was wondering if someone could help test something? I was looking into Gen5 rng stuff and wanted to have a peek at BW's rng state memory address on the Japanese ROM. So I looked up the address on PP.org (0x022160A8), but it didn't seem to be correct for my ROM (the US ROM address works perfect, it's the JP one that didn't seem to show the actual rng state). So I started searching and found that 0x02216084 and 0x02216088 do seem to correspond to the state (it's an 8-byte seed, so two 4-byte addresses). could anyone confirm that this works?