Any% ACE Route Explanation

Video reference: https://youtu.be/UA8xtN2QXCg

First in kokiri we collect a subset of permanent rupees to clear out certain sections of memory. We leave the shop and the lack of those rupees makes holes of free memory between blocks of occupied memory where other entities (actors) in the forest exist.

Then we head to the babas and go back and forth through the load plane that divides the village and baba rooms. We use camera manipulation to keep certain things loaded or not on each room transition, and also hold out the sword in a charged spin sometimes since that spawns an actor. All this loading and unloading of the rooms and its actors, combined with the arrangement of holes from rupee collection, makes one particular rock load in an exact memory address that we will need.

Then we do Return A (baba camera glitch) and Walking While Talking (crawlspace camera glitch) while picking up that special rock to get the camera to fly away which unloads the rock while we hold it. Now Link is holding a reference to free memory: a pointer to where the rock used to be. When Link holds stuff, he uses this pointer to copy his own position and rotation data to the thing he's holding on every frame. This causes it to appear to follow him. He continues to write this data to where he thinks the rock is, but it is being written to free memory now since the rock is gone.

We walk to the baba room and back to the village room. All the memory manipulation we did earlier was also planned to make an actor called wonderitem load at this moment near the same address where the rock we picked up was loaded previously.

The wonderitem is an invisible actor that controls the invisible blue rupee on the pond stepping stones near the shop. Link is still writing his position and rotation data to the memory where the rock used to be. Since the wonderitem is there now, he writes that data to some attributes of that instead. The data we planned for is Link's angle. We make sure we face an exact direction first, then drop the "rock" to lock in the angle we want and end the carrying state. That value overwrites part of the wonderitem which corrupts a branch instruction to make it look elsewhere to execute the code in that branch.

The value we choose makes the wonderitem run code at an address in Link's actor instance, in a place where 4 bytes of continuous data are completely controllable by the player. Two of the bytes are the last angle the player locked the camera at, and the other two are the player's current angle. This isn't code, but since we control this exact 4 byte value, we can make it mimic code.

We do more angle setups and then a spin attack to set the locked camera angle bytes to a particular value (can't just use Z target since we are still in walking while talking mode this whole time). Then we do another setup to get link himself to be facing a particular angle (this is the part just before we do the last c-up). Now it's time to get the wonderitem on screen and get it to actually run its corrupted branch.

We let the camera turn to the wonderitem and the moment it is active, the angle from the "rock" drop makes it look at link's instance. The spin attack + current angle values make it jump execution to the filename. The filename is another 4 byte controllable bit of data that we've made to mimic code. This code runs and loads a pointer to the "next cutscene" value into a register. The filename then jumps execution to part of a function inside the gossip stone in kokiri. This function was specifically chosen because it already increments the value stored at the pointer in the same register we just used. So the gossip stone is adding 1 to the next cutscene value.

This whole code path runs every frame, so the next cutscene value goes up by 1 on every frame that the wonderitem is active on screen. Since link's angle is part of the code path, all this must be done while standing perfectly still or else the game would crash. We let the wonderitem remain active for exactly 9 frames, using c-up to get it off camera on the proper frame (can't pause buffer this since pausing doesn't work when the next cutscene value exists).

Then we just enter the house and the next cutscene value of 9 is applied to the house of twins entrance. This causes a normal wrong warp, and you end up in the cutscene map with cutscene 9  applied, which is the credits scene shown.