Speedshots, What are they and how do they work?

[RNC1839]

Speedshots, What are they and how do they work?
 
So we all know what a speedshot is, it's merely when a rocket hits the ground exactly when the player that fired the rocket also hits the ground.
Great that's solved but what's so special about them?
 
The SPEED! 
The fun, useful part of speedshots is the massive, compounding horizontal velocity and distance you gain.
 
An important thing to note is that when a player normally rocket jumps and then just stops when they hit the ground they don't stop instantly.
There is 1 tick in which the player's vertical velocity gets set to 0 while the horizontal velocities don't.
 
Data:
 

Spoiler (click to show/hide)

Just landing:
xloc            yloc            zloc            xvel            yvel            zvel
886.652099      295.968750      144.799224      636.895507      0.000000        -653.608825
896.205505      295.968750      134.905090      636.895507      0.000000        -665.608825
905.758911      295.968750      128.031250      636.895507      0.000000        0.000000
909.358886      295.968750      128.031250      240.000000      0.000000        0.000000
912.742858      295.968750      128.031250      225.600006      0.000000        0.000000
 
Speedshot:
xloc            yloc            zloc            xvel            yvel            zvel
895.636901      172.343704      144.545059      750.914855      56.947010       -559.742309
906.903076      173.176376      136.058929      751.078674      55.511615       -571.742309
918.169250      174.009048      128.031250      836.966918      184.652313      624.239807
930.784973      176.242309      137.304840      841.048400      148.884429      612.239807
943.461914      177.939056      146.398437      845.129882      113.116546      600.239807

So as you can see, looking at the just landing data you see that on the third tick the zvel (vertical) becomes 0 while on the fourth tick weirdly the horizontal velocity gets set to the class' max velocity. (and the reason yvel is 0 is because I was rubbing against the wall when recording the jump)
 
And when you look at the speedshot data all velocities increase on the thrid tick when the speedshot happens. The zloc during the speedshot is 128.031250 and we can through out the .031250 so 128 is the height of the speedshot platform.
So that's great we know that speedshots happen right when you hit the ground. Except that sometimes they don't.
 
While testing I got other speedshot recordings that looked like this one:

Spoiler (click to show/hide)

xloc            yloc            zloc            xvel            yvel            zvel
900.410766      218.700271      146.973480      772.022705      -127.079971     -563.458435
911.991088      216.794067      138.431610      772.022705      -127.079971     -575.458435
923.571411      214.887863      129.709732      984.727050      -51.392929      584.091979
938.294677      213.579071      138.381103      981.551879      -87.252624      572.091979
952.988281      211.911743      146.872482      979.574157      -111.154708     560.091979

Now we know that 128 is the height of the speedshot platform and yet when I got the speedshot I was at 129.709732, a whole 1.709732 units above the ground. What does that mean?
 
Well, weirdly, it means that I actually got a 'lucky' bounce. Now this is mostly about speedshots but when this happens we don't speedshot on the ground but we do speedshot on the "ground" (the quotes are important).
 
In TF2 (and all source games), the "ground" is defined as 0-2 units above the actual ground. And for the forward thinking this is how bounces work too.
 
 
So I've covered what they are the basics of how they work, but why do they work?
I'll cover the bounce and "ground" stuff later in another one of these posts.
 
But for now, I bring up one very crucial source for all this nonsense.
 
THE SOURCE CODE!!!
https://github.com/ValveSoftware/source-sdk-2013
 
Specifically this one function in this one file:
https://github.com/ValveSoftware/source-sdk-2013/blob/55ed12f8d1eb6887d348be03aee5573d44177ffb/sp/src/game/server/physics_main.cpp#L1840
 
What that one function basically does is control the friction generated from the platform you land on, and adjust speed accordingly.
That is the whole backbone of not only speedshots but also bunnyhopping and edgebugs.
 
 
Now again the astute of you may think that some textures have lower friction than others, so would that make speedshots any easier on say glass or ice?
Well you'd be correct about the friction thing, but sadly no speedshots are no easier on low friction textures. The horizontal velocities get set to the class's max velocity too fast.
 
Data:

Spoiler (click to show/hide)

xloc            yloc            zloc            xvel            yvel            zvel
955.318298      -38.236213      -348.044342     510.637817      148.685989      -615.414489
962.977844      -36.005924      -357.365570     510.637817      148.685989      -627.414489
970.637390      -33.775634      -366.866790     510.637817      148.685989      0.000000
974.093872      -32.769195      -367.968750     230.430297      67.096008       0.000000
977.420715      -31.800497      -367.968750     221.789154      64.579902       0.000000

 
 
But that's not really that important. And yes if you could make a texture with 0 friction in theory you could speedshot at any time
BUT frictions are based on the "$surfaceprop" value in the VMT and there are only so many that Valve has made available, and I don't know of any that have friction of 0.
 
From https://github.com/ValveSoftware/source-sdk-2013/blob/55ed12f8d1eb6887d348be03aee5573d44177ffb/sp/game/mod_episodic/scripts/surfaceproperties_ep2.txt
 
"friction: this is the physical friction (0 - 1.0, 0.01 is slick, 1.0 is totally rough)"
 


If you have any further questions please feel free to ask, I will try to answer everything as well as I can. Also keep in mind I'm probably wrong somewhere in here.

All data sourced from jump_rebound_v3 and jump_hexahedron using Jrecord, or the github repo linked above.

TL;DR: just read the second/third line, if you don't care about the actual physics behind it, that'll be a good enough explanation for you.

[plep]

Holy shit.

[HyperDan]

[BQE]

[Balls]

Really interesting, I'm keen to understand more...

I'm not at all familiar with source, so I wonder if you could put a couple of things in context for me... if you know yourself

