RNG Manipulation in FireRed/LeafGreen: Wild Pokémon Supported in RNG Reporter 9.93

Status
Not open for further replies.
The whole old rod thing was me wondering how it could only have two slots (and thus how to make it work).

If you freeze a value to the main seed location, it will act as the initial seed for PID generation, thus bypassing any advancement from sweet scent. A little hackish, but gets research done.

Now that I can successfully test individual seeds (knowing what Nature I'll hit) via seed freezing in the emulator, I can verify those ESV->Slots.

Here's what I believe them to be:
Code: 
Old Rod
Slot 0: 0-69 
Slot 1: 70-99 

Good Rod
Slot 0: 0-59
Slot 1: 60-79
Slot 2: 80-99

Super Rod 
Slot 0: 0-39
Slot 1: 40-79
Slot 2: 80-94
Slot 3: 95-98
Slot 4: 99
Setup of everything before PID:
Code: 
0 - Initial
1 - Battle Decision,		 pretty long thing		 = Battle
2 - Encounter Slot Value (0-99), via Upper16 %100		 = Slot
3 - Encounter Level (from Slot), via Upper16 %(High-Low+1) + Low = Level
4 - Encounter Nature, 		 via Upper16 %25		 = Nature

Now to generate a PID.
Code: 
set n = 0
loop until break to get a PID%25 = Nature
5+n - Temp  Low16PID
6+n - Temp High16PID

	if High16PID_Low16PID % 25 = Nature
		set as the PID, break
	    else n=n+2
		repeat loop
	end

end
Then comes the IVs, which depend on the Method of Generation.
Not sure if this is that calc at frame 1, the rejection of IV bits, or something else.
Code: 
	if Method 1
		a = 0 
		b = 0
	elseif Method 2
		a = 1
		b = 0
	elseif Method 4
		a = 0
		b = 1
	end

7+n + a   - IVSet1
8+n + a+b - IVSet2
 
Kaphotics said:
FireRed/LeafGreen TID/SID Generation

Code: 
The moment you press OK and the screen fades out completely, 
       the 0x04000104 timer value gets set as the new seed.
The game then takes that seed and considers it the initial, 
       and that initial seed is your TID.
frlg-tid.png
Code: 
The SID is set later in the process, but is still related to the seed. 
It is taken from the frame you are on when you end the miniaturization, 
       taking the seed on that frame (and using the upper16).
frlg-sid.png
Click to expand...

Also, the current seed for the game is stored at 0x03005000
 
Thank you for your posts here, Kaphotics! I have incorporated your research into the main post, so users will not have to scan the thread to find the relevant information.
 
I'm not a researcher or anything of the sort, but regarding the Magikarp near Mt. Moon, how "consistent" is it supposed to be Method 1?

I've been able to RNG other method 1 pokemon consistently with no error using another way which I shouldn't/can't talk about but basically it hits your target frame with no fail. I've done Method 1 pokes from legends to the game corner. It works for essentially all except Magikarp. Problem is I don't get the result I should be getting for Magikarp (Shiny; Jolly; 31/31/31/29/31/31). I get a Gentle nature instead. Tried this multiple times to no avail.

Has it been confirmed fully that Magikarp is Method 1? Or am I just having bad luck?

Sorry if this is the wrong topic btw, I figured it was most suited here.

Edit: Just making note that the above situation also applies to the Old Amber Aerodactyl fossil, and most likely Kabuto and Omanyte.
 
So I've taken up FireRed RNG abuse again, and I've noticed that as I use the Skipping method like I do in this post, I only hit the following ranges:
Code: 
079x-07ax
4c6x-4c8x(easily)
9a8x-9a9x(with much difficulty)
The most common seed I hit using this method is 4c7a. Unfortunately, this seed doesn't have very good spreads with 31 speed IVs. However, maybe varying the metronome's BPM will allow you to hit other seeds with equal consistency as this one.

xtr3m3 said:
I'm not a researcher or anything of the sort, but regarding the Magikarp near Mt. Moon, how "consistent" is it supposed to be Method 1?

I've been able to RNG other method 1 pokemon consistently with no error using another way which I shouldn't/can't talk about but basically it hits your target frame with no fail. I've done Method 1 pokes from legends to the game corner. It works for essentially all except Magikarp. Problem is I don't get the result I should be getting for Magikarp (Shiny; Jolly; 31/31/31/29/31/31). I get a Gentle nature instead. Tried this multiple times to no avail.

Has it been confirmed fully that Magikarp is Method 1? Or am I just having bad luck?

Sorry if this is the wrong topic btw, I figured it was most suited here.
Click to expand...

That's interesting, since it's listed as method 1 on the first page. Can you check what method it's being generated through, and see if it's consistent?
 
xtr3m3, this is an excellent place to ask your FireRed/LeafGreen RNG questions, Magikarp included. If Magikarp isn't being generated by method 1, then that makes it the only gift Pokémon generated by a different method (to my knowledge); this is certainly odd, but it obviously isn't impossible if you aren't getting the desired result. I second GoldenBanana in asking if you can check the method of your failed Magikarp; I suspect that if the IVs match up with method 1 (which your post implies) but not the nature, we are looking at a method 4 Pokémon. Kaphotics laid out a simplified version of the PID generation routine a couple of posts back; maybe something about Magikarp triggers something that causes the method to switch like a wild Pokémon.

I also can't help but notice the recent influx of RNG manipulated Pokémon coming from non-Emerald games. You are obviously among the new manipulators, so I have to ask—have there been any new discoveries as of late? I would think such things would be posted in the RNG Research thread, or this one, but I'm wondering if something went down on an IRC channel that hasn't made it to the forums (which is, incidentally, basically how FireRed/LeafGreen manipulation started). It's obvious that most, if not all of these Pokémon are coming from emulation, but I would like to know if it's just a renewed interest in the third gen and overclocked GBA emulation, or if some progress has been made in proactive manipulation. Thanks for your post!
 
It's because the way he tried to receive the Magikarp forced the disassociation of PID and IVs.

Vblanks interrupt the generation routine, and cause the game to wait to generate further. By having a seed frozen, you'll start over at the frozen seed again, which yields illegal results.

I've seen this same problem occur with the initial Poochyena battle where half of the IVs were generated improperly.

==========

The way the RNG works in every gen is with a magic number, called the seed. The game doesn't store the initial seed and frame as most people have come to believe... It instead stores the "current seed", which is [frame] iterations advances from the [initial seed] via the RNG formula of the particular game.

I've recently been testing how to get around the absurd wait time for different spreads (while using an Emulator). By changing this "current seed" memory location, you can effectively skip all the downtime of letting the game run for ages, and instead RNG what you wanted in less than an hour. (This takes a little more knowledge of how the RNG works in order to pull it off). This may cross the line for some, but so far I have only told 5 people how to do it (don't ask me now).

