User Files from FatRatKnight

f37033 *** STAGE 5 ***
f37768 Segment 0: 735 (T2: 736 ; T4:761)
f38248 Segment 1: 480 (**: 477)
f38557 Segment 2: 309 (T4: 309)
f38680 Segment 3: 123 (T3:_ 91)
f38757 Segment 4:_ 77 (T3: 241)
f38872 Segment 5: 115 (11: 116)
f39331 Segment 6: 459 (T3: 451)
f40069 Segment 7: 738 (T2: 735)
f40347 Segment 8: 278 (T4: 279)
f40464 Segment 9: 117 (T4: 129)
f40702 Segment10: 238 (T3: 234)
f42109 Segment11:1407 (T4:1408)
=== END OF STAGE 5 (Frames: 5076) === (T3:5310)

13 frames better than my previous.

Removed a mistake in Segment 2 where I forget to hold Right on the frame I release my Flame Charge.

It may seem like not all that much. I mean, camera scrolls 1 pixel/frame after touching the door. So how can 81 be so much worse than 80? I'll tell you. ScrX 81 vs. ScrX 80 is greater than the difference of 2 lag and 2 normal frames that alternative route gives us. The boss spawns much later sitting on that one pixel. This pushes us back behind the dialog frame rule. We lose the frame rule. We lose all gains and then some from one pixel. Vicious.

Or maybe I do take the route. I obviously have a bad memory on what I did. Took me a while to realize what I uploaded. The times are correct, just that I thought I did one route. I am confused.

Alright, here's what I did: I jumped that tricky route, got to screen position 81, because being in 80 would trigger the enemy's attack and lag the game hard. Then after the next segment loaded, I specifically moved back and forth just to set myself in screen position 80 for the door. Despite the frames needed, this is still faster than just taking the door at 81, and I trigger the boss earlier as a result. I don't remember doing this, but obviously I had to have done it, since no one else decided to have a secret TASing session on my laptop. My memory is definitely not perfect.

In other news, I did avoid one spot of damage and kept the barrier so I can get a better spot for the last Flame Charge. For whatever reason, I had trouble with falling through the floor in the transition between Segments 7 & 8, and delaying a frame let me land normally. Curiously, the delay I chose let me avoid a shot that just barely hit me. So the barrier lasted long enough for my needs.

I'm selecting out things that make sense to read in real-time. Fiddly numbers like when item drops happen is difficult to display appropriately in real-time.

Currently shows barrier, weapons, and size of current segment. I hope it's pretty.

f37033 *** STAGE 5 ***
f37768 Segment 0: 735 (T2: 736 ; T4:761)
f38248 Segment 1: 480 (**: 477)
f38558 Segment 2: 310 (T4: 309)
f38681 Segment 3: 123 (T3:_ 91)
f38758 Segment 4:_ 77 (T3: 241)
f38873 Segment 5: 115 (11: 116)
f39332 Segment 6: 459 (T3: 451)
f40070 Segment 7: 738 (T2: 735)
f40330 Segment 8: 260 (T4: 279)
f40475 Segment 9: 145 (T4: 129)
f40709 Segment10: 234 (T3: 234)
f42122 Segment11:1413 (T4:1408)
=== END OF STAGE 5 (Frames: 5089) === (T3:5310)

Preliminary look at Stage 5. I'm on the bad side of the frame rule by the boss. Stages 3 & 6 were tacked on the end of this TAS, as proof of concept as to how readily I can just sync stages however I please, though I did need to fix a few weapon swaps.

Bubble Barrier Charge Swap was used extensively, from the start of the stage to its very end. I'm not happy with all 18 hits the barrier took, I can benefit from keeping just one more hit for the end, as I prematurely fired my Flame Charge, landing me on the save platform. It was that or wait out 16 ouch frames. Probably time to look for the least costly hit to preserve.

Still, the Miniboss Skip accounts for 150 frames, give or take 50. I'm 221 frames ahead of the leading team, so at least Miniboss Skip can't really take all the credit from the improvements. I did not carefully compare optimizations between this run and the teams, so this stage can stand for another look over.

Felt nice to just go straight through enemies. I refused to preserve Bubble Barrier whenever it meant I get even one frame of lag.

Removed the stage select delay between Stages 1 & 4. Not only have I found the ammo to maintain a speedy run, but I even removed one lag and saved a frame rule. 24 frames delay inserted between Stages 4 & 3.

Items seemed to manipulate themselves before the miniboss, balancing out exactly with what I had before. The Ghost Fall segments needed some tweaking to get the ammo I need. After that, a change in strategy was needed, and the route had enough rigidity that I couldn't stop the game from producing a bunch of small ammo refills out of reach. Whatever the case, I got enough to reach the end, and the game still had to throw one more refill out of reach when it was no longer important. Somehow, I find this humorous.

I'm more in a mood to look at a stage I haven't optimized. Expect either a fixed Stage 3 or progress on Stage 5. I'm pretty sure anything I do in 4->5 can be readily transferred into 4->3->6->5, as I don't think the weapons in 3 and 6 give any benefit in 5. Probably just a matter of handling extra weapons in the swaps, hopefully 2 frames per swap isn't a major problem in the route.

I'm pretty sure jumping through a ceiling should cause a headache or two. Still, I'm through one faster, and overall now have Stage 7 done 4 frames sooner.

The intentional 8 frames delay between s7 and s1 is also removed. Going through Stage 1 again, I've started it 12 frames earlier, which is 1 and a half dialog frame rules. We were delayed half a dialog frame rule to begin with, so we started the boss 2 dialog frame rules ahead, and so I leave Stage 1 with 16 frames advantage.

That 16 frames advantage is tossed away in the delay between s1 and s4. Stage 4 heavily uses Flame Charge. Item drops are critical.

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.