User Files from FatRatKnight

This is a test run. Route information:

Basically, I maximized Ella's distance as far as it will go. Out of all the Par 4 holes throughout the entire game, only a single one during Links was possible to get in one stroke, though another in Mushroom Tourney was close. As for whether the added distance of Super POW is worth the 2 minutes, that's hard to say. This is a test run, after all.

I'm given the impression Neil can reach a fair number more Par 4 holes in one fewer shot. However, there are times in later holes where I felt the low Height was needed for any sort of reasonable speed, and it's likely that Neil's Height will destroy our speediness, whether it saves a bunch a strokes or not.

Another nine holes. A Height of -2 instead of +3 is definitely a difference. A lower level means we'd have more Height and less Drive.

Give Up on Marion Hole 4 (+12) and two of the more awkward Par 4 holes (+10 each) for a score of -7 gives us less levels, which affects us for the rest of the run. For reference, the Marion champ Joe gets +3. Is a tie score enough to reach the last tournament and see the credits anyway? Hard to say if the initial savings we get from that will pay out more than the losses later. A run that gets the best possible will give us more information in case someone else wants to Give Up some of these holes later.

While browsing through Mario Golf's Glossary, I did spot this:

Worm Burner
A shot with an extremely low
trajectory that skims or appears
to skim the ground.

Curious how well that describes some of these shots.

Poor Ella. Didn't notice the glue on the 1W, so she swung that the whole tournament.

The strategy mainly revolves around doing anything possible keeping shots low. The choice of chip-in or flag shot depends on the situation. Flag shots are nice, since the ball can be flying at ridiculous speeds and still come to a complete standstill the next frame, but it's fully possible said speed would have the ball exist before the pin one frame and exist in the space after the pin on the next frame.

A hole-in-one will never call a chip-in message, but will call the flag shot message if you do that, so for Par 3, I always opt to avoid the flag. On the second stroke, either way will call a time-wasting message, so I pick one or the other on the situation.

Some manipulation on weather and pin position was done, and I cleared three of the four Par 5 holes in 2 strokes. 701 EXP, enough to hit level 12. Hard to say if Give Up is faster after after whatever difference in levels. Took a few moments to art up the first few shots, so look at that ball picture on the bottom right corner if you're bored.

For adjusting shots, TAStudio, Follow Cursor OFF, Auto-Restore Last Position ON. I did find that feature convenient.

EDIT: I called it 11 minutes before. Perhaps 12 minutes is better. I'll let someone else decide the nuance of the exact timings.

VBA 23.6, also not for BizHawk. If it can be converted, go for it!

I recall getting through Marion with Ella and POW clubs. View it if you like.

VBA 23.6, I think. Sorry, not for BizHawk, unless someone's got a good conversion tool and can have it sync fine.

I don't remember how far I got with Neil. Not very far, I recall.

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.

Additions include:

Hopefully the fancy numbers and boxes look pretty enough. The orange hexadecimal values by the cyan decimal timers is the RNG value used for determining what spawns. For fairy encounters, it depends on what terrain you're walking over (D0 F0 E0 F0 F8 FF), and it needs to be that value or higher for a fairy to appear. Theoretically.

The directions of existing spawns are color coded: Green means they will unquestioningly go that direction, while orange means they'll only go that direction if not aligned vertically or horizontally with Link.

Still tweaking my prediction algorithms. Currently, the piece of code that predicts the next encounter appearance is inefficient, as it will run through hundreds of RNG calculations every frame. Or, for that matter, while you're sitting there paused, as gui.register runs lua code several times per second when paused. I plan to inject timestamps and a bit of memory to avoid recalculating what we already knew a frame ago.

However, the active display is encouraging. I haven't detected further errors, so here's my current prediction script.

Oh, and one more thing. The script is set up to detect moments the RNG is reset. It'll print, to the Output Console, the RNG value and global timer every time it happens, as these are probably our sync points. Probably good information to know, as if these are identical to some previous trial, then you are almost certainly going to have identical luck. If these are the only constraints to the effects of RNG, then there's 2688 possibilities.

