MrCheeze's video: Ocarina of Time - any Slingshot Skip TAS Only

Since the discovery of the Kokiri credits warp, there have been two holy grails left for OoT any% speedruns: ocarina skip and slingshot skip. (Sword/shield/nuts cannot realistically ever be skipped.) On Jan. 18, Jolin012 and r0bd0g found the first ocarina skip, but it was kinda slow, dependent on an RNG seed drop, and required calculating a new heap manip: https://www.youtube.com/watch?v=b45xe0GooZ4 On Jan. 30, before we had even worked out a new heap for the previous method, Blini found a new ocarina skip that suffered none of these issues: https://www.youtube.com/watch?v=hYXq5NgEWcI So all that remained for any% to be "solved" is slingshot skip. The reason slingshot has been needed so far is this: Using SRM, we can make it so that the code intended to run a certain immobile rock's draw function instead jumps to elsewhere in memory. But via SRM alone, we can only jump to locations within the actor heap, not to truly manipulable locations such as filename. But slingshot seed rotation gave us one extremely manipulable 32 bit word on the heap, so we were able to use draw pointer SRM to jump to seed rotation, and from seed rotation to filename, and use filename to credits warp. Eliminating slingshot from the run means either finding something else on the heap we can manipulate enough to form a jump to filename, or else coming up with a new ACE entrypoint other than draw pointer. One candidate for this is short coordinates. Certain actors, such as deku nuts and spin magic, have their coordinates stored within them as short ints. In particular, their Y and Z coordinates form a single 32 bit word that we can use as an instruction for ACE purposes. Unfortunately we're constrained by what Y and Z coordinates are actually achievable in Kokiri Forest, so we can't form a "jump to filename" instruction. One of the few meaningful instructions we can form is "jr", meaning jump to the address currently located in some register. Taking a look at what addresses happen to be located in registers at this time (https://pastebin.com/PGc5f6aH), most of them don't seem to point to manipulable memory... with one notable exception. By some amazing freak coincidence, register $t3 JUST HAPPENS to be pointing exactly at controller 3 inputs in memory. That's right, controller 3 is making a comeback with this strat. By inputting an exact input on controller 3 - including, most notably, a unit-exact joystick input - we can jump to filename and finally use the filename itself in order to trigger the credits warp, in the same manner as the previous strat. So, the overall ACE flow goes like this: Immobile rock draw function pointer (801F9004) - using SRM, we manip this to have a value of 801F8000, so that execution jumps there when we look at the rock. Spin magic YZ position (801F8000) - climb the cliff and use the setup that I do to set its Y position to 0160-0x017F (decimal 352-383) and its Z position to XX[048C]8 (decimal 8+64*n). Anything satisfying these constraints will form the instruction "jr $t3", which jumps us to the address already there for us in the register, which is 801C84E4. Controller 3 (801C84E4) - Should have the inputs dup + cdown + (105,125) , which forms the instruction "j 8011A5F4". Filename (8011A5F4) - This filename uses the same code as in the previous strat: "3.　dベNgべ" which is 03EADFC8 A3B8CB53 which is "jr $ra; sb $t8, 0xCB53($sp)" which will set the "next cutscene" value to FFF8 on every other frame the kid rock draws, and then return. Of these steps, only the need for an exact controller 3 joystick makes this whole strat a TAS one. But with this particular execution path, there's no way around that requirement.