(Link to video)

Emulator information

  • Emulator: BizHawk
  • Emulator version: 2.4.1
  • Profile: N64 Tool-assisted Speedruns
  • Core type: Pure interpreter
  • Video plugin: GLideN64 (default settings)
  • Video resolution: 320x240
  • Controllers: 1 and 3

Game information

Game version: JPN 1.0

Run goal

The goal of this TAS is to beat The Legend of Zelda: Ocarina of Time as fast as possible, without any restriction. This category is widely known as any%, and takes advantage of the Stale Reference Manipulation glitch to achieve Arbitrary Code Execution and reach the credits.
The Japanese version of the game was used because of faster text. The version 1.0 was chosen because the setup to manipulate the memory requires this version of the game.

Introduction

We all thought Ganondoor would remain the fastest way to beat the game... but we were wrong !
Since the last official submission on this website, the Get Item Manipulation glitch was found in 2015, which saved a little more than a minute according to this unofficial TAS, but was not possible to do on Nintendo 64 under normal circumstances and required the usage of Rice video plugin to work on emulator. This route remained the same for years until a new major glitch has been found: the Stale Reference Manipulation glitch, or SRM for short. This glitch enables us to achieve Arbitrary Code Execution, or ACE for short, to warp straight to the credits. After this glitch was applied to any% mainly thanks to MrCheeze's work, I made a TAS of it which ended up with a time of 6:54.27. However, there was one big problem with it: the route I used was intended to be used by speedrunners. Therefore, the advantages that TAS has over real-time speedrunning could not be exploited to save even more time. Moreover, I used the Mupen64 emulator which is banned from this website, because I was expecting this category to evolve since ACE was fairly new. Immediately after I published my TAS, Tharo contacted me and was motivated to work on a route that would take advantage of TAS powers to reach credits faster by using controller 1 and 3 inputs. After some failed attempts, we successfully found a setup that worked and avoided the game over, which itself saves about 12 seconds ! This time, I tried the Bizhawk emulator for the run to be publishable on this site since it is a big improvement. The final time for this run is 6:37.33, which is 16.94 seconds faster than my previous TAS, and 13 minutes and 32 seconds faster than the previous official submission on this website. Although the bk2 file indicates 9,432 re-records, it is actually much more than that because I reproduced some inputs from my previous TAS, which has 20,793 re-records. I think this new TAS also has around 20,000 re-records in reality.

The SRM glitch

In October 2019, Glitches0and0stuff noticed a weird behaviour of boomerang when changing rooms while it is grabbing an object. We can observe that the object the boomerang is holding changed and was replaced by a door. Similar instances were also observed with bomchus in the past, notably one back in 2007, over 12 years earlier. However, what changed over 12 years in the Ocarina of Time community is our tools to analyse the game that became way more sophisticated and enabled much deeper look into the memory of the game to understand this glitch. Interestingly, it was noticed that this glitch enables to write some data in some memory locations based on how it set up. By manipulating the structure of the memory, we can take advantage of this glitch to write specific data into a specific location to give special effects to objects. Only two weeks after Glitches0and0stuff's video, he found an interesting application that consists in editing the chest contents. Two more weeks later, the first instance of ACE was achieved, and another month later, Total Control ACE was achieved which truly broke all limits of the game.

Route description