Also, I customized some existing Lua scripts to display the data of the appearing Pokemon as seen below:

kyogre.png


It helps by not having to use RSEdecode at all, and there are a few save file editors out there that can show you your TID/SID for Gen 3 games (PokeBox / Enciclopedia Pokemon).

We [bond (and arcee?) mainly] are starting to grasp the "vblank" aspect of the RNG routine, in which certain calls are skipped or redundantly there. This is the workings of why things are method 1/2/4. Still figuring it out.
 
Thanks again for swooping in with a helpful post, Kaphotics. I'm not sure what this "RSEdecode" is—I'm assuming an older emulator script—but it's good to know why there was a sudden increase in the number of generation 3 Pokémon. Hopefully this new seed-checking advancement will allow us to test the extent to which we can manipulate the initial seed. Am I to understand that the RNG is basically at a point where those using emulators have total control over the seed, and RNG abuse is wide open for them? If that is the case, then the initial seeding process for cartridge users is really the last big advance we can make. Hopefully the "vblank" phenomenon can be addressed soon as well, and I wish you all luck with that!
 
RSEdecode was made by mingot to decode the memory of the game of a caught Pokemon. You'd dump the ram to a folder and run the command line program and it would spit out the details of the Pokemon.

Basically this Lua script does it in game, while you are catching it.

