Jump to content

Recommended Posts

So to confirm what @Bond697 said, if someone magically is able to get the slave payload to work with another master ROM, the jirachi would (at the very least) have the wrong PID algorithm result due to how the seeding works.  That is granted we can get the global variables to match up, which sounds difficult (impossible?) using a master ROM from the wild.

  • Like 1
Link to post
Share on other sites
  • Replies 301
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Hello. This thread is great! Sorry, I'm from a country with Mount Fuji. My English is very childish. Well, I found a method to replace the "client.bin" of the "Ruby_And_Sapphire_Rev.gcm" with "

I found the JPN Berry Glitch Shiny Zigzagoon GameCube Distribution hidden away on the Japanese Interactive Multi-Game Demo Disc from January 2004! If its listed on the discs menu system its far from o

Posted Images

yeah i think we're out of luck here unless someone has the actual gba distro cart for the negaiboshi.  to figure out how it works anyway. 

if someone does actually have it and is weary about giving it to anyone, remember, no one knew i had the 10anniv rom for more than 5 years, and even then it became known only because other people let it out.  B|

 

e: same goes for pcjp2003 and anything else we need info on.

  • Like 3
Link to post
Share on other sites

@Bond697 please correct me if I am wrong on any if this.

I read through most of the code last night and the rng looks like it is seeded by the result of a calculation of magic numbers, possibly time related? X =(1440 * A) + (60 * B) + C. This number is changed before used as a seed by doing this: (X >> 16) ^ (X & 0xFFFF).

Held item uses the same number X. Question is, does A,B,C change? Like from an RTC? Also even if it doesn't, the seeding creates data loss so we can't link held item to the seed regardless.

  • Like 1
Link to post
Share on other sites
37 minutes ago, Sabresite said:

@Bond697 please correct me if I am wrong on any if this.

I read through most of the code last night and the rng looks like it is seeded by the result of a calculation of magic numbers, possibly time related? X =(1440 * A) + (60 * B) + C. This number is changed before used as a seed by doing this: (X >> 16) ^ (X & 0xFFFF).

Held item uses the same number X. Question is, does A,B,C change? Like from an RTC? Also even if it doesn't, the seeding creates data loss so we can't link held item to the seed regardless.

days*1440m/d + hrs*60m/h + m

standard initial seeding for R/S from the RTC storage

  • Like 1
Link to post
Share on other sites

Yeah, so this is what it looks like it is doing (roughly) is this:

seed (RTC minutes like R/S, with the xor high and low bits)
pidh
pidl
if pidh is 0, or it with 0x2003
if pidl is 0, or it with 0x327
-- pid is not used
pidh (again)
pidl (again)
if new pid is shiny, increment pid until not shiny. Increment maxes out at 8.
iv1
iv2

item is based on the original RTC seed calculation, which is indeterminate based on the seed because the RTC seed is xor'd before its sent to seed the RNG.

I never dived into R/S seeding, so I am not sure how the RTC is calculated, like based on minutes from an epoch, a random date, etc.  I also don't know the seed period of GBA games, so maybe someone can chime in with that info.

  • Like 2
Link to post
Share on other sites
11 minutes ago, Kaphotics said:

The latest commits of PKHeX support viewing of the saved RTC values, a dry battery yields 5A0 which is 1 day.

Basically it's just an elapsed time since initial power on (iirc).

Wouldn't surprise me if those debug pid values are a date :) 03/27/2003

Yeah they are a date.  It probably corresponds to when they were writing the code.  I think that was around a month before the first gen 3 event (5th anniv eggs).  We know the first distribution used the same code too.

Also Bond found in R/S a binary encoded decimal representation of the date.  It was in IRAM ~0x3000460.  It looks something like 0x17 0x04 0x19 0x11 0x40 0x00 (for example).  This is used to generate that RTC value you mentioned.

Link to post
Share on other sites
1 minute ago, coltonsmogon said:

Meaning 65535 "days" are possible and 65535 possible Jirachis exist because of this logic...

If the seed is 16bit then all that has to be done is brute force seeds from day 1 to see the minimum time for a seed. I'm pretty sure it'll be low enough such that all seeds are possible to obtain prior to the event.

Link to post
Share on other sites

My question is, can we see about writing some code with this knowledge and our currently known trash byte Info that either takes an RS save and generates a Jirachi based on the RTC value, or B, checks and bruteforces all 65536 Jirachi spreads to see if the  incremental shiny check could ever have hit a wall of 9 or 10 failed incremental PID modifications, resulting in shinyness like on Wishmaker???

Link to post
Share on other sites

OK. That IS sad, but we DO have Wishmaker (maybe even meteor.)

BTW can someone write this code into an online repl.it? Also, are any Jirachi flawless-capable???

Edited by St. GIGA
Added questions
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...