User Files from FatRatKnight

It's a script I was using when TASing on VBA, already converted for BizHawk.

Oh, and sorry about all those hexadecimal numbers. It's actually my preference, and if you refuse to get used to it, I'll upload a new script that reads things in decimal instead.

It's a fairly basic script. But it had what I wanted. Reading distance to pin should help in knowing just how close you got.

Restrictions:

Well. Here it is. 48 tracks of racing madness. This definitely feels like the appropriate stopping point, as 49 is just like 25. Every loop past the second is exactly as tough as the second loop, so 48 is our natural stopping point.

Besides that, dealing with CPU players who stay routinely at 127 MPH does make for a challenge when you max out at 103. TAS precision does not appear to be enough to go weaponless entirely if you want 1st place. Well, in my all items restriction, anyway.

For old time's sake, I still insist I'm not completing this run, despite already having done so. Clearly I'm wrong, seeing as I have a complete run now, but, well... Now I'm out of excuses. Look at what your reading this paragraph has done now!

Should have one trailing blank frame. Some thought in mind about FCEUX duplicating the movie's last frame once when the movie finishes or something. Didn't want to duplicate an extra B button press.

Triggered R_2=31. It only saves one "frame rule" over the R_2=72 movie if we cast Fairy spell. This time I took the effort to create a movie that naturally manipulates R_2=31 in.

If it took fewer frames to manipulate in R_2=31, then yes, this would be faster even with the menu loss later. There's room to manipulate away the 21-frame chunk, but not with the R_2 we had coming into the normal encounter.

RNG is complicated business to explain, really.

RAM hacked to get gTimer/RNG pair.

So Fairy spell can traverse this segment 4 frames faster than non-fairy Link. I checked for other RNG values this early, but nothing came up.

This is what happens if R_2=31 is done. If we can traverse the cave quickly enough, we will get that fairy, but I only succeed by, in this movie, casting Fairy. Assuming that magic I just spent isn't used for anything else, we still need to re-open the menu later. Best done if R_2=72 isn't behaving in some improvement sometime in the future.

Payment due: Two dreams.

We're not going to get this any faster. At least, not without something more crazy. I now feel this is optimal, at least by the methods I am using.

According to me, the Valley of Death fairies by this attempt reaches the last cave 287 frames faster than this movie produced by the Reflect Trek fairy manipulation. We just need Arc to copy in the last cave and Great Palace input and tweak things to fit with the RNG.

Uses R_2=71. Some small time lost to manipulation, but this looks pretty nice.

However, I'm not convinced I took the normal encounter optimally. We can delay the first fairy encounter by as much as 11 frames, so we have 12 possible gTimer starts on that normal encounter. We do this to do RNG stuff if necessary.

Payment due: One dream.

This ain't hacked RAM anymore. I've actually trimmed off several frames before the last traversed bridge (removing intentional delays), scattered the remaining delays across a few transitions, and granted a wish.

There are extra delays, including sitting tight for 20 frames positioning a spawn and a little more walking in the Valley of Death. For a fairy, I'm sure this is a reasonable trade-off. Now, I haven't checked how mean the follow-up spawns are going to be for the trap that follows, but look at that fairy!

Save state anchored. RAM was hacked to provide the initial RNG/gTimer pair, but this indicates it's worth continuing my search.

gTimer=18 R_2=15 ; gTimer could also be 20, so basically see if I can't trip over this using the prior screen transitions.

Picked a different RNG than the concept for the first fairy. It's faster.

For the second fairy, I delay exactly 5 frames across various screen transitions in order to spawn the fairy and have it fly mostly where needed. One frame later, and the 21-frame rule would kick in.

Out to the second fairy, I haven't actually ran the rest of the trek to know if the encounters behave on the way to the palace. Still, there's not a lot of possibilities to look at without moving past that frame rule.

The concept is reality.

I've taken the third entry of my table put out by my script found in this post. Which is 0 frame delay at the tunnel and 22 frames at the child cave. Also, I seem to defy my own expectations by spawning the fairy in slot 5, where I only output paths for a fairy in slots 0, 1, or 2 in that table.

Seriously, I just can't predict what slot that thing will appear in, and it is possible to pick a different lossless path using the same RNG/gTimer pair that spawns the fairy in a different slot. I also spent more time waiting than expected, requiring more path than I reveal from my script.

Regardless, this proof of concept by itself should save over 100 frames. Spawning a new fairy on our way out of town shouldn't be an issue with all the screen transitions. I will be looking into how feasible it is to spawn two fairies in a row and have them fly straight to our next trap (immediate 3x east travel for our west fairy). At least for the second fairy, the east fairy will always spawn in slot 7, and the west fairy in slot 5, as nothing else will be taking up our slots, so prediction will be more stable.