anyway, i guess i made my point on the difficulties of manipulating the rng for battles. that said, so how was the "TAS" that was already linked done? and how did it not involve him just standing and waiting for some time for a good seed to show up before a battle starts, but still manipulating the battle rng? well, the simplest answer is correct and also explains the missing input file. i'll just leave it at that.
before i forget, the tick system is 64-bit. it doesn't loop for a good, long time. you would also need to estimate where it would be when you're starting the battle. and you need to guess when you'll be starting the battle so you can guess where it'll be.
You could turn off the DS, then turn it on when you're told to start the battle; that's done really frequently to prevent the DS losing power.
i agree with you to a point. the tick system moves at 65536 ticks per 7.5 vframes. so, very fast. so you would really need to know ahead of time down to the second when your battle is starting. or you'd need to guess and make lists of which starting seconds would work and see if you could kind of manipulate things a bit so the battle started when you needed it to. theoretically possible, i suppose. the real pain the ass there is making sure you kind of push things or delay things so the match starts when you need it to.
A bunch of these variables you can't actually control without losing more time than it actually saves.
You can change input and microphone the frame it happens so that's more reasonable and also I didn't say that 268435456 different possibilities are the maximum, they are just the easiest to manipulate.
ok, we just had a small miscommunication here. i thought you were saying that that was everything. you're certainly right about that. to make one where you actually take advantage, you would just be sitting there forever slowly advancing frames waiting for the right combination of numbers to come up. so yeah, you'd end up killing tons and tons of time.
Masterjun wrote:
Bond697 wrote:
indeed, 1 sample for the whole movie. you'd probably have to make it yourself in a hex editor and provide it to desmume as a.raw file.
That would mean that you had the same sampling data for every battle! That's very pointless for a TAS because that gives you only 2 out of the 65536 possible states (0 and the one in the file).
you're right. i guess there's really no good way of handling this? and it's not legal for the TAS to disable it in desmume?
it's starting to look like any real manipulation of the battle rng in a TAS would be extremely difficult, if it's possible at all. that's kind of disappointing.
I thought there are 65536 different values for sample data that gives you 65536 different possibilities for seeds.
And since the seed also depends on the input (which there are 4096 states of) you have to multiply them together. So 65536 * 4096 = 268435456.
edit:
Responding to your picture:
Masterjun wrote:
I think even if it would be working, you could only use one sample for the whole movie (since in the movie file there is just stored if you pressed the hotkey for microphone enable).
indeed, 1 sample for the whole movie. you'd probably have to make it yourself in a hex editor and provide it to desmume as a.raw file.
as for the seed, that's true about those few numbers, but there are others. let's see if we can extend this all the way. we'll start with battle seeding since everything is initialized.
-65536 numbers for sample
-0x3000 for input, minus a few since closing the console and hitting the debug button wouldn't count and a few of the . so let's say 0x2400 values for the sake of argument
-263 for vcount
-65536 for timer0
-MAC is MAC, it doesn't change
-vframe is an unsigned int, so 4294967296 total. that said, it could take months to get that high. for argument's sake, let's say you play/leave the game on for up to 3 hours. that would max the vframe at 38880000.
-gx status will somewhat change. it's a 32-bit number, so it can go up to 4294967296, but some of that is not used in these games. so let's be pretty conservative and say roughly 8 bits are commonly used and say 256 values.
-mic data address in ram- let's constrain it to a 1mb area instead of 4 for the address, so 1048576 there
-wireless rssi pool- this generates randomness based on wireless intensity. it would be extremely hard to get past this randomness, but you could certainly shut off wifi. this is 65536.
-tick system- this is one of the big ones. it's 64-bit and runs faster than vframe, but slower than timer0. it's used for timing things for debugging, random numbers, etc. it's the ds equivalent of a windows api timer or starting a timer in C#. let's do the same thing as vframe and lower the max from 2^64 to 3 hours of play at most. there's 4294967296 ticks in 2 hours 17 minutes, so let's just go with that as the max.
-the clock, which is binary-coded decimal and can be read as decimal in the memory @ 2FFFDE8 and 2FFFDEC, will of course throw things off even more. i'm not going to add this in to the calculation because it's already so big that it illustrates my point. keep in mind that it would need to be factored in, though.
so as you can see, the max possibilities for a seed for a battle are pretty large.
65536 * 0x2400 * 263 * 65536 * 38880000 * 256 * 1048576 * 4294967296 is the max there. (*wifi is assumed off, so we won't count this) to change up the tick system and vframe count, just change 38880000 and 4294967296. still a lot, though.
keep in mind, that's for battle. when starting the game, you get something more reasonable.
(again, each number is the number of values possible)
-1 for sample
-0x2400 for input
-1 for vcount
-4 for timer0
-MAC is MAC
-1 for vframe
-1 for gx status
-1 for mic data location
-1 for wifi
-1 for tick system
-and the clock again, which is constant between each. just keep it in mind.
see the difference? and the stuff that's still got a wide range for the main rng seeding is user controllable very easily- input and clock.
so what i'm getting at after saying all this disparaging shit is that battle rng is possible with the emulator so long as you're set to stand and wait for the values to change and do the math out to check and see if you'll benefit from the outcome. and you may be standing and waiting for a very, very long time. and you can't know what the opponent will do during the battle that might screw up your long-awaited rng seed. if they do something that requires an extra rng call or 1 less, you're kinda stuck again.
how are you calculating that, exactly? like, can you give me the numbers you multiply together? or do you mean just given different mic data? because that's not nearly enough for total seeds. also, do you mean for the main seeding or for a battle?
also
you can provide a sample that desmume will use. pretty sure that will work.
thinking about it now, maybe the mic does work right and it's just not picking up mine right so it's outputting 0s. if that's the case, the newer versions of desmume have a setting that lets you use a generic mic sample provided by desmume. you could get away with that, i'm sure.
the sizes for the mic data are:
u32 mic_last_address;
u16 mic_sampling_data;
so 4 bytes and 2 bytes- the address is somewhere in 0x2xxxxxx in ram and the sampling data is 0-65535
-microphone sampling data result
-address in ram of the last microphone sampling data
Wait so does microphone actually change the result of the seeding?
Because from my testing the seed didn't change (or the microphone thing in desmume doesn't work, I don't know, I tried random whitenoise).
it does for battles. it's not initialized for when the main game seeds. not all of those things are in effect when the main game seeds which is why it's possible to rng.
well, at least for b2w2 I can confirm that the start seed for a battle is as it is described here. Now I wonder where the microphone is coming in...
you can't use that. what i was describing is the same thing, but it uses more entropy data because things are actually initialized by the time you enter a battle. i'll show you.
this is OS_GetLoEntropyData:
note the comments. mic, vcount, tick counter, vcount, etc etc. when this runs when the main game is seeding, most of those values are 00s. when you do it when you're getting into battle, they are initialized and are used.
this is the output from the array on the stack when the main game is seeding:
02FE36AC 00380761 MEMORY:00380761
02FE36B0 A81F0000 MEMORY:A81F0000
02FE36B4 B4C55689 MEMORY:B4C55689
02FE36B8 05111013 MEMORY:05111013
02FE36BC 00000461 MEMORY:00000461
02FE36C0 00000000 MEMORY:00000000
02FE36C4 00000000 MEMORY:00000000
02FE36C8 00002FFF MEMORY:00002FFF
note all the 0s.
now note the array on the stack when getting into a battle:
02FE3654 00F0C7CA MEMORY:00F0C7CA
02FE3658 A85F3174 MEMORY:A85F3174
02FE365C 3CC424DC MEMORY:3CC424DC
02FE3660 05111013 MEMORY:05111013
02FE3664 00021262 MEMORY:00021262
02FE3668 00000000 MEMORY:00000000
02FE366C 0D600170 MEMORY:0D600170
02FE3670 FC032EDF MEMORY:FC032EDF
much fewer 0s because the hardware and systems are initialized.
and keep in mind, the only reason there's 1 line of 0s in the second array is that the mic just isn't working right in desmume. that's the mic data element. if this was a real DS, that would be set to a couple of values.
this is how i know that:
ARM9:0207C74E E5 20 80 00 MOVS R0, 0x394 ; MIC sampling result
ARM9:0207C752 31 5A LDRH R1, [R6,R0]
ARM9:0207C754 0A 04 LSLS R2, R1, #0x10
ARM9:0207C756 01 1F SUBS R1, R0, #4
ARM9:0207C758 71 58 LDR R1, [R6,R1] ; MIC data storage address
ARM9:0207C75A 51 40 EORS R1, R2
ARM9:0207C75C 69 61 STR R1, [R5,#0x14]
note that the mic data result is stored to r5 + 0x14 and 0x2FE3654 + 0x14 is 02FE3668, which is the 0-ed line.
so to carry this to a conclusion, this array is hashed along with 20 bytes of garbage from the stack. it looks like this: http://pastebin.com/EVxNBAN4
then after the nazos and array are hashed, they take 8 bytes and make that the starting seed.
-microphone sampling data result
-address in ram of the last microphone sampling data
Wait so does microphone actually change the result of the seeding?
Because from my testing the seed didn't change (or the microphone thing in desmume doesn't work, I don't know, I tried random whitenoise).
it does for battles. it's not initialized for when the main game seeds. not all of those things are in effect when the main game seeds which is why it's possible to rng.
When does this seeding happen? If it's at poweron, like the other RNGs, most of those have known values, or typically known values, and so aren't important.
If it's seeded at the start of every battle, then yes, it's going to be rather harder. Many of those are going to be the same every time, though. (Realtime clock and key inputs are trivial to control, you can just not touch the touchpad, the MAC address is fixed, and I think it only samples inputs once a frame so it'll always be at the same point within the vcount?) The microphone is also easy to control, because it's possible to attach an external microphone to the DS, and it could easily be made to always output zeroes.
Dealing with the wireless-related seeding is normally handled by RNGers via simply turning wireless off. I don't believe there's any reason to turn it on at a VGC, either (it uses infrared). The graphics state likely has very low entropy, because the view on screen is particularly simple when starting a battle.
So "all" that you'd need to control would be the various precise timers. That probably does make control very difficult, but because I think the game only acknowledges keys at the transition from one video frame to the next, you could probably find a seed where a range of consecutive frames worked, for all reasonably likely precise-timer values that might happen on those frames.
obviously it's seeded at every battle. and keep in mind it's not like doing rng abuse, you can't just start resetting your console over and over until you think you've maybe, possibly hit(remember, you can't check) one of the seeds at 1/16780000 hz that has to line up with the other timers that might work and give you an advantage. you start the game and battle when you're told. and while y/m/d is nothing, h/m/s is something you have to keep up with and pay attention to because you'll need the fight to start at the right time(which the competitors don't get to decide on) so you can maybe hit a seed through all the other timers/counters. another thing to pay attention to while you're trying to concentrate on a couple of high-precision timers and the other counters.
i could see it being possible if there was maybe 1 timer and counter and you had all the time in the world to reset til you liked what you got and could check somehow, but it's not and you can't.
plus, don't they supply the hardware for part of regionals and during at least parts of nats and worlds? which means you can't do anything to stop the microphone, etc. if you end up with their hardware. not to mention, you need to know exactly where the last sample was even if you do manage to force the samples to 00 through.. some means in front of the crowd of people and your opponent watching.
e: and no, the graphics state changes based on where in the room you are(causing new graphics to be queued and the state to change), if there's currently a gx-related callback interrupt executing, when the FIFO changes state, box tests and their results etc. it changes very frequently.
e2: before i forget, the tick system is 64-bit. it doesn't loop for a good, long time. you would also need to estimate where it would be when you're starting the battle. and you need to guess when you'll be starting the battle so you can guess where it'll be.
e3: also, you use the cgear to set up infrared battles. *edit: the vgc battles happen through the competition thing in the main menu. the wifi is on for the normal cgear stuff, but i'm not sure if it's on for that. you don't even get option to go in-game. whether that means wifi is on or not, i'm not sure. i don't really need to know to show that it's really not possible, but i'd like for the info to be right. for the sake of argument, though, let's say it's off.
Simply stating it's not possible, without evidence, isn't particularly convincing.
If you can press the sequence of keys on an emulator, you can press the sequence of keys in real life too (unless it involves 30Hz mashing, or something like that). If you can calculate the sequence of keys to press via any means at all, you can pre-calculate it and memorize it. If it requires precise timing, you can use a clock or timer to help set it up.
fine. the entropy data that's passed through the sha-1 function is made from a bunch of different things that i partially listed above.
-vcount is the vertical line counter, 0-262 each vframe
-the current value of timer0, a timer moving at the speed of system bus(16.78 mhz) counting 0-65535
-the mac address
-the current value of the tick system which is a special counter that is part of the sdk and not considered in normal rnging because it's always 0 at that point
-the current vframe number
-the current graphics engine status
-the current realtime clock values for y/m/d and h/m/s
-microphone sampling data result
-address in ram of the last microphone sampling data
-current touch panel status and info- all ranging from 0-65535
-current sel/sta/a/b/udlr/lpad/rpad key input
-current x/y/closed input
-the wireless rssi pool that generates random numbers- depends on wireless module received signal intensity.
you would need to accurately predict every single one of those from when you turn on the console to when you start a battle. and keep in mind they don't all change at the same rate at all. some don't even change consistently.
the only reason rng abuse is possible in gen 5 is that most of those values are 0 when the game creates the seed for the main rng. thankfully someone at gamefreak never read the sdk manual.
I never believe that exploits 100% require an emulator, and I'm not convinced you're correct in this case. (Also, you forgot about, or didn't mention, the ability to earn byes in Nationals via online play.)
However, I also don't see how releasing the input file would be useful for people intending to cheat.
So this is basically turning into the discussion of this thread.
Let me try to summarize:
as Bond697 is saying, the input file is useless for figuring out RNG
there are a lot of information about this RNG on the internet and they are somewhat easy to find
Thus there is no problem in submitting a TAS of a Pokemon game after D/P (not including X and Y because of obvious reasons).
I don't know how any other discussion would fit into this thread, really...
it's almost 100% completely useless, even compared to just using an emulator to follow the battle rng and it's obviously not even close to using a debugger to pick through the code.
the MOST use you could get out of it would be seeing what the seed is on a frame that a move is selected and sort of going "ok, i know this 32-bit number makes a move do X, but why?" which is what you'd be doing on an emulator anyway. so is use is almost 0 there since you're doing the same thing either way.
and there's the point that, as i said, you cannot abuse the battle rng at nationals, regionals, or worlds because it absolutely 100% requires an emulator or action replay.
speaking of debugging, i have a really nice IDA 6.1 database for the battle system for black and white 1 if anyone is interested. lots of info there for anyone who can handle ARM assembly and is interested.
...If I recall correctly, the in-battle RNG from Platinum onward is no longer based on frame timings. There's one seed set at the very start of the battle (this one is time-sensitive), but afterward, the RNG only cycles when it needs to. If you make a savestate right before selecting a move, and said move lands a critical hit, then reloading that savestate will always make that move critical hit, no matter how long you wait between loading the savestate and confirming the move.
that's correct. all the gen 3 games were constantly advancing the rng* which made manipulating it a chore, though still possible. gens 4 and 5 only call the rng when it's needed.
the difference between gens 4 and 5 is in the seeding. in gen 4, as i recall, the battle rng was in the same place as the normal rng. when a battle would start, the current seed would be saved and a new one would be created. this seed would be used for the length of the battle and then the old seed would be put back when the battle ended. gen 5 is completely different. the overall codebase got a pretty massive overhaul for gen 5- likely in preparation for moving to the 3ds. they use a.. sort of complex method of creating the seed by taking the SHA-1 hash of an array of low-entropy data.(a timer, graphics engine status, rssi, wireless hardware status, vframes since boot, etc) so, while all the low-entropy data isn't initialized when the game boots, which is why gen 5 is still rng-able, it certainly is when a battle is initialized. so without an ar or emulator, you can't actually do anything with the battle generator.
*it has no real use, mind you. it was done literally for the sake of helping a crappy generator's "randomness".
On a wild guess, when people stop playing Gen V on Wi-Fi, so that abusing the in-battle RNG could no longer be really used to cheat anyone in Wi-Fi battles. Which will probably be in like 2 more generations or something.
what do you need to know, exactly? just ask.
It's not something I need to know exactly; it's just somewhat disheartening to realize that if Game Freak doesn't change how their in-battle RNGs work (and they have no reason to), then it will basically be impossible to, in good conscience, ever submit a TAS of a Pokemon game post-Platinum here (since doing so would essentially allow any players of that game to cheat others on Wi-Fi almost undetectably).
that's not true. the input file is basically useless for figuring it out.
Masterjun wrote:
Zowayix wrote:
it's just somewhat disheartening to realize that if Game Freak doesn't change how their in-battle RNGs work (and they have no reason to), then it will basically be impossible to, in good conscience, ever submit a TAS of a Pokemon game post-Platinum here (since doing so would essentially allow any players of that game to cheat others on Wi-Fi almost undetectably).
I have a question, why would submitting an input file to TASVideos suddenly allow anyone on earth to manipulate RNG in online battles?
it doesn't.
not to mention, if someone did manage to find the battle rng, which uses the same constants as the normal rng and is super-easy to find, using the input file to a tas would be about the least useful means to gleaning info. there's info on smogon, info on projectpokemon, and considering xfr and i did literally all of the reverse engineering on this: http://www.smogon.com/bw/articles/bw_complete_damage_formula, i know a hell of a lot about how it all works and you're more than welcome to ask me.
and keep in mind, you can't abuse the battle rng at the VGCs(including regionals, nationals, and worlds), which is the one place that really counts, because it absolutely requires either an AR or emulator.
On a wild guess, when people stop playing Gen V on Wi-Fi, so that abusing the in-battle RNG could no longer be really used to cheat anyone in Wi-Fi battles. Which will probably be in like 2 more generations or something.
assembly instructions:
21XX = movs r1, 0xXX
he's changing the second passed argument for this pair of functions:
http://projectpokemon.org/wiki/PKM_File_Fields
setPKMStat(void* pPKM, PKMField field, int data)
getPKMStat(void* pPKM, PKMField field, int data)
A0-A6, 46-4B, and 0D-12 are arguments you can find here:
http://pastebin.com/R2inHTRV
No topic about this :3
Pokemon black/white 2!
Still fairly new with the English version, with an Exp gain fix patch.
Not sure about running a TAS my self but kinda interesting seeing its not being done yet.
Never played this game yet so don't know much about it.
Any knowledge about this you wish to share that would help would be great!
Honestly don't know where to start, never done a TAS my self :3
Starting off:
Starter pokemon
Male/Female Gender - I would assume it depends on the Rival mostly, I would assume he talks different depending on the gender u are.
Pokemon names length make a difference?
I did a vid up to first battle.
Nothing special:
http://dehacked.2y.net/microstorage.php/info/190539112/PB2-LTTP.dsm
Also question that dont really fit here but:
How do I resume a recording with save state?
ty :)
EDIT: Actually I figured it out
Press Play movie, select it with read only off
Then press record movie and select same file then press save state:
I hope :3
Alright I started a bit into the run:
Pick Male
Put A as name
Bring Rival's name to 1 letter long
-
Here I am for testing going to pick fire pokemon.
Question: Setting message speed to fast is the same as just holding B while messages are going on, is it worth it to change it?
Still not knowing how to RNG crit/dodge every turn, help on this?
I thought the Battle RNG from Platinum onward only advanced when it was called? How do you call it without using a move?
Is it possible to manipulate and get, say, all critical hits in Platinum or HG/SS?
you're right. the game only calls for a random number when you need one. to keep trying for a seed you would have to stand there just before the battle is starting and keep reloading a save so timer0, the rssi data, the time, and a few other things keep changing.
in gen 4 it's just based on the time, so you would have to keep reloading as the seconds change to get new seeds.
you can provide a sample that desmume will use. pretty sure that will work.
note the comments. mic, vcount, tick counter, vcount, etc etc. when this runs when the main game is seeding, most of those values are 00s. when you do it when you're getting into battle, they are initialized and are used.
this is the output from the array on the stack when the main game is seeding:
02FE36AC 00380761 MEMORY:00380761
02FE36B0 A81F0000 MEMORY:A81F0000
02FE36B4 B4C55689 MEMORY:B4C55689
02FE36B8 05111013 MEMORY:05111013
02FE36BC 00000461 MEMORY:00000461
02FE36C0 00000000 MEMORY:00000000
02FE36C4 00000000 MEMORY:00000000
02FE36C8 00002FFF MEMORY:00002FFF
note all the 0s.
now note the array on the stack when getting into a battle:
02FE3654 00F0C7CA MEMORY:00F0C7CA
02FE3658 A85F3174 MEMORY:A85F3174
02FE365C 3CC424DC MEMORY:3CC424DC
02FE3660 05111013 MEMORY:05111013
02FE3664 00021262 MEMORY:00021262
02FE3668 00000000 MEMORY:00000000
02FE366C 0D600170 MEMORY:0D600170
02FE3670 FC032EDF MEMORY:FC032EDF
much fewer 0s because the hardware and systems are initialized.
and keep in mind, the only reason there's 1 line of 0s in the second array is that the mic just isn't working right in desmume. that's the mic data element. if this was a real DS, that would be set to a couple of values.
this is how i know that:
ARM9:0207C74E E5 20 80 00 MOVS R0, 0x394 ; MIC sampling result
ARM9:0207C752 31 5A LDRH R1, [R6,R0]
ARM9:0207C754 0A 04 LSLS R2, R1, #0x10
ARM9:0207C756 01 1F SUBS R1, R0, #4
ARM9:0207C758 71 58 LDR R1, [R6,R1] ; MIC data storage address
ARM9:0207C75A 51 40 EORS R1, R2
ARM9:0207C75C 69 61 STR R1, [R5,#0x14]
note that the mic data result is stored to r5 + 0x14 and 0x2FE3654 + 0x14 is 02FE3668, which is the 0-ed line.
so to carry this to a conclusion, this array is hashed along with 20 bytes of garbage from the stack. it looks like this: http://pastebin.com/EVxNBAN4
then after the nazos and array are hashed, they take 8 bytes and make that the starting seed.