User Files from FatRatKnight

Thanks Memory for the encode: https://youtu.be/h79WqnOBUC8

Ah. Still TASing around on F-Zero stuff. Here's a high optimization run. Well, except for the last turns, anyway.

Side Attacks are really fast on their initial portion of the attack. They cancel on the rail. Another can be initiated with zero frame cost. Fun.

Ported from v7 of the FZMV script.

Geez, so many of the stat offsets and mechanics are the same from Maximum Velocity that I had no trouble porting the script. There's a few things that didn't quite port over yet (dormant record mode when not in a race), but it probably just needs tracking down the relevant addresses. I'm not sure if the player index is always 0, the script assumes such for now.

Here's the bonus. Do enjoy it.

Changes to the script are mostly just internal. Consolidating some functions so the ones that are functionally identical between rotating and static have only one copy of the function, rather than two. Stuff is rearranged, and now things are changed for better maintenance. The visual output of this change should be non-existent.

However, that wasn't the only change. I did other small changes, such as properly detecting whether a machine exists, and whether a race has started. Recording mode is dormant if not racing, instead of constantly trying to write to its tracker, and when dormant, is indicated by less saturation in the red REC. Small, but I did refine a false positive out of my detection.

Uploading largely because I'd like an online backup, but having it publicly available wouldn't hurt. Haven't had any other ideas that immediately come to mind as useful to implement now.

Another small change. Looked at machine stats until I could identify the hysteresis flag. Speed is highlighted in red when you can't accelerate due to hysteresis (but releasing the accelerator will add coasting friction on top of maintenance friction).

Knowing speed limit would require knowing what machine you selected. Understandably, I felt finding the related flag would be less work than having the script find what you picked out.

Increased the number of decimal values displayed. Not really any significant changes otherwise. As much as my habits are for me, I should realize I'm not everyone.

Also, I experienced some pretty fast crashes with BizHawk 2.0, on three different tries, with this script up. Curious.

f16175 *** STAGE 7 ***
f17129 Segment 0: 954
f17945 Segment 1: 816
f18518 Segment 2: 573
f18675 Segment 3: 157
f18744 Segment 4: 69
f18939 Segment 5: 195
f19303 Segment 6: 364
f19926 Segment 7: 623
f20116 Segment 8: 190
f20471 Segment 9: 355
f20825 Segment10: 354
f22237 Segment11:1412
=== END OF STAGE 7 (Frames: 6062) === (prev: 6104)

Redid a part in Stage 7, then did a lazy-sync to have later stages keep working. The change in strategy here is to trigger the extended invincibility before the miniboss, as an obsolete plan had us do so after the miniboss. The obsolete plan was only good when we still fired the giant laser at the miniboss, which terminates the extended invincibility, but since we're skipping the miniboss now, we can change plans and find better spikes before the miniboss to gain invincibility.

The ceilings after the miniboss room refused to cooperate. Might have lost a dozen or so frames on less optimal ceiling clips. Things just don't go smooth this time around. Anyone who wish to bash their head on this problem are free to try.

8 frames are thrown away in stage select for item drop sync of later stages (the lazy-sync I mentioned earlier), just so I can attach them at the end with zero effort. Under no circumstance is throwing away frames in stage select an advantage for a final run, so this is just temporary for keeping sync. We may want to keep the later stages in case we get further improvements and end up syncing the 32-frame rule for item drops.

Original plan had us get invincible after the miniboss. This was because said plan originally attacked miniboss with giant laser, which has the side-effect of removing invincibility. We don't apply giant laser on miniboss anymore (thanks to skip), therefore doing the invincibility trick before it means we won't promptly lose it on our way through the miniboss room. So, while waiting for skip to become possible, set up invincibility.

These ceilings on the upward segment are giving me a lot of trouble, which is why I haven't uploaded a completed Stage 7.

I just can't keep away from TASing this lap, can I? 23"65, down from 24"21, a good 0"56 removed. Mid-23s as predicted by our RTA speedrunners. Take my advice, taking advice from people who knows things can often show good results. Still not sure if I'm in a good position for the curve ahead, but at least I made sure not to sacrifice speed after the second speed arrow.

I was having trouble slowing down, but then I realized the perfect slowdown. Those things that slow you down on either side simply affect your position, and have no effect on your momentum or velocity. Therefore, I find these things to be a nice boon in this case. Could I have taken a bump earlier? Possibly, but this one extra bump has already shown nice results. I've also ended up taking other paths on the end of this lap, curious how many frames are left to find here. Wonder how much more this bump can push us.

