User Files for Segapede

Specifically for #9029: Induviel & Spikestuff's Genesis Segapede in 00:11.48.
If you want a value specific one use (and modify honestly, it can be cleaned up more) UserFiles/Info/638493265433382096 then come back here once done.

Haven't been able to find a better route, so I tried optimizing further, 7 more frames off, there's probably more frames to save somewhere. This only makes sense to submit if its actually perfect, since its so short.

The input after the gem warp is still by Spikestuff, slightly modified to make it sync.

Induviel & Spikestuff

Induviel's opening input until they touch the gem, rest is mine.

ADMITTEDLY I AM NOT 100% SURE THIS HITS THE FLAG.
Let me quickly explain. In practice there's this jump that makes it without needing to hit anything else after (image below).
I do that jump on this userfile blind with the only value I'm looking at being the y coordinates (0x86E2), now I could find the x coordinates to validate, but I'm blind like this jump.

Roughly what's happening:

White represents alive input, Grey represents no input, but projected path.

Looking at the level map Spikestuff linked to on the other userfile, I thought of another route that could be potentially faster, and it was. Basically, instead of descending to the first gem on the previous route, you go right and jump down to a lower track, then jump to the second gem. Main timesave here is the fact that you pick up the trail segment along the way, speeding up the section after the gem warp.

Still some frames to save, but its getting more optimal, this is probably the fastest route, unless there's some faster way of reaching the gem, maybe somehow clipping through the tracks.

Induviel & Spikestuff

Induviel's opening input just before they touch the gem is used, rest is mine.

Found out that those big emerald things warp you around if you jump on them somewhat specifically, not sure if its a glitch or intended. Anyway, found a different route using this tech where you do that twice, saving a good amount of frames, this is just a rough test to check if it was actually faster, so its very unoptimal, since you are warping around you can't see what's going on, and I didn't want to try optimizing where I don't see anything.

This movie is 8 frames faster than Induviel's userfile upload in pure input and 16 frames faster in reaching the goal thanks to better lag management and speed control—which are mostly the same thing in this "game" because it lags when you move slower or faster than it wants you to and is extremely picky about it.

It is further improvable if you find out a better lag management strategy and/or lengthen the input to make the character reach the goal sooner. I'm not going to submit this unless I solve the extra frames of lag in the last section or find a way to move at >10 px/f (which is technically possible) at will; feel free to use the movie as a reference for your own attempt. The horizontal subpixel speed address is $86F0. Sub-880 feels doable.

Suboptimal.