Still a prototype. I'm using integer versions.

Added a snippet of code that attempts to identify world map locations where an exit will drop you off at. One would hope this lets you know where you're teleporting to. Numbers in the bottom right may be of assistance. Additionally, for room exits, I invert the colors if it's 0x3F, and instead show a number from 0 to 3. That's the selector for our world map thing.

Then again, I don't have much experience with these glitches about somehow making use of alternative exits, so I haven't checked how viable the numbers I'm showing are. Also, there is a *known* failure with my script when we're talking about the Maze, as for some reason, the standard 0x3F I expect to see isn't showing up, yet it exits to the overworld. I have things to look at.

Work-in-progress script. I'm playing around with various designs and thoughts as I run the debugger to get information.

Included is something that tracks Link's position, gives two numbers for enemies and one number for enemy projectiles (Link's sword beams and fire shots aren't included). The numbers are damage to Link if he's hit, and how many strikes it will take to defeat an enemy at current attack power.

I also have HUD stuff at the top of the screen. Still working things out and making them pretty enough. I haven't even removed the TASEditor piece in the script, so pressing controller buttons will toggle the TASEditor stuff if that's running.

I've experimented with some registerexec and registerwrite code. One piece is enabled as of this WIP.

Finally, I have my script respond to when you press space by dumping out a list of exits and apparently related numbers. I'm not particularly inclined to disable that bit of code.

This script just spits out what room you're in, and the four destinations of that room. Look near the experience.

Numbers are in hexadecimal. Don't like them? Edit the script and change the several DrawNumx inside the bottom function into DrawNum.

Where is my sanity?

Here's v3, which is exactly as fast as v2, but does random stuff on a different screen. I'm sure the population don't mind me playing around with the taxes. After all, there's no military unrest, or something.

I don't know how I filled up the long delay waiting for the attack ship to arrive, but I found a way. This might be mildly entertaining. Maybe. At least 10 times that of v2, anyway. Keep in mind that I probably moved the exponent from -4 to -3.

If I make a v4, perhaps I should question my submitting without first consulting the forums.

Test run. Did not attempt to maximize frame savings. This is what it looks like when easy is done. Shorter wait, but alas, where's the splashy ending?

By the way, this was how I discovered that you can win without needing something intact on the attacker's side.

Well, new ending strategy: Crash tank into building. Deals 5 damage.

I'm trying to figure out how I managed to miss this. Maybe I just wasn't inclined enough.

Added frame markers.

Largely the same as the previous version, otherwise.

An off-by-one error fixed. I hope.

Also, I experimented with an item seeker code. It will indicate how long you'll have to wait for some item, with the frame count shown as the number, and the color that indicates the item. There is one more number, with an inverted white, that indicates how "out of sync" the two timers are.

I've also recolored the items. Red(s) and orange(L) are the energy drops. Blue(s) and cyan(L) are the weapon drops. White is the extra life.

It is difficult to work with an RNG predictor where there are three factors in its output: Frames passed, lag frames, and whether an RNG call was made recently. The more fancy I try to make it, the more I realize there are factors out of control I can't readily predict.

I can probably add controls to the item seeker so that you can specify a specific "out of syncness" of the timers, but that generally assumes you can get things to lag appropriately. I can try a lag tracker, a good pair up with TAS Editor, but now we assume things will lag exactly how they do when you change the timing of your shots. Then, of course, there are other factors that may use the RNG, and a call will adjust the RNG output for the next 16 frames.

I'm questioning the validity of that "second column" that I threw in there in v1, since it seems a different RNG call is made that adjusts it differently when an enemy needs to think or something. It's still here in v2, though.

But I like the canvas. Well, aside from the fact it acts slow on my laptop, anyway. This display runs rather smoothly here on FCEUX rather than the floating BizHawk canvas.

I still have not identified which color goes to what item, but I can assure you that the different colors go to different items. If I take the time to look, I'll update this description. I've spent said time to transplant the script to FCEUX without nasty hiccups.

I made a quick change and am uploading it right away. Quick tests show its working well enough.