RNG Research

[Bond697]

this is something i noticed that i thought was kind of odd:

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.

[CodeBreaker]

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.

[Nexus]

Yeah a lot of the FRLG research was covered in this thread http://www.smogon.com/forums/showthread.php?t=62357 may want to give it a read to see what has already been found out, the OP lists most everything so you don't have to go through 18 pages.

[Kaphotics]

Diamond/Pearl stuffs I didn't see mentioned in this thread:

Safari Zone Pokémon - Save File offset 0x72D0+n

• Unsigned 32bit integer result from the ARNG.
• Four daily safari zone Pokémon
• Index_n = ( ARNG >> ( n * 0x5 ) ) & 0x1F
• List of Safari Zone Pokémon

Swarm Pokémon - Save File offset 0x72D4

• Unsigned 32bit integer result from the ARNG.
• One daily swarm Pokémon
• Index = ARNG % 0x1C
• List of Swarm Pokémon

Note: Both Safari Zone Pokémon and Swarm Pokémon have the same ARNG call value.

Source, edited in by Sabresite.

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

[TCCPhreak]

Hello,

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:

0x00 -> 0x1D Revive (30 values, so about 30%)
0x1E -> 0x27 Candy (10 values, so about 10%)
0x28 -> 0x31 Dusk Stone (10 values)
0x32 -> 0x3B Shiny Stone (10 values)
0x3C -> 0x45 Dawn Stone (10 values)
0x46 -> 0x4F Full Restore (10 values)
0x50 -> 0x59 Max Revive (10 values)
0x5A -> 0x5D PP Up (4 values)
0x5E -> 0x61 Max Elixir (4 values)
0x62 TM26
0x63 Leftovers

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

Regards,

TCC

[TCCPhreak]

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.

Has anyone ever verified the Kanto and Hoenn pickup-chances?

Regards,

TCC

[TCCPhreak]

Hello,

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


Regards,


TCC

[TCCPhreak]

Originally Posted by Fat TCCPhreak

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

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
• Second slot has battle-items: Fluffy tail, Dire Hit, X-Attack, X-Defend, X-Speed, X-Accuracy, X-Special, Guard Spec. After eight rounds, this seems to repeat (in that order)
• 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.
• Seventh slot alternates between Brightpowder, Leftovers, Scope lens and quick claw (that order, repeating after four rounds).
• 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.

[Slashmolder]

Happiness increases in BW2 (and probably BW1 as well)

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.