• The argument to the friction function, (float) timestep, what kind of value will this pass?
• sv_friction.getFloat(), is this the point where the material friction is included? Or is it GetFriction()?
• VectorLength( vecAbsVelocity ) - what does this return? Current or maximum velocities?

Well if you don't know don't worry, I should just learn to source anyway.

[RNC1839]

Really interesting, I'm keen to understand more...

I'm not at all familiar with source, so I wonder if you could put a couple of things in context for me... if you know yourself

• The argument to the friction function, (float) timestep, what kind of value will this pass?
• sv_friction.getFloat(), is this the point where the material friction is included? Or is it GetFriction()?
• VectorLength( vecAbsVelocity ) - what does this return? Current or maximum velocities?

Well if you don't know don't worry, I should just learn to source anyway.

I'm gunna be guessing a bit here but

1. The float timestep is basically just 1 tick in fancy terms, and my guess for why it's a float instead of int is because it doesn't actually run off of a tick count, but a real amount of time. Which makes sense because the standard tickrate for tf2 is 66.666666...
2. I would think that sv_friction would be some sort of server based multiplier or something (like sv_noclipspeed). I would guess GetFriction() is what looks at the VMT's $surfaceprop.
3. VectorLength( vecAbsVelocity ) should just return the total velocity of the player. This can be seen with cl_showpos 1 it's the vel number there. Which is silly because it just merges all 3 velocities into one. But I'm not really sure which velocity/velocities it returns, it could just be X and Y, while Z is dealt with elsewhere.


Now an interesting point is that if sv_friction exists it could possible be set to 0 through sourcemod much like sv_airaccelerate, which would then allow for some weird interactions.

Quick Edit:
Yup sv_friction is a thing... and it's weird.

[Balls]

Hey,

So guyyst spoke to me too and basically said what you just replied here... sorry! But yeah the bit I'm miffed about now is why it would use all 3 velocities... Perhaps the assumption being that a rough calculation is good enough? I mean some shortcuts must have been made in order for RJ to be as it is.

I'm going to play with sv_friction now

[Lopez]

What, then, is the difference between a speedshot and an edgeshot? Other than the obvious, with one requiring an edgebug and one not.

[RNC1839]

What, then, is the difference between a speedshot and an edgeshot? Other than the obvious, with one requiring an edgebug and one not.

Good question. I was going to answer this when I wrote up the little post for edgebugs but here works too.

With an edgeshot the window where you can do it successfully is much bigger.

Speedshots have a 1 tick window
Edgeshots are more like 4 ticks, and that window gets smaller based on how fast you go horizontally.

The reason is that your vertical velocity gets reset to 0 so after a few ticks you're not falling fast at all, so the effects of the rocket are still fairly big.

[pardinensis]

Does that mean that the difference between speedshots and bounces is that bounces require you to touch the surface between 1 and 2 HU above the actual ground and speedshots do not?

[RNC1839]

Does that mean that the difference between speedshots and bounces is that bounces require you to touch the surface between 1 and 2 HU above the actual ground and speedshots do not?

Yes

[Balls]

Are speedshots really a 1 tick window though? Or is it that a speedshot occurs in a 1 tick window but there are several points where you can fire and make a speedshot?

[pardinensis]

Are speedshots really a 1 tick window though? Or is it that a speedshot occurs in a 1 tick window but there are several points where you can fire and make a speedshot?

Without having done any maths, I think that there should be a window of several ticks to fire the rocket, especially since in most cases, the speed of the rocket is fairly similar to yours. The only important thing is that the rocket explodes in the exact same tick as you touch the ground.

Does that mean that the difference between speedshots and bounces is that bounces require you to touch the surface between 1 and 2 HU above the actual ground and speedshots do not?

Yes

Someone please do a V-shaped surf into a speedshot-bounce thingy!

[RNC1839]

Are speedshots really a 1 tick window though? Or is it that a speedshot occurs in a 1 tick window but there are several points where you can fire and make a speedshot?

Without having done any maths, I think that there should be a window of several ticks to fire the rocket, especially since in most cases, the speed of the rocket is fairly similar to yours. The only important thing is that the rocket explodes in the exact same tick as you touch the ground.

Well it's a 1 tick window for when the rocket and the player hit the ground, when you fire is something much more complex.

Rockets travel at 1100 u/s (16.5 u/tick) in whatever vector they are spawned.
Players travel in a parabola shape which eventually ends in hitting the ground.
So really there are (in theory) two 1 tick windows at which both player and rocket will hit. Which explains prefire speedshots.

So what about bounces? one of you is probably thinking, Do they also have two 1 tick windows?
No they don't, at least not the conventional, mostly vertically based bounce. Speedbounces on the other hand could. I'd need to look into that further to be sure though.

Someone please do a V-shaped surf into a speedshot-bounce thingy!

That is a really good idea. 

[Balls]

Rockets travel at 1100 u/s (16.5 u/tick) in whatever vector they are spawned.
Players travel in a parabola shape which eventually ends in hitting the ground.
So really there are (in theory) two 1 tick windows at which both player and rocket will hit. Which explains prefire speedshots.

Are you sure that's the case? I'm just speculating, but my gut feeling is that the timescales are more lax than this. I imagine the 1 tick window would apply to the actual generation of a speedshot, however to the best of my understanding, the firing window would be larger due to the variety of aiming that can be used (more speed, more height), and also as stated earlier that the ground can be 0-2 units above ground.

For bounces it makes sense that there is a 1 tick window because any more and you'll get reset, but that's not the case with speedshots.

If I'm even close to right thinking this, it could also be that pre-fire speedshots are simply like bounces with more speed/height, and would also explain why having more speed/height makes it harder to time a speedshot because the amount of viable shots that land on the right tick would be reduced.