Was interesting to see my script indicating I was past the 20 frame range I set of where my ghost was.

A bunch of changes here. The script will record to a file in text format. This is because the way BizHawk is set up, it is impossible to maintain lua variables, such as the position history, when merely switching from one movie to another. A persistent file might be useful for other reasons, so it's probably good I made one to begin with. Note the list of frames in file isn't necessarily sorted in order.

Also, I'm now displaying ghost trails. In the past and the future. The ghost Xes will also show everyone, not just the player, and will be darkened if it is identical to the immediate current position. This is probably a better way to indicate changes in CPU position than the confusing list I was displaying before. As for the trails, they look pretty, though sometimes I ended up confused on whose trail went to what.

I hope this is a fun script to use. Oh, and useful, of course.

Once again, I'm doing something right. Opener lap done in 24"21. Unassisted WR opener is 24"39.

Though, whether I drove nicely for the next curve ahead is another question. If not, it just means we shouldn't expect it to remain 24"21. There may still be a few mistakes in there, though. I just TASed a part and don't really want that to go to waste.

Starting bumps got me to 450-ish, and the one just before the jump got to 593. I've seen 600, but wasn't able to replicate that in this run. The other times the CPU appeared all did not look convenient to take more bumps, and TASing this still didn't give me ideas on how to script up predictions.

f43869 *** STAGE 6 ***
f44804 Segment 0:935
f45703 Segment 1:899
f45798 Segment 2: 95
f45997 Segment 3:199

Don't care what the numbers suggest versus my try #2, I started the dash after miniboss later. Also, extra lag, so no idea about the frame rule effects.

A route where I move to the right sooner. Sadly, a bullet clipped my toes by precisely one pixel. This is enough to eradicate an entire HP off the barrier, and the miniboss strat suffers badly from it. One pixel can do that.

f43869 *** STAGE 6 ***
f44804 Segment 0:935 (T3:933)
f45707 Segment 1:903 (T4:870)
f45801 Segment 2: 94 (T7: 90 . T4:154)
f46001 Segment 3:200 (T5:219 . T4:220)


My second attempt at getting to the miniboss in this stage. I still don't feel fully satisfied, even walking to the miniboss with this much barrier. Then again, I have a decent lead over the DTC teams.

The Segments 0->1 transition is better, at least. Did stuff to preserve barrier lossless, so that's nice as well.

f43869 *** STAGE 6 ***
f44808 Segment 0:939 (T3:933)
f45710 Segment 1:902 (T4:870)
f45805 Segment 2: 95 (T7: 90 . T4:154)
f46016 Segment 3:211 (T5:219 . T4:220)

To Segment 4: 2147 . Fastest team: 2176 (T3)

I choose Stage 6 next. My route is unique from any team. After this will be 5, 2, then the end.

Copying in Team 3 was not simple, as this route has a weapon in between flame and bubble. Transition of Segment 0->1 is awkward, as the following ceiling clip apparently needs a low enough screen position. Also changed things with Team 4's ascent to go to the right side just before miniboss. I want it to work somehow. Finally, it would really help if I can preserve just one barrier HP for miniboss.

I'm not convinced what I did is fastest. I hate the 0->1 transition, for one thing. I don't feel right about how I moved to the right side during Segment 1, for another. Having 1 barrier HP for miniboss is extremely desired, lastly.

f37087 *** STAGE 3 ***
f37603 Segment 0: 516 (T3: 519)
f38278 Segment 1: 675 (T4: 718)
f39007 Segment 2: 729 (T7: 732)
f39114 Segment 3: 107 (T7: 106 . T4:_ 89)
f39175 Segment 4:_ 61 (T7:_ 61)
f39311 Segment 5: 136 (!!: 136)
f39644 Segment 6: 333 (!!: 333)
f40649 Segment 7:1005 (T7:1004)
f40767 Segment 8: 118 (T4: 124)
f40889 Segment 9: 122 (T2:_ 99 . T4: 124)
f41123 Segment10: 234 (!!: 234)
f42799 Segment11:1676 (T3:1672)
=== END OF STAGE 3 (Frames: 5712) === (T4:5939)

Nifty. Got to the end of the stage at last. Manipulating item drops because Flame Charge is hungry for ammo. I think I got the items cost-free, as there were a few points I had to delay for Flame Charge anyway.

