Every GDQ, I wonder if I should take up TASing, and if no one else is running these games, maybe I can.
RTA speedrunners have already manipulated for IVs and encounters, so hopefully we can extend that indefinitely. But in-combat manipulation will take some experimenting.
But since I'm new at this, I think the first WIP would just be a loose proof of concept, following the RTA routes. I'm sure running that will give us more of the info I need.
The main route is a manip'd Tepig into manip'd Excadrill. We can try to guts route, but Excadrill's base stats and movepool are so good, we may not need it.
I'm not sure if there's a preference between this or B2/W2. W2 seems a few minutes faster, but both runs are about 3:10 to 3:20.
Challenge mode is considered a separate category because the added XP balances out the higher levels. Easy mode is actually considered harder, because XP is hard to come by.
https://www.speedrun.com/pkmnbw1/thread/iia5e
It's probably faster to use Tepig line all the way to the end for this game. I think it would be good to make becoming the champion the end point of the run, like Kaphotics's run did, since defeating Red is considered the end point of G/S/C/HG/SS runs.
You might find Masterjun's Black 2 WIP(http://tasvideos.org/userfiles/info/44378127928492667) helpful, although I can't sync it.
Agreed. Excadrill is a BW2 strat, because where you get them in 1 is too low level, lacking moves like Dig, and just before the bug gym. I'll keep an eye out for possible improvements. I'm just more familiar with BW2.
RTA runs seem to end after N's speech, just before credits. It looks like last input on his speech, which is consistent with TAS timing anyway.
The biggest issue now is sorting out my setup, because I'm not getting experience after fights. I know that's a solved issue, but I'm not sure if I have the wrong ROM, or the wrong emulator (RTA runners are on 0.9.11).
There is plenty of documentation on IV manips based on date, so I'm not worried there.
You are probably using a wrong ROM if anti-piracy is in effect.
The best choice for TASing is Desmume 0.9.9 at this point. While Desmume 0.9.11 is probably more accurate overall, TASes made with 0.9.11 are hard to sync due to SRAM issues.
I know the RTA runs end after the Ghetsis fight, but IMHO defeating the (supposedly) hardest boss that rolls credits is the better ending point when you don't need to do anything different before rolling credits for the first time, and that's how it works for Johto games.
I'm on Desmume 0.9.9, and I don't want to deviate from it without a very good reason. I don't think the experience "bug" is because of emulator versions.
Do we know what ROM that Masterjun run is on? It sounds like that experience thing is usually fixed with a code (memory editing), or patched ROM. Given this is a TAS recording, the patched ROM is probably the only option.
Also, given this is a 3-hour run, let's start with ending at the Ghetsis fight. We can branch off a postgame "100%" run after.
The patched ROM is working, but given the name is just "Pokemon Black Version.nds", I'm worried these might not be consistent, and we'll be fighting desyncs.
I'll try to WIP to hitting lv 6 or something, just to make sure we're not wasting time.
It does!
Except the game does not actually bother to poll the microphone most of the time. If you decide to go use the sound test for whatever reason you can see microphone data gets polled just fine. Once you get out of that however the value just stays there, unchanging. If the microphone is never polled, the values will just stay at the default 0 values.
Similarly, the RSSI pool values will just always be 0 unless you have the C-Gear enabled. If you enable C-Gear you can see the values change around, if you turn off the C-Gear the value stops changing (which in theory you would do anyways since it should cause more lag (although this seems reduced at least on emulators) along with sporadic RNG calls which might not be wanted, also enabling C-Gear reseeds IVRNG so if you have a long running IVRNG manip in a TAS that might not be wanted).
OSi_TickCounter is just counting overflows from timer0. This just happens at around 8.5ish frames, so not particularly interesting in any case.
Combining this with the 4096 possible input states
4096 is not quite right, it's actually 8192 (Lid Close counts as an input here; you can have it closed for a frame and reopen the next frame to avoid the game having any sleep mode due to lid close). Also, the touch position is part of the seed here, so you get every single touch coordinate combined with those input states, so 8192 * 256 * 192 = 402653184. Also can chuck in another 8192 for not touching (this is different than touching at 0, 0), giving a total of 402661376 just from key input and touch input.