PPUser2018

RNG Reporter

Method: Colosseum/XD (RNG Reporter 10.3.2)

Direct Gen 7 -> Gen 7 trades (Quick Link Trade, Link Trade, Wonder Trade and GTS) do not add memories or residence data. Pokemon Bank does add some data though: Gen 6 -> Bank -> Gen 7 = OT Memories retained; Residence history removed. VC -> Bank -> Gen 7 = Residence updated (Latest added). In both cases, notOT Memories = when it arrived via Link Trade at... somewhere. The Pokemon remembers {random feeling}. Subsequent direct Gen7 -> Gen 7 trades will reset this to the default (seems to have a good memory, but it doesn't seem to be able to remember...). Based on personal testing, I believe Gen 7 -> Bank -> Gen 7 will update notOT Memories and Residence only if the Latest (notOT) Handler is different to that of the receiving game. I tested the following using my copies of Y, Sun, Ultra Sun and Ultra Moon: Sun (self-caught) -> Bank -> Ultra Sun = notOT Memories added; Residence updated (Latest added). Ultra Sun (self-caught) -> Bank -> Sun = notOT Memories added; Residence updated (Latest added). Ultra Sun (self-caught) -> Sun (via Quick Link Trade) -> Bank -> Ultra Sun (notOT Handler did not change) = no memories or residence data. GTS (origin: Ultra Moon) -> Ultra Sun -> Bank -> Ultra Sun (notOT Handler did not change) = no memories or residence data. VC Red -> Bank -> Ultra Sun = notOT Memories added; Residence updated (Latest added). ^ -> Bank -> Sun = notOT Memories updated (new notOT Handler); Residence updated (Latest updated and Past 1 added) Y (heavily traded Xerneas with full Residence history) -> Bank -> Ultra Sun = OT Memories retained; notOT Memories added; Residence history removed. ^ -> Bank -> Sun = OT Memories retained; notOT Memories updated (new notOT Handler); Residence updated (Latest added). As pk7 files do not contain the TID/SID of the Latest (notOT) Handler, I'm not sure if Pokemon Bank can detect whether the receiving handler is actually different if the trainer happens to have the same name as the current notOT Handler.

The game does not generate PIDs "using" a specific TID/SID. PIDs are randomly generated, and whether one is shiny depends on your TID/SID. Editing your TID/SID won't change how the game generates PIDs, but it will change which PIDs are shiny. If you copy your newly caught Pokemon over to your old save and change their TIDs/SIDs, there's a slim chance (1/4096) they could become shiny. Every combination of TID/SID has 2^20 PIDs that can be shiny, out of a total of 2^32 possible PIDs. When a Pokemon is generated in-game, a random PID is rolled, and the chance of a shiny PID is thus 2^20 / 2^32 = 1/4096. Having the Shiny Charm rolls two additional PIDs, and the Masuda Method rolls five additional PIDs, effectively octupling the chances of obtaining a shiny PID if the methods are combined. If a Pokemon is shiny locked and the game happens to roll a shiny PID, the PID is forcibly changed to become non-shiny; conversely, if a Pokemon must be shiny but a non-shiny PID is rolled, the PID is manipulated to become shiny.

Excuse my misunderstanding. I was under the assumption that getTimeInMilliseconds() was based on User RTC, so every "Met Date" would have the same set of results returned (86.4 million of them). As you said, if the function actually utilises Raw RTC (which is different for each system based on date of manufacture and can be reset by formatting), then there would be no direct correlation between "Met Date" and that date's possible seeds. The following details were what I failed to grasp: The RTC chip has the default date of 01/01/2000 00:00:00 set when system is manufactured, and the Raw RTC starts running from there. User RTC = Raw RTC + Offset. I conflated the default date of the RTC chip as having a direct relationship to the getTimeInMilliseconds() function. Thank you for resolving my confusion.

Ah, I see. Is the default date/time on the RTC chip not 00:00:00 01/01/2000? So getTimeInMilliseconds() would only be different for users who change the Raw RTC of their system. Of course there's also the number of CPU ticks added into the mix, and both values are then hashed to the produce the seed. My main thought is if I did RNG a Pokemon using a seed I obtained on my system today (based on CPU ticks + milliseconds), and then chose a desired frame (within the set of frames produced from that specific starting state), it's not feasible to ascertain whether that seed could (or could not) have been possible to obtain on a previous date. I suppose the possibilities are so vast compared to Gen 4 that it just doesn't matter. The thread at Smogon includes the following example: "if GetSystemTick() returns 0x12345678, getTimeInMilliseconds() returns 0x7d349cc000 (that means 00:00:00, 15 Jan 2016), then seed is 0xddcdcba7." I was actually wondering if a seed generator exists. In theory, one could choose a range of dates/times and CPU ticks to produce a list of seeds.

Thank you for the additional insight Kaphotics. Apologies for my rudimentary understanding as I only just started reading about Pokemon RNG so I'm still trying to grasp the differences between generations. With regards to Gen 5, I think I got confused with Smogon's part 3 write-up which references the Mersenne Twister "half" and the other "half" (PIDRNG), but I see now that it's 64-bit. If I wanted to RNG a Gen 6/7 wondercard using today's seeds, could the met date of the resulting Pokemon be changed (to a past date within its original distribution period) and still be considered legal? Or is it practically impossible to discern due to the use of SHA-256?

As far as I am able to understand the concept based on this early post over at Smogon, the initial seed for 3DS Pokemon games is calculated using 1) the number of CPU ticks that have elapsed since the CPU was powered on, and 2) the number of milliseconds since 00:00:00, 1 Jan 2000. Considering that the initial seed is basically the digest of SHA-256, is it practically impossible for any "Seed to Time" programs to exist? So even if we could somehow manipulate the message (inputs), it wouldn't be much use. The above train of thought stemmed from wondering whether certain PID/EC/Nature/IV/Gender/Ability combinations are theoretically invalid given a specified met date of a Pokemon, or can every possible initial seed be obtained on any given date? I know in Gens 4 and 5, not every seed is available on every date (some aren't even valid seeds in Seed to Time). Also, unlike Gen 5, where a 64-bit seed is split in half and each 32-bit half can be independently advanced, calls in Gen 6/7 reroll the entire 64-bit value, and I assume (0x41C64E6D * Seed) + 0x6073 doesn't apply anymore. When genning, I want to be as legal as possible (I know Nintendo doesn't care), which I believe involves using 3DSRNGTool to find a feasible frame with the desired spread and corresponding PID/EC combo.