Copied Team 3 after miniboss. Took a look at how Team 7 started Segment 7 and disagreed with it. They decided to use an enemy there to try that Charge Glitch, which is why their Segment 6 took so long compared to other teams. According to my Segment Counter, I'm one frame slow in this segment, but I haven't carefully studied their route to be entirely certain.

Ascending Segment 8 took an inspiration from Team 3, going all the way left before going up the ladder. This is because the wall is thicker at the ladder, and I can't go all the way left otherwise. From there, I can walljump at a lower height past the ladder. I use Fragile Barrier to get past an enemy, instead of shooting it with fire. This is so I can charge my Flame Charge sooner.

Segment 9 is reported rather slow, probably because we start essentially on the far left rather than whatever place on the right the other teams were. Haven't looked at them, but the frame counts of Segment 10 indicates they paid a rather bad trade for that.

f37087 *** STAGE 3 ***
f37603 Segment 0:516 (T3:519)
f38278 Segment 1:675 (T4:718)
f39007 Segment 2:729 (T7:732)
f39126 Segment 3:107 (T7:106 . T4: 89)
f39187 Segment 4: 61 (T7: 61)


12 frames better than my free form. I practically copied in Team 7's segment in, with only a minor change to make the breakable wall look less ugly. I'm now a cute 2 frames ahead of Team 7 comparing Segments 2 & 3. It's probably because of the camera, if nothing else.

Team 4 didn't need to jump and snipe an enemy, which is why their Segment 3 is so short. I have no plans on matching that frame count with the enemy snipe.

Been distracted on F-Zero stuff for a bit, why I haven't worked on this a bit for days.

This script now records positions and whether things exist. After playing parts of the run, rewind and do different things. The script will state whether things existed or not, and if they did, whether they changed position from the last time it got to that frame. The script will dumbly record into its memory every time you go back over a part, so if you just rerun the new input again, it will claim everything is present or absent exactly as they were.

The purpose, mainly, is so we can more easily tell if the CPU did something different when doing random crud.

Oh, and I changed the order of the player ghost functions. It'll record your new position after displaying what it has. Previously, it recorded, then displayed the recording, which will always coincide with the player's immediate position. At least this way, if you leave the ghost recorder on, that you can see the immediate local changes you're making, though it really isn't smart. Thanks to core resets killing lua variables, and one being triggered every time you play a new movie, cross-movie checks with this type of ghost stuff are impossible without file IO.

