Hahaha... I believe anyone can do that now. You missed out on the huge avatar fiasco where people had avatars so big that they stretched the page to over 5x the normal width. Titles are in here assuming you can still do it.
From your previous posts I thought that to reset for Entei in Colosseum you had to fight 9 guys + Dakim for it. But... I just fought the 9 guys, went back to save, then I didn't have to fight them again. <_<
Ok I believe I found a problem with your tool. I just remembered that 9.96 alpha has Pandora's Box for R/S that can handle live battery by using dates. Meaning that it should be accurately converting dates to seeds. Here is the problem I ran into. I used your tool to output seeds starting at 1440 minutes (Jan 1 2000 at 00:00). For the first 9 hours and 59 minutes I got a match but once the 10th hour was reached I didn't get a match.
I was following the RTC on my cart for a while. Was given two separate possible times so I had to follow it until a point where they split. The time that worked was what would have been Jan 2 2000 at 10:00 for the later time. At that point I got a seed that was completely different from what was expected (0962 instead of 0B80, or 07FC).
Edit: Bond is saying the seeding formula that you have (and Slash posted) might be wrong. < Disregard that Slash has it working enough for live battery stuff for himself.
I'm going to send this plan to Slashmolder to see if maybe he can implement it into RNG reporter sometime in the future.
Edit: How hard would it be to write a small program that tracks the RTC? Basically you enter the RTC time you got and the system time at the time you SR'd to get that RTC time. Calculate the offset then the program can display the system time w/ the offset, thus displaying the RTC time. I suppose it would be easier to use Unix time to calculate things or something (isn't that what it was made for?). And there would need to be a way for users to account for the change in system time due to daylight savings. Of course users can sync their system time to various sources like time.gov if they have admin privileges before they run the program for accuracy.
So I've been tracking my RTC and I thought I had a fairly low value. Could have been one of two things but at a certain point they split and give different values. But something really fucked up happened. I got a completely different seed than expected. I'll edit this VM once I figure out a possible time.
Edit: I'm not getting a possible match period. 23 minutes between seeds 07FD and 0962. That can't be right... I believe seed 7FD comes from either 1121 minutes or 2021 minutes (I'm leaning towards the second one).
Edit 2: Using your tool if I do list seeds with a high starting minute like 4326800 it somehow gets messed up. :s Still I can't match my new seeds of 09xx with my older seeds. wtf? I wonder... can you take a look at this and see if it matches what you have in your program?
Hm... If you could write the program to export the list of times that would make it easier as once could use excel to calculate the minute differences between times. As of right now I guess I can just type them out manually.
Edit: Oh wait crap that probably won't work out nicely. Oh well.
Seems like everything he gave you is most of what is already known. The only thing that is a problem is that if you miss a seed you'll probably have to wait about 45 days before you're able to hit that seed again. So the better solution is to search for another seed in the near future. Another potential problem is how will people know what Month/Day/Year their game is at.
Hm... to find the current RTC value you would just gather a bunch of seeds at specific times, enter it into your tool (searching 11 years worth of minutes just to be sure), and search through the results for minutes given that line up with the minutes that the game was booted?
Yeah he confirmed that's the memory address of the RTC. I'll edit this VM shortly with a lua script that Kaphotics is making to calculate possible seeds given a starting point from a spread.
Edit: script Grab again if you got it before seeing this.
use this to find a starting point by entering a spread
Pretty sure the script is independent of the game you're playing. It just uses VBA to run.
Edit 2: Ok Mat is saying the RTC would start when it's first powered (aka when it's built). At that point it starts at Jan 1 2000. This would explain why GoldenBanana said his RTC was quite a ways behind considering that it came out in 2002. So if it could somehow be reset that's the starting point.
Ok I've been picking up a lot of things from the IRC chat here. Mat says the RTC value is stored at 3000460 in the RAM (he thinks). I'm not sure if it actually starts at 5A0 or not but the default date when the battery is dead is Jan 1 2000 at 0 min/hours (which yields 5A0 of course). So I'm guessing when the RTC first runs it goes from there. When does it first run though? When it's powered? Or when the game is first booted? Still some questions...
If you're interested I've been toying with live battery abuse for a few weeks now mostly because I'm too lazy to open my game to modify it to test RNG Reporter.
I've already abused my ID/SID with it. I'll probably add it to the R/S capture searcher once I finish it.
Oooh Kaph just gave me a brilliant idea. One could use an emulator to see if the RTC value is stored in the RAM. If it is an AR code could be made to display the RTC value somehow to view the RTC directly. With an emulator you know exactly what the RTC started at when you boot the game.
Also Slash just pulled out the seeding function here. Pretty much what FractalFusion got.
v = (1440 * d) + (960 * th) + (60 * uh) + (16 * tm) + um;
x = floor(v / 65536);
I call x the seed cycle since since it stays constant as the seeds increase from 0000 to ffff, and then it increments by one.
edit: I'm not quite sure what I mean either. Let me think about this for a while, but I feel like v isn't really how many minutes the RTC has been running, since at 23:59 on any day, the part of the equation that makes up the minutes equals 2189, but there's only 1440 minutes in a day. Do you see a problem with that?
Oh man if I could freeze the RTC by removing the battery that would be amazing but unfortunately that's not the case. No battery always yields 5A0. If I put it back in the RTC acts like it was never taken out.
I'm going to leave it out overnight and see if that resets it.
I'm really impressed with the progress you've made on live battery abuse. But when I was working with this, I wasn't concerned with how many minutes my RTC was running, but rather what the seed cycle (x, an 8-bit number) was. If you could write a program that could spit that out, then you would only have to worry about how far off your battery is from the real time.
Well it's not hard to find a seed... Use this to find a spread, take the seed value given and put it into RNG reporter's Researcher tool as the seed, select LCRNG [R], display as many frames you want to advance, and output it. Open the text file, search for 0000 under 16 bit high, and enter the corresponding 16 bit low value into your tool as the seed. Still that is fairly time-consuming but not that difficult.
However it's far more time-consuming to wait for the minute that the RTC will give the seed you want, especially if you end up not hitting your frame. Then what? You have to wait another ridiculous amount of time for the next seed (although some seeds are repeated fairly quickly but that's not to really be relied on). This just seems to be an exercise in frustration waiting to happen. Although I suppose this would make R/S abuse w/ the RTC really easy.
I'm going to try to leave the battery disconnected overnight to see what happens.
I noticed when I first turn on the game after reconnecting the battery I still get the dry battery error but when I SR it goes away. I'm thinking the error only shows up if the RTC holds the default value of 1 day. That would mean the clock starts when the game boots up.