This part has been written by Tharo and is going to explain in detail how this route exploits the SRM glitch to reach the credits:
Actor
A dynamic, interactive game entity whose state may evolve during gameplay. For example: Link, Kokiri Children, Rocks and Signs
Actor Heap
The dynamic memory arena in which Actor Instances and Overlays, and possibly other data can be found
Actor Instance
Data pertaining to a particular instance of an actor, one of these is loaded for each actor and contains data common to all actors (position, rotation, flags, etc.) and specific data (i.e. in Link, information for his shield hitbox)
Actor Overlay
The file in which an actor's code and data that is the same for all actors of that type is stored. Only one of these is allocated for all actors of the same type.
MIPS
The CPU Architecture of the Nintendo 64. It defines the assembly instruction set used by the CPU.
Culling
Actors that are sufficiently far off camera will not update or draw.
Wonder Item
An actor present in Kokiri Forest responsible for handling giving you blue rupees for jumping the platforms in time.
Cutscene Pointer
A reference to tell the game where the data for the cutscene currently being played is located.
Stale Reference Manipulation (SRM)
A use-after-free bug which allows us to continue writing data to actors that are no longer loaded. There are several ways in which this can be achieved but in this run we only use held actor SRM. If an actor is grabbed by link but is culled and subsequently unloaded, the reference to this actor is not invalidated and data such as position and rotation values are still written to where this actor used to be located in memory. If something new loads into the space the grabbed actor's instance used to occupy, those values still being written will corrupt the newly loaded entity in possibly useful ways.
Throughout the run, actions are performed to set up the game's dynamic memory arena in an effort to line up a MIPS branch instruction with the rotation value written with SRM in order to redirect it to a location in memory where we can write our own code. By shuffling different actors around in memory with the methods described below, we can align where we write with SRM with actor overlay code and modify that code to our benefit.
By collecting permanent rupees in Kokiri Forest, more free space will be available leading to different permutations of heap entities.
There is a loading transition between the Deku Tree clearing and the Kokiri village which unloads actors in one area and loads new actors for the other. This can be exploited to shuffle actors around in memory even further. By traversing this loading transition several times with a combination of charging a spin attack (which loads its own actor)/not charging a spin attack and looking towards Mido/looking away from Mido (as some allocations are sensitive to camera angle) we can move everything into the correct positions in memory for later.
Getting Walking While Talking off the crawlspace and sign, we load the circle of rocks near Mido's House. We cancel Return A by slashing our sword and recoiling off a rock, making the camera begin to zoom out towards the crawlspace. Before it gets too far away, we pick up the rock which culls soon after due to the camera getting too far away. The rock we pick up is the one that results in the grabbed actor reference eventually lining up the way we want.
With the culled rock held we make our way blind through the loading transition, which unloads the rock and allows new entities to allocate into this space, achieving SRM.
We traverse the loading plane once more to return to the village area and shield-drop the rock in the angle range 0x821A to 0x8245 to corrupt a branch instruction in the Wonder Item actor overlay to point into Link's actor instance.
We point the branch instruction to direct execution onto two adjacent 16-bit values, both of which we manipulate into a single valid MIPS instruction beforehand. These values are the "movement angle", the angle Link last moved towards, and the "target angle", the angle link last targeted or used a spin attack towards.
We manipulate these angles such that they form 080475E4, which is `J 0x8011D790`, or "Jump to 0x8011D790"
Located at address 0x8011D790 is the most recently polled inputs from each controller, with some additional status information. Only controllers 1 and 3 are polled by the retail releases of the game, controller 3 being available to delete save data in the event of a corruption by an input code. Each controller is 6 bytes long, 4 of which are the inputs themselves. Since MIPS instructions are all 4 bytes long and must start at an address that is a multiple of 4, we can only trivially form two instructions from both Controller 1 and Controller 3's input as they are the only ones that align properly, so not being able to use Controller 2 and 4 is not especially impactful.
With controller 1, we perform arithmetic on the N64's GP Register (Global Pointer) which goes unused by the game due to the settings it was compiled with. This gives us a useful temporary space in which to load values to and then store them where we want on the next frame. However, we can only hold one temporary value at a time and not all load/store instructions are available with the possible inputs we can form with controller button presses.
With controller 3, we run another jump instruction to safely resume game execution to prevent crashing on invalid instructions following our carefully crafted controller input values.
The controller inputs we perform at this stage are as follows:
Controllers (FORMAT: Number: Buttons, (StickX, StickY) ; Hex Value ; MIPS Instruction)
Frame 1: (Loads the first value to store to the Cutscene Pointer)
1: Z, D-Down, R, C-Up, C-Down, (-16, -16) ; 0x241CF0F0 ; ADDIU gp r0 0xF0F0 ; Adds the value 0xF0F0 to zero and stores the result in GP
3: D-Up, C-Left, C-Right, (94, -69) ; 0x08035EBB ; J 0x800D7AEC ; Jump to 0x800D7AEC
Frame 2: (Stores lower half to cutscene pointer)
1: A, Z, D-Down, D-Left, L, R, C-Up, C-Down (29, 106) ; 0xA63C1D6A ; SH gp 0x1D6A(s1) ; Stores the value in GP to s1 + 0x1D6A
3: D-Up, C-Left, C-Right, (94, -69) ; 0x08035EBB ; J 0x800D7AEC ; Jump to 0x800D7AEC
Frame 3: (Loads the second value to store to the Cutscene Pointer)
1: Z, D-Down, R, C-Up, C-Down, (-128, 55) ; 0x241C8037 ; ADDIU gp r0 0x8037 ; Adds the value 0x8037 to zero and stores the result in GP
3: D-Up, C-Left, C-Right, (94, -69) ; 0x08035EBB ; J 0x800D7AEC ; Jump to 0x800D7AEC
Frame 4: (Store upper half to cutscene pointer)
1: A, Z, D-Down, D-Left, L, R, C-Up, C-Down (29, 104) ; 0xA63C1D68 ; SH gp 0x1D68(s1) ; Stores the value in GP to s1 + 0x1D68
3: D-Up, C-Left, C-Right, (94, -69) ; 0x08035EBB ; J 0x800D7AEC ; Jump to 0x800D7AEC
Frame 5: (loads the cutscene value to store to current cutscene)
1: Z, D-Down, R, C-Up, C-Down, (-1, -3) ; 0x241CFFFD ; ADDIU gp r0 0xFFFD ; Adds the value 0xFFFD to zero and stores the result in GP
3: D-Up, C-Left, C-Right, (94, -69) ; 0x08035EBB ; J 0x800D7AEC ; Jump to 0x800D7AEC
Frame 6: (stores cutscene value to current cutscene)
1: A, Z, D-Down, L, R, C-Up, C-Down (-91, -38) ; 0xA43CA5DA ; SH gp 0xA5DA(at) ; Stores the value in GP to at + 0xA5DA
3: D-Up, C-Left, C-Right, (94, -69) ; 0x08035EBB ; J 0x800D7AEC ; Jump to 0x800D7AEC
The registers at and s1, at the time of jumping to controller inputs, have the values:
- at = FFFFFFFF 80120000 | Intermediate value for accessing game save data beginning at 8011A5D0
- s1 = FFFFFFFF 801C84A0 | Pointer to the "Global Context", containing information about the current state of the game.
At address 0x800D7AEC is code to restore the stack pointer by the required amount and a jump to the return address register to resume normal execution.
The code we execute here is to load two halves of the address at which one of the two Kokiri Forest credits cutscenes is at and store them to the Cutscene Pointer. Once this is done, we store 0xFFFD to the "current cutscene" value, causing the credits to immediately play, ending the run.

