I've been experimenting with superbumps, and other places they could be used other than Territory.
The first thing I have found, is that the distance seems to be influenced by the game FPS. I recently got a new graphics card, and using it I get very high FPS (300-500) on low graphics settings. After getting it, I tried the superbump in territory and when I got it was propelled way beyond the droids to the wall behind them at very high speed. I'm not totally sure if this is due to the FPS, or I just got lucky, as after trying for a few minutes wasn't able to replicate it. My speculation for the mechanism behind this is that it has trouble calculating the collision when hitting something at an angle to the player's feet. The collision box actually goes into the edge for a frame, but then the game engine "realizes" it's inside and object and reverses your velocity direction and increases it's magnitude to get you out of the object. The high friction causes the player to quickly decelerate, but if you input a jump before you slow down, you can use it to get a lot of distance, but as far as I know, the height of your jump is unaffected.
Second, I couldn't find any other places it could be used, with the exception of possibly on final strike. After using the barrels in the first room to get up to the top, the slanted beams you climb up can be superbumped.
While I haven't been able to get a bump that propels 38 far enough, it does seem to be going in the right direction.
I also have had some bumps without a properly timed jump that shot me backwards very quickly, and it only seems like I have a few frames at most to input the jump. I'm not totally sure yet. It will take some more testing.
You are right for the explaination of the phenomenon. Although I'm not certain about the incidence of FPS.
If you want to work with superbumps here's a tip: bind "freezeframe x" to a key, where x is 1/FPS (something around 0.01) to perform the rebound frame by frame. When you see that upon touching the bump your frame as moved quite a bit, it means it's the time to unfreeze the game and jumping on that specific frame. To do that, write a text file with "jump, jump" (*), so that the first jump cancels the frozen state and the second jump is an actual one. Bind this tiny script to a key (with "exec nameofthefile").
(*): I'm not sure that's the proper syntax, but I don't remember and my computer has been reinitialized, so I cant tell... but you wouldn't have too much struggle to find the right command
this allows to perform the superbounce consistently.
As for skipping the Final Strike, I tried that too but it seems the trajectory isn't in the right direction. Maybe there are other bumps on the map. Also this is awfuly inconsistent for live runs.
If you want to investigate in Final Strike, I managed once to reach the 4th turret without going in the 3rd room. Here's how: once you barrel glitch to get on top of the map you can see there are columns/pillars - i mean those metal plates hanging against the wall - which are in fact plateforms, and one can imagine jumping on top of them to reach the turret balcony. However, the distance between such plateform and the ledge is too wide. Howeverever, not so wider. I definitly couldn't make it from the side that is adjacent to the 1st room, but I seems really possible from the side adjacent to the 3rd room.
I made this jump only once and couldn't reproduce it, maybe my computer lagged or some kind of magic idk. But maybe there's a solution.
(sorry, as I have to re-install every program on my laptop)
I'm not sure if FPS has something to do with it, but I was able to get the extra superbump on territory consistently using the freezeframe method:
I also successfully managed to use a superbump on Final Strike, but it is still inconsistent even when using 0.003s increments, so basically just for segmented/TAS runs.
I can't go as far as you do. I run the game at averagely 120FPS and I'm falling back without even flying over the ledge. I suppose the FPS thing is just that the gap between hitting the bump and jumping is even smaller, so the momentum computed is invertly bigger
That would make sense. I can also do it quite consistently. I tried a few times and only failed once, but I accidentally advanced one frame after the bump, and the player didn't even move much. Which means that not only is it frame perfect, each one of those frames is going to be 1/300s. However, if you get lucky, it can save a lot of time. Trying it in real time maybe 50 times or so, I got it 2-3 times.
It may also be positioning. It took a bit of trial and error to get just the right angle for it to work. I have a setup for it now too.