Considerations for Gen 2 Glitchless timing rules

(Just writing this up as a reference in case this ever comes up again.)

There are two complicating factors for RTA timing rules for Gen 2 glitchless runs with no clearly obvious best solution: Lucky ID manipulation, and StartSecond manipulation. First, let's review the relevant mechanics and their implications, before assessing the possible rulesets to account for them.


=== MECHANICS ===

(1) Lucky ID (manipulated for Master Ball from lottery)

Here is the disassembly for the "LoadOrRegenerateLuckyIDNumber" routine: https://github.com/pret/pokecrystal/blob/e6046eaf09f91e7bb1df402be70c151847d3eb98/engine/menus/intro_menu.asm#L305-L329. It is called when selecting New Game, or if the "lucky number show game over" flag is set when talking to the lottery guy in Radio Tower or tuning into the lucky number radio show.

If wCurDay <= sLuckyNumberDay, the current lucky ID number is kept. Otherwise, a new lucky number is randomly rolled and stored in both RAM and SRAM (save data), and sLuckyNumberDay is reset.

The code was probably written as-is to prevent the easiest form of save scumming. It does so by persisting the new lucky number to save data, even when the player does not save the game (i.e. you can't just keep resetting and talking to the guy until he gives you a winning number). RNG Manipulation was almost certainly an afterthought (at best), though the lucky ID generated at new game only avoids being re-rolled when talking to the lottery guy if StartDay is Sunday and wCurDay=0 (i.e. StartDay/Hour/Minute/Second + elapsed RTC doesn't roll over past Sunday).

The implication is that unless you clear your save data (with Up+Select+B on the title screen), your game has a lucky ID already stored before starting a New Game. It does not matter if you don't have a save file, and it does not matter if you have a dead battery that can't hold a save -- you still have a pre-existing lucky ID saved.

(2) StartSecond/RTC

Here is the disassembly for the "FixTime" routine: https://github.com/pret/pokecrystal/blob/3eacab563d0e1ab5557c2443556a7a5e58d14cad/home/time.asm#L129-L143. This is the routine to blame for why a StartSecond of 0 is desired for RNG manipulation, as it is the only way wStartSecond + hRTCSeconds will avoid ever reaching 60. (As an example of its effect, the first frame of Raikou Manip v1.0 worked for 60/60 RTC second values when StartSecond was 0, 56/60 values when StartSecond was 1, and 52/60 values when StartSecond was 2.)

If a save file is not present, RTC is zeroed roughly 14.4 frames after the game is "initialized". It continues to be zeroed any time the game goes back to the copyright screen. From that point RTC keeps ticking to match the amount of real time that has elapsed since it was zeroed.

If a save file is present, RTC will not be zeroed when the game initializes, and the clock will continue to tick instead. RTC continues to tick even when the game is powered off. If you start a new game with an old save file still present, the old RTC values will still be preserved and continue to tick.

When setting the clock (confirming the time in the intro or during a clock reset), the game calls the "InitTime" routine: https://github.com/pret/pokecrystal/blob/3eacab563d0e1ab5557c2443556a7a5e58d14cad/engine/rtc/rtc.asm#L155-L198. This effectively reverse engineers the "clock time" at which RTC was zeroed, and uses that as the base time (StartDay/Hour/Minute/Second) for computing the in-game clock time at any given point.

TAS gets a StartSecond of 46 on Crystal and 49 on Gold. Always starting without a save file would mean attempts on both games need to waste 45+ seconds waiting for StartSecond to hit 0.

Alternatively, doing a session of attempts with a "secondary timer" can be done by tracking the game's RTC starting from an attempt without a save file. Subsequent attempts during that session take place with a save file present, and you wait to press new game on those attempts until the secondary timer aligns for a StartSecond of 0. This approach aims to maximize reset efficiency, at the cost of some real time due to an extra textbox at the first save (confirming it's okay to overwrite the previous save file).


=== POSSIBLE RULESETS ===

With knowledge of these mechanics in mind, I see 4 options that could reasonably be considered for Gen 2 glitchless timing rules, which are as follows:

(1) Allow starting runs with a pre-existing save file

This is the status quo as of this writing. The main con is that people question whether it is NG+ since there is a save file present and the lucky ID was manipulated "on a previous file". (Those people are ignorant and shouldn't be a major consideration.) Allowing a previous save file also means it's theoretically harder to verify a console run from video, but the technology to do so does not currently exist in this universe.

(2) Disallow starting runs with a pre-existing save file, but allow starting runs with a manipulated lucky ID in save data

In terms of gameplay impact, this is effectively no different than (1), and it even saves a textbox vs attempts that start with a save file present. Options are still set before New Game, and no time is wasted getting StartSecond=0. This would effectively force runners to wait 45+ seconds for each reset if they wanted to use StartSecond=0 for manips, so reset efficiency would be negatively impacted.

(3) Disallow starting runs with a pre-existing save file or with a manipulated lucky ID, time still starts on New Game

In terms of gameplay impact, this is effectively no different than (1) or (2), since using fast options allows manipulating the combination of lucky ID and StartSecond=0, while setting options before new game (example: https://www.youtube.com/watch?v=le8dfRs3u3c). Runners would be forced to visibly clear save data before every attempt. This would effectively force runners to do a 56+ second manip (involving at least one 4-frame window). Frame Type=1 and stereo audio would likely become the norm for optimal attempts, since anything else would cost time to set. With a calibrated setup, runners should be able to hit the LID manip over 95% of the time, so they would probably not bother checking to make sure they hit it, but the rare run that misses LID and gets to Goldenrod would be devastating, although it would make for some good schadenfreude Twitch clip material.

(4) Disallow starting runs with a pre-existing save file or with a manipulated lucky ID, change time to start on hard reset

The other 3 options are effectively the same, so this is the only option to consider that substantially changes what a run might look like. Unfortunately, it completely blows in terms of practicality. Runners would be still be forced to visibly clear save data before every attempt. In terms of gameplay impact, skipping lucky ID manip becomes a more serious consideration, since the time spent manipulating it eats into its timesave. And waiting 45+ seconds for StartSecond 0 probably can't be realistically considered, so you'd likely take a StartSecond in the 40s. With enough magic and botting work, you might be able to get a suite of manips whose success rate is only moderately dented. In sum, everyone except the people hellbent on enforcing a mostly irrelevant standard lose with this option.


=== CONCLUSION ===

Option 4 is nice in theory, but is an absolute disaster practically speaking. Option 2 is pretty much pointless since it is still NG+ in the same way Option 1 is, it just cosmetically looks less like NG+. If we were to change, Option 3 would be the cleanest option from a policy standpoint. But seeing as Option 3 is substantially more annoying to runners and results in no effective gameplay difference, the best option is sticking with the status quo (Option 1), and accepting that from time to time you may have to explain the logic behind why it's the best solution.