Yep, emulators have always had total control over the current seed, as you can go from frame A on any initial seed to frame Z, millions or billions of frames away.
 
longer explanation:

http://pastebin.com/sH8W3frU

Code: 
    [21:19] <10Kaphotics> right
    [21:19] <10Kaphotics> but it looks like the game puts the seed back in between cccc and dddd
    [21:19] <10Kaphotics> and then re-grabs it
    [21:19] <Bond697> i do not know what that means
    [21:19] <10Kaphotics> ok, well
    [21:20] <10Kaphotics> to explain how Drakiar got those IVs
    [21:20] <10Kaphotics> it generated a-c perfectly fine
    [21:20] <10Kaphotics> but the d call IVs
    [21:20] <10Kaphotics> is aaaa
    [21:20] <10Kaphotics> the frozen seed
    [21:21] <10Kaphotics> actually, it's not that
    [21:21] <10Kaphotics> it's before the ????s
    [21:21] <10Kaphotics> you probably get what I mean
    [21:21] <Bond697> i think so
    [21:21] <10Kaphotics> for xtreme's magicarp, the IV binary is the PID binary
    [21:24] <Bond697> ok, hang on...
    [21:33] <Bond697> not sure what you're seeing
    [21:33] <Bond697> everything is in order here
    [21:33] <Bond697> nothing is reused, nor can it be
    [21:34] <Bond697> the seeds are overwritten in-register very quickly and nothing reches out to 3005d80 until the advancement routine
    [21:34] <Bond697> *reaches
    [21:35] <Bond697> if i might make a guess as to what you're seeing,
    [21:35] <Bond697> the main loop running again for the vblank will cause the game to stop cycling and start from what it currently has recoded
    [21:35] <Bond697> *"recorded"
    [21:35] <Bond697> if that makes sense
    [21:36] <Bond697> leaving the seed frozen is causing it
    [21:36] <10Kaphotics> that makes more sense
    [21:36] <Bond697> that's a bad explanation
    [21:36] <Bond697> but it makes sense in my head
    [21:36] <10Kaphotics> edited
    [21:36] <Bond697> all those rng calls you're seeing in a row are part of 1 run
    [21:36] <Bond697> then the game sort of "starts over"
    [21:36] <Bond697> pulls the current seed and keeps going
    [21:36] <Bond697> that would normally be the next seed
    [21:37] <Bond697> the ar is slow and isn;t keeping up
    [21:37] <Bond697> possibly
    [21:37] <Bond697> not sure why it isn;t writing fast enough
    [21:40] <10Kaphotics> each frame the game has it spits out the RNG seed
    [21:40] <10Kaphotics> into the lua console
    [21:40] <Bond697> yes
    [21:40] <Bond697> oh, thats it
    [21:40] <Bond697> the ar probably runs on vblank too(i.e. writes values 60x/sec)
    [21:40] <10Kaphotics> lawd
    [21:40] <Bond697> whcih should be fast enough most of the time
    [21:41] <Bond697> that should be plenty fast enough for almost anything
    [21:41] <Bond697> in this case, there are multiple calls between vblanks
    [21:41] <Bond697> so you're progressing and regressing back and forth
    [21:41] <Bond697> on each vblank
    [21:42] <10Kaphotics> you been able to find when the vblank is called?
    [21:42] <10Kaphotics> in otherwards, why/when/howoften
    [21:43] <10Kaphotics> or just the routine
    [21:43] <10Kaphotics> it could just be related to the timer calling for a refresh every xxxF
    [21:49] <Bond697> it's possib;e
    [21:49] <Bond697> *possible
    [21:49] <Bond697> the same routine runs regardless of method 2/3/4
    [21:50] <Bond697> so clearly something is interrupting it