I do need a better frame detection (it doesn't like start of races). I also need a better way to detect whether a thing exists.

SRAM uses Type 5 controls. I make no claim that this is the best opener, I'm fooling around trying to figure things out.

It jumps to 408 km/h when the clock is visibly 0'03"43, and to 446 at 0'03"45 on the next frame. I'm not entirely certain what's going on. It looks like a double hit to me, although Power only drops once.

The Wind Walker CPU in Training hasn't had any obvious speed boost from me hitting the wall or anything, so I fooled around and tried to snake to reduce my true speed forward after a rocket start, but without hitting the wall. If things are different in Grand Prix, I will take a look there.

The list of five numbers in my current script show, after messing about, that the Wind Walker CPU reaches the same lap segment after the same number of frames, after a few random actions on my part.

This "good hit" was apparently frame perfect to get. One too many or one too few frames of my leftward strafing did not get anywhere close to the 446. I may want to study the collision radius for a bit and see what I come up with. Is this the effect we want, or am I looking somewhere else?

You know, since I have a nifty radar display, I figured it wouldn't hurt to record player positions. Also, added one more number right below the durability and lap progress numbers. All the fanciness of height and vertical velocity, and it really boils down to one number: How much longer until you land. Mind, I only report the longest possible time left, when holding down the whole time.

As I haven't figured out code for detecting user input while paused (I will refuse a solution requiring an active loop), you need to hold the key and advance a frame to toggle record mode. For now, I have it keyed to M, but of course change it as needed.

Well, I pick different numbers for that list of five numbers on the right side of the radars. Now it specifies that lap segment thing, so you can tell if something suddenly appeared ahead. It also changes the colors used for the background of those numbers in case it's a mine.

Other thoughts include calculating jump time, but that's for later.

Complicating my script some. I hope my organization works out.

Left side, static display:

Right side, rotating display:

Didn't want to work out rotating grid lines. At least, not yet. I've aligned the grid lines with what I suspect to be how the game tiles things.

And it has a few other things, I suppose. Some stats on the right are seen, some basic thing with machine data or something.

Facing and momentum compass on the lower left.
Rival radar on the lower right.
Various RAM Watch alternatives and minor calculations in various places on the screen.

This is a start. Not sure how helpful the visuals are, but the visuals should hopefully give a decent idea. I use hexadecimal in a lot of places, considering how many important things are apparently nicely divisible by 256, but if those aren't liked, look through the various string.format scattered about and change that X to a d. Or ask me to do that for you and re-upload, I suppose.

I have a soft spot for hexadecimal. Easier for me to remember 0000, 4000, 8000, and C000 for the compass points rather than 0, 16384, 32768, and 49152. So clean.

Anyway, hopefully this script is a nice enough starting point. Some things from an older VBA script was used.

Before I forget, the rival radar has a minor glitch. Namely, I restrict the viewing area to a square, and then rotate it. Whoops, the rotation spins my square around. I really should rotate, then trim to within the square...

f37087 *** STAGE 3 ***
f37603 Segment 0:516 (T3:519)
f38278 Segment 1:675 (T4:718)
f39007 Segment 2:729 (T7:732)
f39126 Segment 3:119 (T7:106 . T4: 89)
f39187 Segment 4: 61 (T7: 61)

That first flame charge Team 3 did wasn't ideal, so I dashed straight off rather than jump and made sure I landed on that platform ahead properly. Segment 0 was otherwise copied straight over. Ran free form on the remaining segments. Segment 1 is pretty fast when absorbing 6 hits thanks to barrier.

My free form had results in Segment 2, apparently. However, my Segment 3 is worse than any team out there. I clearly need to check on a few things I might need to do differently.

I'm not certain Stage 3 is the ideal next spot, but I did get here losing zero frames to animation frame rule. Team 3 got here after exiting Stage 2, and I needed to do adjustments to sync their Segment 0, as they lost 3 frames to this very frame rule (my SegmentCounter script does not count frame-ruled starts against any team, so these 3 frames are not reported; the 3 difference it is reporting was from that first flame charge).

f30081 *** STAGE 4 ***
f30313 Segment 0: 232
f32042 Segment 1:1729 (T4:1741)
f32287 Segment 2: 245 (T4: 245)
f32436 Segment 3: 149 (T3: 155 . T4:152)
f32625 Segment 4: 189 (T3: 190)
f32948 Segment 5: 323 (T4: 325)
f33894 Segment 6: 946 (T5: 949 . T4: 958)
f33990 Segment 7:_ 96 (T7:_ 87 . T4:_ 96)
f34129 Segment 8: 139 (T3: 128 . T4: 140)
f34375 Segment 9: 246 (T4: 246)
f35880 Segment10:1505
=== END OF STAGE 4 (Frames: 5799) === (T4: 5845)

At last, this stage is decidedly improved! Not sure about that moment with Team 7 and Segment 7, though. And Team 3 with Segment 8. But we have a Stage 4 clear that's 46 frames faster than Team 4.

Anyway, here it is.

Run out of flame ammo, fall, die. I don't think that was part of the plan.

So I was looking at how Team 5 did things, since they are several frames ahead of the leading teams in this latest segment I die in. Yes, it does appear that throwing Flame Charges in an area that looks ideal for just straight dashing is indeed faster by a few frames. Probably because I'd otherwise have to wait until I land before I dash, and also that a ground dash requires a few frames of us holding still and lasts 40 frames, while there's plenty of time here to get a Flame Charge up and ready.

Item drops went up in importance here. I suppose someone should start searching for convenient items.

f30081 *** STAGE 4 ***
f30313 Segment 0: 232
f32042 Segment 1:1729
f32287 Segment 2: 245
f32436 Segment 3: 149
f32625 Segment 4: 189

Team 4: Miniboss strat
Team 3: Landed on save platform
Team 4: Ladder headbonk
Team 3: Avoid damage during Ghost fall
Team 4: Leftward position after Ghost Fall

Interweaving the best of teams one right after another. A frame was spent before the ladder due to even-odd parity of X position, as 208 got me hit and couldn't go further right, but 209 was safe, and I get there from 207. While falling, if I'm on even numbers, I can't switch to odd numbers as movement goes in blocks of 2.

Lag on the flame charge at the end of this Ghost Fall. Naturally, I'm not liking this lag. Somehow one frame shorter than Team 3 on the Ghost Fall segment, probably due to the fall cycle. While falling, the player's air time counter oscillates between 34 to 42. One of these frames has 0 Y speed. Probably the cycle was different from Team 3 from the ladder headbonk.

Finding it tough to find time, largely due to life stuff.