Rupee route

In order to perform SRM, the sword, the shield and Deku nuts are needed. The shield and Deku nuts must be bought for 55 rupees. To collect this amount, a route has to be chosen with some constraints. First of all, as Tharo explained in the previous section, this route requires to collect all permanent rupees in the Kokiri area in order to set up the memory. These rupees themselves make 22 rupees. Another constraint is that we also have some rupees that are directly on the way and that require extremely little to no time to get. These rupees make another 15 rupees. Therefore, we already have 37 rupees collected normally. The remaining 18 rupees have to be collected among rupees that can be reached without loosing a significant amount of time. The map below (taken from https://www.vgmaps.com/Atlas/N64/ and edited by me) sums up the situation.
We see an interesting option here. We can manipulate bushes so that they always give 3 rupees (1/16 chance). Fortunately, 18 is a multiple of 3 so 6 perfect bushes just fulfils the rupee requirement. Moreover, they are also on the way to the hidden permanent blue rupee located in the sign.
When Tharo was adapting MrCheeze's route for this TAS, I suggested him to research for a way to skip the permanent blue rupee on the bridge, as well as the permanent blue rupee behind Mido's house. The reason is because both of these rupees take too much time to collect. Notably, it is possible to compensate these 10 rupees by taking the blue rupee near the bush in the sword area and the blue rupee in the shop. Unfortunately, no setup was found after researching with simulation tools. I even suggested to check the versions 1.1 and 1.2 of the game to see if they are different enough to permit a setup, but it turns out they are not different enough to have different setups.

Section by section

Filename:
From my previous TAS, we notice that I no longer put a special filename. This is because Tharo's adaptation of the route bypassed this requirement.
Link's house -> Crawlspace:
This section is very straight-forward since it has been optimised since years. I only had to redo inputs from my previous TAS for this part.
Crawlspace -> Sword:
We notice here that I did different movements than traditional TASes to reach the blue rupee. These differences did not end up saving time since going any faster would result in link hitting the rolling rock. However, I managed to save 6 frames over MrGrunz and Bloobiebla's TAS from the blue rupee until the sword chest. This improvement comes from the fact that I somehow got a good positioning before the last turn that enabled me to not have to walk for 6 frames before the last sidehop to reach the chest.
Sword -> Crawlspace:
After the sword the movement remains the same in my previous TAS until the crawlspace, which ties traditional TASes as well.
Rupee collection:
This section is one of the hardest of the run. Although I explained earlier which rupees should be collected, it was also needed to find the order in which they should be collected. The beginning is straight-forward since Link is just in front of the bushes and the hidden permanent rupee. RNG was manipulated such that 3 rupees always spawn. We notice that, like in my previous TAS, I was able to cut 3 bushes with a single slash and 2 of them spawned 3 rupees. Unfortunately, I was not able to find a good reachable RNG for which I wouldn't have to cut that extra bush (because cutting a bush creates a lag of 3 frames). I was neither able to reproduce such luck elsewhere that would cut 2 bushes. Overall, I manipulated the RNG better than in my previous TAS, which lead to faster movements and saved about 19 frames.
After the bushes are cut and the hidden blue rupee taken, I tried a new route I did not try on my previous TAS: instead of going for the blue rupee behind Mido's house first and then the blue rupee on the bridge, I was thinking of doing the opposite. My motive was that I thought that it could be possible to WESS after collecting the bridge rupee to clip inside the house and get the last permanent blue rupee from out of bounds. This house clip has been known for quite some years, but was only used to get to Lost Woods faster. The advantage of this new route is that we can get to this rupee faster and we also avoid a ledge grab.
To take the blue rupee on the bridge, there is a clip found many years ago that speedrunners have always been using, but never used in TAS because of the time it takes to take it. By jumpslashing at a specific frame, Link is popped on top of the bridge because he is close enough of the floor. After that, something interesting is done to grab the blue rupee optimally: there is a girl next to the blue rupee, consequently, if you press A to sidehop to the stone to WESS just after collecting the rupee, Link will instead talk to the girl because the rupee hitbox is located within the range where Link can talk. To counter this problem, I take advantage of how forward slashing works (holding the joystick to the front of Link and pressing Z and B). This type of slash makes Link go backward for 1 frame, and suddenly forward with high speed for a brief amount of time. The frame where Link goes backward is enough to grab the rupee, and the forward boost makes link go forward enough to be outside the range of the girl. This method is much faster than walking to the blue rupee, turning and walking to exit the range. That trick was also done in my previous TAS. After that, I keep the same angle and do a twisted sidehop in order to sidehop diagonally and jumpslash at the perfect frame to barely hit the stone and barely enter in the water to perform the WESS.
Clipping inside the house with WESS speed is more precise than with SuperSlide or HESS speed since it is a much lower speed. It requires not only a good angle, but also a good positioning that is gotten by changing angle at the correct moment and is more precise than it looks. Once we clip inside the house, getting to the rupee is tricky. The wall where we normally ledge grab extends inside the house as well and normally requires grabbing it. However, the house collision also extends behind this wall on the left side of the house (see the screenshots below).
This house collision is very helpful because it causes an unwanted effect which is, if you have sufficient speed, it is possible that the house collision pushes link out of bounds and completely ignores the wall collision. Sidehopping gives sufficient speed for this. Similarly to the bridge clip, since Link is close enough of the floor above him, he is popped up and we then collect the rupee without grabbing any ledge.
The last rupees are then collected and something interesting happened when I was doing the last sidehop to go the shop. Thanks to the very good positioning I had on the stones, I was able to land extremely close to the shop loading zone. So close that doing a vertical slash forward was the fastest way to enter in it and was 3 frames faster than anything else. Until this point (since the hidden blue rupee in the sign), about 131 frames have been saved compared to my previous TAS: 74 frames come from the new rupee collection order and about 57 come from avoiding to call Navi, because this new any% route does not need to go to first person during ACE anymore.
Shop -> Deku tree area:
After buying Deku nuts and the shield and exiting the shop, I do another WESS to get to Mido that I took from my previous TAS since it was already optimal. This WESS does not save a big amount of time, but it is still faster and very cool too. Unfortunately, we cannot skip Mido like in MrGrunz and Bloobiebla's TAS because later in the run, during the Walking While Talking glitch that will be performed later, Mido's collision will remain and there is no way to skip Mido while holding a rock.
Once we get past this guy, we start the heap manipulation to setup the memory. For that, we need to cross several times the transition between the forest area and the Deku tree area. A map of transitions and area can be found below:
However, we need to cross them in a special way: during some transitions, it is necessary to have Mido unloaded or loaded. When he needs to be loaded, the camera should be directed towards the forest, and directed towards the Deku tree otherwise. Moreover, during some transitions, it is also necessary to cross the transition while charging a spin attack, in order to cross the transition with this actor loaded. However, while making my previous TAS, I noticed that if Link does a forward slash, the actor spawns and link can walk for just one frame before starting to charge the sword. So when a transition should be crossed using a spin attack, I get Link close enough of the transition, do the forward slash, and during that frame of walking, cross the transition and immediately release B. By doing this, Link will still crouch and the memory set correctly, but Link will not spin attack, which saves time.
Once I reach the last transition from the forest area to the Deku tree area, I perform a glitch called Return A which will be useful later. It is done by pressing Z, R and C-up at the same frame and having a damage source hit the shield at the first possible frame. We can also note that from the shop until the last transition, 3 frames have been lost compared to my previous TAS although I kept the exact same inputs. This is likely due to emulation differences during the transition from Deku area to the Forest area that is longer on Bizhawk.
Deku babas -> Crawlspace:
The goal is now to get to the crawlspace for the next glitch that will come. In order to get there, the first idea is to go there normally by sidehopping. However, in TAS, we can take advantage of the damage source from the Deku baba to perform an A-Slide which gives link a speed of -18 to get to the platform near Mido faster (for reference, walking speed is 5.5 as child and sidehop speed is 8.5). The disadvantage of A-Slide is that the angle can be changed in a limited way without loosing speed, and requires loosing speed to change even further than a certain limit, +2 of speed every walking frame to be exact. Normally, we can also perform an HESS out of a Deku baba as well because of its special way to deal damage. The advantage of HESS is that we can change angle and thus reach the crawlspace extremely fast. However, the Return A glitch gets cancelled if Link takes damage at low speed (has the knockback animation), which is a necessary step to perform an HESS, and can therefore not be done.
Because of the limited angle change A-Slide offers, I can keep the maximum speed until the corner, and then I change my angle in a first time without loosing speed, and walk for one frame to trade 2 of speed for a better angle (so we now have a speed of -16) and we keep the speed thanks to Z-Sliding until the very edge of the platform. Once we reach the end of the platform, we have no choice to sidehop until our goal. It should be noted that we also cannot enter in the water as it also cancels the Return A glitch, so we cannot do a WESS neither to reach the crawlspace faster. We might notice that I used a slightly different path in this version of the TAS than in my previous one because I did not try this path before, but it ended up being tied.
Crawlspace -> Rocks:
After Link exits the crawlspace, we have little time to sidehop to the sign and read it while throwing a Deku nut. This glitch is known as Walking While Talking. Under normal circumstances, doing this glitch would stick the camera to the sign as seen in this video. Because of the camera position, the rocks next to Mido's house cannot load and so, cannot be picked up. Thankfully, the Return A glitch we did earlier enable the camera to continue following Link. Now, we target the sign in order to change Link's angle to backflip through the fence. You may notice that I paused before the backflip. That is because if I press A without having paused beforehand, Link will try to read the sign no matter the distance and will softlock the game. Once we get past the fence, the goal is to get to these rocks, however, for memory to be set up correctly, it necessary that the sign regenerate before these rocks load. A sign regenerates either by playing Zelda's lullaby, which we cannot do here, or either by getting far enough of it. Normally, going directly to the rocks would load them before the sign regenerates, which will result in ACE failing. However, when making my previous TAS, with some camera manipulation, I managed to somehow regenerate the sign before rocks load while still going straight into them, which saves a good amount of time. When we reach the rocks, I have to slash and pick up one rock in particular that is located exactly where we want in memory. Slashing a rock or falling from a ledge has the effect of cancelling the Return A glitch while keeping the Walking While Talking glitch, so the camera will behave like normal and try to stick to the sign. Because of this, the camera gets too far away of the rocks to remain loaded, however, I pressed A to pick up the rock just before they unload, so we are now carrying an unloaded rock. On this section, I saved 9 frames compared to my previous TAS because I somehow got a better sidehop angle which got Link closer of the rock, so it could be slashed earlier.
Rocks -> Deku tree area:
The next step to achieve ACE is to bring Link to the Deku tree area while holding the unloaded rock. For that we might think of several paths. It should be noted that Link can also jump, but not very high. In my previous TAS, I used a path that seemed to be the most optimal, however, I somehow forgot to consider the possibility of jumping to land on the wonder item platform near Mido which seems to be a faster path to the Deku tree area. Finally, I tried this possibility and it ended up being 56 frames quicker.
To navigate blindly through the forest, I used Link's position at some checkpoints and found the angle that had to be held to go straight to the checkpoint. The map below shows the path of both TAS including jumping parts and checkpoints I used.
Reaching credits:
Once Link reaches the Deku tree area transition, the camera snaps back towards Link. However, this does not completely cancel the Walking While Talking glitch because the effect of the Z button (i.e. targeting) is disabled. The next step consists of going back to the Forest area and dropping the rock at a certain angle range (explained earlier by Tharo). The range is pretty big and was obtained easily. In addition, 11 frames have been saved from the previous TAS on this small section because of better movement that turned the camera faster towards the wonder item actor. After that, a value that stores the last target angle has to be set to a single possible value which is 75E4 (or 30180 in decimal). For reference, there are 2^16, or 65536 angle values that Link can have. Since Z targeting no longer works, the only way to set the value is to charge a spin attack (without necessarily attacking). With precise movement prior to slashing the sword, I was able to manipulate the camera in a way that made this value reachable. The last step is now to look at the wonder item actor with an angle of 0804 (or 2052 in decimal). Looking at the wonder item with any other angle will result in a crash. After the spin, the wonder item is not yet looked at which lets time to set up the angle. The map below shows where it is located.
Unfortunately, there was no possible joystick angle that resulted in the desired Link angle directly. But fortunately, once the camera starts to turn towards the wonder item, there was still 3 visual frames (9 frames) before the wonder item runs the code. On the first frame the camera turned, I was able to find a joystick angle that worked just fine and thus, did not loose time. Once the wonder item is looked at, I use the controller 1 and 3 and followed what Tharo wrote for joystick values and buttons to press which lead to credits.
On a funny note, I threw a Deku nut just one frame before the wonder item code started to give the allusion of using Deku nuts to wrong warp to credits, similarly to how Sheik uses Deku nuts to disappear.

And that's how you save Hyrule in just 3 minutes !

Special thanks

First of all, big thanks to the analysers of this game for understanding the power of SRM that made this route possible and for finding an application of SRM for any%. These are, but not only limited to, Glitches0and0stuff, Fig, Tharo, MrCheeze, blini, natalyahasdied and probably even more.
Special thanks to MrCheeze for finding the initial setup for ACE used in my previous TAS.
Special thanks to Tharo for adapting MrCheeze's route for TAS to reach the credits faster.

Suggested screenshots

Frame 15759:
Frame 16698:
Frame 20301:
Feel free to propose more and vote for the best one !

Note: Screenshots were taken with the lowest resolution: 320x240 because it is the only one that syncs. Higher resolution should be provided if published.

All images used in this submission can be seen in their original size by following this link: https://imgur.com/a/7BxEaV6

Memory: Claiming for judgment
Memory: There are no signs of any mistakes.
The movie was entertaining, featuring some interesting movement but the main draw is obviously the game end glitch.
There were questions as to whether or not this should obsolete the current run. This run visits a fair amount of fewer areas than the current run and there’s some different glitches exploited.
Accepting to Moons as a new branch.
Memory: Adding geg branch label.
Spikestuff: Publishing.

Memory
She/Her
Site Admin, Skilled player (1515)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
Masterjun wrote:
Memory wrote:
...No I'm pretty sure it was rejected because it resulted in a broken loop. Sure that might be a result of jumping to a different point in credits, but that itself wasn't the reason.
Yeah I worded that badly. But it wasn't important to what I wanted to clear up anyway. I hope my point was clear that a jump to a different point in the credits can both be accepted or rejected, depending on the specific case.
Well given that you had to reply explaining what you actually meant, I'd say it wasn't clear the first time, but now it is.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Joined: 12/6/2008
Posts: 1193
This already shocked me when you didn't input a long-ass complicated file-name. Another shock was clipping up to the blue rupee after the house clip. Would not have thought that you can sidehop clip out of bounds there. Really nice to see this one. Yes vote! So what's next, Majoras Mask any%? :D PS: Might want to change "Video plugin: GlideN64" to "Video plugin: GLideN64" otherwise it's a bit more likely to be confused with the old Glide plugins than it is already (the dev really didn't pick a great name there).
Joined: 12/6/2008
Posts: 1193
ais523 wrote:
One interesting point: the realtime speedrunning community considers this a legitimate completion of the game, but what it's actually doing is warping to a point in the middle of the credits. Is there a flag or some other way of recording game completion that exists within the game? If so, does the run set it?.
Lemme quote the TASvideos rules for you here:
Players can use arbitrary code to quickly complete games, skipping large portions of them. Arbitrary code entered into a game which allows for fastest possible progression of the game is always allowed. Often this means jumping directly to the ending.
CasualPokePlayer wrote:
So looking at the RTA boards, the GCN version seems to be the version used in the top two times. From what I understand, the GCN version has a different setup than the N64 version, which is much faster than the N64 setup. So I'm wondering how this translate to a TAS. To be clear, from what I understand the GCN version is just the original game being ran on a (shitty) N64 emulator, and this ACE exploit breaks out of the sandbox due to an emulator bug within this N64 emulator and executes the credits (which is apparently just a pre-rendered video, so GCN code can access it). I'm not sure if this would actually be considered legitimate due to the fact that it's abusing an emulator bug (albeit this wouldn't be abusing anything in Dolphin and this can be done on an actual GCN), but perhaps that should be discussed for potential future cases.
The GC run is faster for RTA because before they had to go into the twins house to actually activate the credits. But homerfunky activated the credits on the spot with his controller- written- code and as he said it's faster than the GC-runs. Plus, there has been a ruling about this before. While yes, the GC version is basically just an OoT 1.3 ROM running in an emulator, in order to be accepted here on TASvideos, it would have to be run in Dolphin. So an emulator inside of an emulator. PS: As far as I understand, there is no sandbox breaking. There is just a new function in the rom, that usually triggers when the credits are reached, which tells the emulator to stop emulating and play a movie file instead. This function is easier to trigger than normal credits, since normal credits need a few criteria to be set. (but you can trigger normal credits on the GC-rom with glitches as well, they will just have graphical bugs, which is why Nintendo replaced them with the movie file).
Warp wrote:
(the one that's a b&w freeze frame with a "the end" text in the middle), that's enough.
Fun trivia: It's actually sepia tone. It displaying in black and white was a bug in many graphics plugins and emulators, including the official emulator on the GC-Disc, which is why Nintendo hacked a solution where the emulator will play a movie file instead of the actual credits. Thankfully that is fixed in GLideN64 and thus in this run.
Warp wrote:
At speedrun.com, perhaps partially not to throw away a decade of previous speedruns, partially to still keep a category that has a sense of "actually" completing the game (ie. delivering the final blow to Ganon) as fast as possible, there's a "defeat Ganon" category.
Pretty sure it had nothing to do with preserving old runs. Zelda runners just like their different categories. For years there was a "Ganonless" category, where you would warp directly to the credits using windy B or eyeballfrog timer, thus bypassing Ganon. Of course this category became obsolete when the new any% route was found and thus got replaced by "defeat Ganon". There is also now a "Defeat Majora" category for MM with almost no old runs in it.
homerfunky
He/Him
Active player (462)
Joined: 2/18/2015
Posts: 28
Location: France
Slowking wrote:
PS: Might want to change "Video plugin: GlideN64" to "Video plugin: GLideN64" otherwise it's a bit more likely to be confused with the old Glide plugins than it is already (the dev really didn't pick a great name there).
Fixed it, thanks.
CoolHandMike
He/Him
Editor, Experienced player, Reviewer (634)
Joined: 3/9/2019
Posts: 562
..and Link got to live happily ever after as an elf and never left the village. Yes vote.
discord: CoolHandMike#0352
evilas
They/Them
Joined: 7/31/2009
Posts: 68
Slowking wrote:
PS: As far as I understand, there is no sandbox breaking. There is just a new function in the rom, that usually triggers when the credits are reached, which tells the emulator to stop emulating and play a movie file instead. This function is easier to trigger than normal credits, since normal credits need a few criteria to be set. (but you can trigger normal credits on the GC-rom with glitches as well, they will just have graphical bugs, which is why Nintendo replaced them with the movie file).
The new 7:16 7:13 RTA route does have sandbox breaking (the old uhh I think it was 8:12? one didn't). Instead of running the function in the rom, they discovered a weird thing the GC emulator does that allows them to break out and play the movie file directly, which seems to be faster to implement. It just turns out that for TAS, that's slower than just straight-up writing the cutscene value with a bunch of instructions with two controllers, by about 5 seconds.
Over a decade on this site, holy shit
Memory
She/Her
Site Admin, Skilled player (1515)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
Which different glitches are used between this and the publication aside from the obvious (ace, wrong warp)?
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
homerfunky
He/Him
Active player (462)
Joined: 2/18/2015
Posts: 28
Location: France
Memory wrote:
Which different glitches are used between this and the publication aside from the obvious (ace, wrong warp)?
In this run there are glitches that are the same as the currently published movie such as Water Extended SuperSlide (WESS) or Wrong Warping (although it is done in a very different way here). Since this run uses ACE in Kokiri forest, some setup has to be done that exploit some glitches not used in the previous run. These are the Walk While Talking (WWT) glitch combined with the Return A glitch. Both of these glitch enable to perform the Stale Reference Manipulation (SRM) glitch, which is of course not used the previous run as well.
Post subject: It's About Fucking Time!
GamesFan2000
He/Him
Joined: 1/4/2019
Posts: 75
Location: Canada
It was inevitable that a TAS of the new any% route was in order. This is the textbook definition of what this site stands for. A run with absurd luck manipulation, abuse of the game's code in ways not intended, strategies that require multiple doctorates to even understand, and all of this performed at a level beyond human capabilities. All of this with an amazing submission that goes into extreme detail to explain the goings on. To simplify, homerfunky, I have no choice but to give you a yes vote, because this obliterates the requirements needed to make the Stars tier and might wind up being the TAS of 2020 when all is said and done.
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14776
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [4324] N64 The Legend of Zelda: Ocarina of Time "game end glitch" by homerfunky in 06:37.33
Joined: 12/6/2008
Posts: 1193
So this runs under "game end glitch" and doesn't obsolete current any%? Who made that nonsensical decision?
EZGames69
He/They
Expert player, Publisher, Reviewer (3942)
Joined: 5/29/2017
Posts: 2702
Location: Michigan
Ok first off, you can clearly see who judged the run by looking at the submission text at the bottom. Second, the judge gave reasons for why it doesn’t obsolete the other any% branch, so if you want to debate those “nonsensical” reasons please do so.
[14:15] <feos> WinDOES what DOSn't 12:33:44 PM <Mothrayas> "I got an oof with my game!" Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish [Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Joined: 12/6/2008
Posts: 1193
So Spikestuff made this decision and him alone? Okay, thanks I'm not that familiar with the system here. Why it's nonsensical? It's fastest completion. That is always any%. Everybody here in the thread talked about it as any% and the Zelda community classifies it as any%. If you want to preserve the old run "because it shows more areas" or something, rename that one to "defeat Ganon", like the Zelda community has done. Don't invent a new category that is faster than any%. Makes no sense.
Memory
She/Her
Site Admin, Skilled player (1515)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
I'm the judge for one and the judge team collectively made the decision. We don't follow the RTA community's "any%" naming/branching scheme and never have.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
EZGames69
He/They
Expert player, Publisher, Reviewer (3942)
Joined: 5/29/2017
Posts: 2702
Location: Michigan
No, Spikestuff is just the PUBLISHER, not the JUDGE, the judge is MEMORY.
[14:15] <feos> WinDOES what DOSn't 12:33:44 PM <Mothrayas> "I got an oof with my game!" Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish [Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Joined: 12/6/2008
Posts: 1193
Memory wrote:
I'm the judge for one and the judge team collectively made the decision. We don't follow the RTA community's "any%" naming/branching scheme and never have.
Sorry, I guess the system is confusing... and the judge doesn't make the descision alone. Good to know So the fastest run isn't the fastest run on this site? Why? Are there any communities but maybe a few fringe ones where fastest completion isn't fastest completion?
Memory
She/Her
Site Admin, Skilled player (1515)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
Oh the fastest completion flag is missing from this run. That was an oversight, not any sort of deliberate decision. EDIT: That has been fixed.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
fsvgm777
She/Her
Player, Senior Publisher (221)
Joined: 5/28/2009
Posts: 1180
Location: Luxembourg
And as a matter of fact, this has now been fixed.
Steam Community page - Cohost profile Oh, I'm just a concerned observer.
Joined: 12/6/2008
Posts: 1193
>
Memory wrote:
Oh the fastest completion flag is missing from this run. That was an oversight, not any sort of deliberate decision. EDIT: That has been fixed.
Thank you for fixing that. But I still think that is a weird decision to slap the fastest completion with extra labels. The fastest completion should always be any% (or how it is here, no label) and everything else should have qualifying labels why it is deliberatly slower than the fastest run. Not just because most communities handle it that way (although why you need to do it differently than everybody else I don't know). But also for the sake of consistency. If somebody wants to obsolete Grunz's and Bloob' run, how should they know what they are allowed to do? They clearly can't use the fastest route. That would make it "game end glitch". What can they actually do to obsolete that run in a nameless, not clearly defined category? Can you make clear rules what would obsolete Grunz's and Bloob's run and if so why not give it a label instead of giving one to the fastest run?
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Slowking wrote:
But I still think that is a weird decision to slap the fastest completion with extra labels. The fastest completion should always be any% (or how it is here, no label) and everything else should have qualifying labels why it is deliberatly slower than the fastest run. Not just because most communities handle it that way (although why you need to do it differently than everybody else I don't know). But also for the sake of consistency. If somebody wants to obsolete Grunz's and Bloob' run, how should they know what they are allowed to do? They clearly can't use the fastest route. That would make it "game end glitch". What can they actually do to obsolete that run in a nameless, not clearly defined category? Can you make clear rules what would obsolete Grunz's and Bloob's run and if so why not give it a label instead of giving one to the fastest run?
We tried your approach. It resulted in complete chaos. We had to resolve it. And the solution satisfied most people involved. Here's a full explanation of the current system.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 12/6/2008
Posts: 1193
How is that complete chaos? I don't see the problem other than that you made the category names way too specific, maybe. Also how does having something faster than any% (or no label in your case) solve any of that? Sorry I'm not trying to be rude but I really don't see the problem here and especially not how anything is solved. If you think the fastest run is too boring and you have to stick it in the vault (though not sure how that would be the case here, considering the votes), fine. But why slap some weird label on it and not the run that is slower? That makes everything extremely inconsistent. I noticed that you didn't answer my question. How would anybody know how to obsolete a run with no label that isn't the fastest? What are the rules to fit in the unnamed category? I think the old post of yours you linked tries to say something about that, but there doesn't seem to be anything substantial or I just don't understand.
Emulator Coder, Experienced player, Judge (593)
Joined: 2/26/2020
Posts: 691
Location: California
Slowking wrote:
any% (or no label in your case)
Branchless =/= Any%
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
See the actual thread where it all was discussed for more examples of problems. The goal of branch labels is not to list all the rules that one has to meet in order to obsolete the movie, that would be even crazier. The point of a given branch is usually described in the movie description and the submission text. If you're working on a TAS, you're meant to research the movie you're planning to obsolete, and after watching it at least once it is also clear in most cases what the rules are. If it's still not clear, you can ask the community. Also if two separate branches are similar enough, they can obsolete one another despite of slightly different goals.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Judge, Skilled player (1275)
Joined: 9/12/2016
Posts: 1645
Location: Italy
The main purpose of the site is to showcase entertaining tool-assisted gameplay. For that reason, we manage the publication branches in a way to feature diverse gameplay. At the same time, we avoid having redundant movie contents in published movies, by obsoleting movies that are too much similar to each other. With that said, we also give importance to competition, so of course we also manage obsoletions by following a logical reasoning. In this specific case, we differentiate between "game end glitch" and labelless by the presence of arbitrary code usage. In simple words: any future submission that beats the game as fast as possible we be competing for obsoleting the "game end glitch" publication, while instead submissions that beat the game without using glitches that are known to allow to skip more than half of the game (any sort of game end glitch) will be competing for obsoleting the labelless publication. Now, about the labelling system. This involves just the publication naming of movies, so it doesn't affect the judgement process, which I just explained above. In fact, we use labels in order to explain in a short and clear way what's the movie contents about. The label "game end glitch" explain clearly that in this movie the game is beaten by triggering the game ending routing via a glitch. It doesn't matter if it's done thorough a simple glitch or via a complex arbitrary code execution setup. What it matter is that more than half of the game has been skipped. Instead, for movies that don't skip more than half of the game through glitches, we leave the movie as labelless, as that denotes a sort of gameplay that it's closer to the most common way of playing the game. We never use "any%" because it just tells that you're beating the game as fast as possible, without indicating what the movie contents are about. What's worse, is that if at some point a new branch is creted due to a new glitch discovery, the branch previously known as "any%" would technically not be fastest completion anymore, leading to confusion. Reassuring: 1. We technically don't label branches. We label each published movie independently. 2. We manage obsoletion by looking at how much of the game is skipped, usually "beat the game as fast as possible" vs "beat the game while forgoing using a specific glitch or a set of glitches". If a movie uses a too much arbitrary or confusing ruleset, we simply reject it, as we want TASers to know exactly what they have to do for obsoleting a non-fastest completion movie. For the case of this game, it's very simple: just beat the game without using arbitrary code execution, as it's the currently known way of skipping more than half of the game. I hope this clears it a bit, but if you still have doubts, feel free to point them out.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Mitjitsu
He/Him
Banned User, Experienced player (531)
Joined: 4/24/2006
Posts: 2997
Any%, Any% with wrong warp and ACE have nearly always been separate categories. Any% WW usually involves beating the final boss, which is why it's considered a valid middle ground.