not really a phenomenon, the game is redrawing the screen 60x/second. it runs through the main loop each time and in the main loop is 1 lone rand() call meant to keep the rng "random". their rand() call lops off the bottom half of the seed each time it runs, meaning each result is 16-bit. i'd wager the 60 advancements/sec is to keep it "random" and add a little extra juice to a really poor rng. the result of each of the 60 calls is destroyed almost immediately after exiting the function.

and a bit of code to show the 60x/sec advancement:

Code: 
.vblank (used 60/sec for drawing the video)
08000758 4821     ldr     r0,=#0x30022C0
0800075A 6A01     ldr     r1,[r0,#0x20]
0800075C 3101     add     r1,#0x1
0800075E 6201     str     r1,[r0,#0x20]
08000760 4920     ldr     r1,=#0x203CF5C
08000762 6809     ldr     r1,[r1]
08000764 1C04     mov     r4,r0
08000766 2900     cmp     r1,#0x0
08000768 D006     beq     #0x8000778
0800076A 680A     ldr     r2,[r1]
0800076C 2002     mov     r0,#0x2
0800076E 4240     neg     r0,r0
08000770 4282     cmp     r2,r0
08000772 D801     bhi     #0x8000778
08000774 1C50     add     r0,r2,1
08000776 6008     str     r0,[r1]
08000778 68E0     ldr     r0,[r4,#0xC]
0800077A 2800     cmp     r0,#0x0
0800077C D001     beq     #0x8000782
0800077E F2E6FCA7 bl      #0x82E70D0
08000782 6A60     ldr     r0,[r4,#0x24]
08000784 3001     add     r0,#0x1
08000786 6260     str     r0,[r4,#0x24]
08000788 F000FC7A bl      #0x8001080
0800078C F000FA30 bl      #0x8000BF0
08000790 4915     ldr     r1,=#0x3002F50
08000792 4816     ldr     r0,=#0x3006380
08000794 7900     ldrb    r0,[r0,#0x4]
08000796 7008     strb    r0,[r1]
08000798 F2DFFCC4 bl      #0x82E0124
0800079C F032FF54 bl      #0x8033648
080007A0 4913     ldr     r1,=#0x439
080007A2 1860     add     r0,r4,r1
080007A4 7801     ldrb    r1,[r0]
080007A6 2002     mov     r0,#0x2
080007A8 4008     and     r0,r1
080007AA 2800     cmp     r0,#0x0
080007AC D005     beq     #0x80007BA
080007AE 4811     ldr     r0,=#0x2022FEC
080007B0 6800     ldr     r0,[r0]
080007B2 4911     ldr     r1,=#0x13F0102
080007B4 4008     and     r0,r1
080007B6 2800     cmp     r0,#0x0
080007B8 D101     bne     #0x80007BE
[b]080007BA F06EFF07 bl  #0x806F5CC(rand()) (result destroyed immediately, unused)[/b]
[b]080007BE F00DFCD9 bl      #0x800E174(result of rand() is overwritten almost immediately here)[/b]
080007C2 4A0E     ldr     r2,=#0x3007FF8
080007C4 8810     ldrh    r0,[r2]
080007C6 2101     mov     r1,#0x1
080007C8 4308     orr     r0,r1
080007CA 8010     strh    r0,[r2]
080007CC 4804     ldr     r0,=#0x30022C0
080007CE 8B82     ldrh    r2,[r0,#0x1C]
080007D0 8B83     ldrh    r3,[r0,#0x1C]
080007D2 4311     orr     r1,r2
080007D4 8381     strh    r1,[r0,#0x1C]
080007D6 BC10     pop     {r4}
080007D8 BC01     pop     {r0}
080007DA 4700     bx      r0


(this is emerald, but this exact same thing is true for all gen 3 games.)
 
i guess to simplify part of what i was saying before, the method 1 pokes can likely all be created through other methods. basically, since they're supposed to be method1, they will be created without the "method H" pid restriction, but can be method 2/4, etc. pretty sure that makes a LOT more spreads legal that weren't before.

i'm still working on exactly what causes the methods, though i am getting close. once we know that, a lot of this gets easier.

personally, i think the other methods are caused by bad programming on gamefreak's part. we'll see, though..
 
Interesting. In terms of spread legality, the same calls would consistently be skipped, correct? Would that not mean that some spreads we had previously assumed were legal (because they technically should be) are actually skipped over "in favour of" a method 2/4 spread? And saphiren, you might be better off PMing a knowledgeable user than posting here; I'm not sure on how much emulator talk is allowed on the forums.
 
i think it's that it makes more legal because this prevents skipping over spreads.(maybe i'm misunderstanding you?) and the same calls aren't always skipped- you could get method 1/2/4 for a given standing legendary.

this explanation might be handy to have in here, too:

http://www.smogon.com/forums/member.php?u=88089

Code: 
think about it like this:

you have a frame where you you've edited the seed via action replay to be a specific number. the seed is frozen, so it's being constantly written by the ar which runs 60x/second. so, this is what's happening on the frame you're finding the poke you want to rng:

frame1:
-main loop(everything else occurs inside of this)
-vblank(useless rand() call here- just to "randomize" rng)
--ar writes its seed here->so the next rand call uses ar seed+1
-battle/make pkm
--rand()(pid), rand()(pid), rand()(ivs)
---something causes this to stop here and run through the main loop again-still figuring out this condition

frame2:
-main loop
-vblank(useless rand())
--ar writes its seed again-> next rand call uses ar seed+1
-finish makePKM()
--rand()(ivs)-ar seed+1(already used before)

see why it doesn't work?


(message was too long...)

the pkm creation calls occur in the interstitial space between vblank. anything where they aren't all made in 1 go will result in weirdness when generating. 

also, the roamers, static pokes, etc most likely all share the possibility of this happening. nothing is exempt from it, i don't think. what you end up with usually is a method 4 poke without the method H pid restrictions.

interesting stuff.

e: you might want to refer here, too:

[url]http://www.smogon.com/forums/showpos...&postcount=360[/url]
[url]http://www.smogon.com/forums/showpos...&postcount=362[/url]
 
When I was referring to the skipping over of spreads, I meant what was shown here of a "discarded" call:

Code: 
080007B8 D101     bne     #0x80007BE
[B]080007BA F06EFF07 bl  #0x806F5CC(rand()) (result destroyed immediately, unused)
080007BE F00DFCD9 bl      #0x800E174(result of rand() is overwritten almost immediately here)[/B]
080007C2 4A0E     ldr     r2,=#0x3007FF8

Now forgive me for any misunderstanding, as I've never been on the forefront of the more technical RNG aspects. What is happening here, if I am to understand, is that the vblank acts independently of the RNG, so the unused result has no bearing on the spreads generated—it's only used as a stimulus of sorts for the cycle. So whenever a rand() is invoked, you could end up with an "illegal" spread, but an existing spread is not consistently discarded as a result, is that right?

I also note in one of your other posts in the RNG Research thread, you speculate:

The IRQ handler runs 60x/sec, so the RNG runs 60x/sec+ a few when it cycles multiple times on a (vblank, not RNG)frame(I think, pretty sure).
Click to expand...

Would this explain why the RNG doesn't run at exactly 60 frames per second, assuming this turns out to be correct?
 
the rng, when running with no decisions to make, runs at the speed of the main loop/vblank because vblank is called every iteration of the main loop to clear the screen. does the game not run at exactly 60fps? i don't really know. if it's not, then yes, that's exactly why.
there's really no speculating about it being correct or not, as the game has a call to the rng advancement function in the vblank interrupt, so it's also gonna run at the speed of the game, basically.


the code you quoted at the top is part of the vblank function. it's an interrupt that clears the screen, or at least runs as the screen is clearing that stops data from being displayed. i guess the right way to understand it is that the rng advacement function is just a small function that takes the current number and does: seed = (seed * 0x41C64E6D) + 0x00006073; it can be called by any other function, and one of the functions that calls it is the one that clears the screen. the screen is cleared roughly 60times per second, so the rng is advanced 60 times per second.

after #0x806F5CC(rand()) runs, the game branches right into the next function, at #0x800E174. this function uses r0 without storing it first, that means the register where the rng result is stored on the processor is overwritten without saving its contents(i.e. it's gone for good). i've also looked for other calls to 0x3005000, the spot where the rng state is stored, and there are none that would use the rng state in a calculation. every time the rng is needed to make a decision, it's immediately called and the result is used. it isn't stored away for later use. 0x3005000 is just a global variable used to save the rng's state for the rng advancement function, it isn't used for anything else.

what you're seeing in that top-quoted part is the rng advancement that "causes" method 2/3/4. this "empty" advancement that isn't being used for a decision is what creates the extra call(s) for method 2/3/4.

sorry if this is kind of hard to understand. some of it is extremely complex and requires at least some knowledge of the hardware, how it acts, and its interactions with the software on a few different levels.
 
if anyone wants to turn off the unnecessary rng calls to make researching easier:

rng_fix.png

original on the right, changed on the left. 4 bytes to change total.

the image is for emerald. for r/s, change the same thing at 000005B4(080005B4), and for fire red/leaf green change it at 00000788(08000788).
 
NeoSyrex said:
This seems similar to the other RNGs (aside that the starting seed is harder to figure out), but there is one key factor that seperates it from the other RNGs: button presses on the title screen seem to influence the starting seed.
Click to expand...

Going to elaborate here a little more now that Zari is able to abuse somewhat reliably on his cart now :D

The timer, upon starting, is affected by the Keypress state of the game.
Lets say we have 2 scenarios. When a frame advances, so does the timer...

  • You don't have a key pressed down. You will get #(adv).
  • You do have a key pressed down. You will get #+1.
The +1 doesn't always happen from what I've heard, I'd say 99% of the time it will. My own guess :P

As we've seen with the RNG in Black and White, this timer is influenced by the keypress state. In B/W, the window of operation is incredibly small; however, in FRLG the time this timer is advancing is a lot. The minute inconsistency for these pressed key frames will rack up the +1's, which is what causes these "Seed Groupings".

Mashing A to a beat will cause much more erratic results compared to just pressing the button once. This makes your "Seed Groupings" smaller, and easier to hit. Additionally, when you press A, try to do it with the least amount of time possible!
 
Intriguing. I noticed in the Discuss My Pokémon thread that Zari stated he will be sharing detailed information on how he got his Mewtwo, so I look forward to his post as well! I sense that I shall need to make some major changes to the first post in the next little while, but I shall wait for Zari's post.

Now, I'll just address some more technical aspects of your post. In Black and White, different combinations of keypresses will have a different effect on your seed, but the way FireRed and LeafGreen are being presented here is binary. Is it a more "primitive" version of the keypress concept inasmuch as a button press affects the seed, not the specific button itself? This is what I am understanding from your post, but I would just like to be sure!

So to sum up, if I understand correctly, you have the "normal" seeding process which is based on the amount of time spent on the "press Start" screen in the game (as seen here). For our intents and purposes, we can liken this to the delay factor seen in the fourth generation games. However, any and all keypresses during this time will (presumably) advance the rng. Obviously since the timer is running at 240 hz, even a short press will have a considerable impact on the generated seed. This leads to certain groups of numbers being favoured (i.e. the numbers in our seed groupings) because of the way the RNG is now advancing, correct? In a roundabout way, this could be likened to switching the delay from odd to even if we are using "delay" as a reference, as it allows you to hit a different set of seeds than is otherwise possible.

In any case, I am curious as to how the "erratic results" caused by mashing A to a beat will make the seed groupings smaller. There must be something I'm missing here, so I'm hoping either you or Zari can clear it up!
 
You almost got it :P

The timer always advances at a particular rate per frame. If you have a key pressed down at any time, the timer's advancement will be +1 to what it is usually.

The timer advances in a linear fashion, 1 2 3 4 5... Ect. However, it advances faster than the ~60 fps the game runs with, so it will appear to advance in increments (of a particular amount which I don't remember offhand). If you started your game up and did the same process each time, you'd probably hit the same seed. Pressing A as quicky as possible reduces the amount of frames you have a key pressed, which drastically reduces the amount of seeds in the grouping.

Mashing A doesn't produce small seed groups, it is not good. A small, quick, and precise tap at the menu is the best thing you can do to get a small seed group range, thus making it easier to hit seeds reliably.

That was a copypaste error on my part :S

Then comes the ingame waiting, which isn't timer related :D
 
Well, almost getting it is pretty good by my standards! So extraneous button presses should be avoided in that case, since they make it more difficult to hit a given seed from the larger pool. Thanks for clarifying the seed groupings part of your post, as it makes sense a quick tap would be better given the rest of your explanation.
 
Alright, let's get cracking with some updates. I haven't posted here in a while, but for those of you who don't check dmp, I just completed my first frlg RNG!

Now onto the details.

A while back on IRC (and in recent posts) Kaphotics said that keypresses affect timer0 aka the seeding timer, in frlg. Well, I can confirm this; out of 9 tries I hit one particular seed 3 times. For as fast as FRLG seeds, a 33.3% ratio of hitting a target seed is quite good. Now, I've hit this seed before, but what made this different from previous tests was that I only hit the A button 3 times per attempt. As such, I got even more consistent results when I used the skipping method (3 presses is the minimum needed to do the skipping method).


As for how I got my new mewtwo....well, it took a lot of attempts, a lot of luck, and the right kind of target frame. What I mean by that is, well, choose a low target frame; you'll be hitting quite a few groupings of seeds, so select a frame from one of them that's somewhere under a minute (I used frame 2051 for my mewtwo).

Basically, to RNG in frlg you first need to find what you can hit; in my case on my lg, it was the groupings 4cXX, 7aX, 9a9X, and f4dX. Notice that, as opposed to those I hit earlier on my fr in the first post, there's mostly only 1 X variable (4cXX is right on the split point). This is due to the groupings being smaller, like Kaphotics has mentioned. Anyways, once I found what I could hit, I looked through the groupings for low frames with good spreads. I chose one out of the 7aX grouping because it was the smallest grouping that I could easily hit (7a4 - 7a7), thus increasing my chances of hitting my target seed when timer0 selected that grouping. After that, it just took using eontimer to find my lag for that particular frame (-517), and then a few more resets and....





150.gif

Bag_Master_Ball_Sprite.png
/ Hasty / Pressure / Genderless
28 / 31 / 7 / 29 / 24 / 31



....became mine. :)


If you guys have any more questions I'll try my best to answer them, but that was the main process for which I used to get my mewtwo. Obviously there was a lot of luck involved in the capture, but when it comes to frlg, you don't really have any other choice since timer0 moves so fast.
​
 
Thanks for your post, Zari! I have updated the original post in accordance with the research that you, Bond697, and Kaphotics have posted in this thread recently. I have also removed some of the older posts in the original post (the authors are still credited in the credits section) in favour of some of the new ones here. I hope there isn't too much outdated information in said post, as it has been almost two years now since this topic's inception, and we have a lot of new information! At the very least, the practical information has been reposted wholesale so that anyone can access it. Keep posting, everyone! We've made a lot of progress!
 
Kaphotics said:
The 256 Hz timer, upon starting, is affected by the Keypress state of the game.
Click to expand...

first of all, no:

t1.png


tcnt.png

and F = 33.something MHz on a ds.


second, no, keypress doesn't affect the seed. scankeys() is running 60x/second anyway through the main loop and it does the same thing whether or not you have a key pressed.

what you're seeing is the result of slamming on the A button and you not triggering it at the right instant to continue through the start screen. only doing it a few times will undoubtedly give you much more consistent results.
 
Okay, thanks, Bond697. I've gone into "damage control" mode and removed all references to keypresses from the first post, instead simply advocating more deliberate button presses.
 
Status
Not open for further replies.
Back
Top