[TF2] Fix tf_parachute_maxspeed_xy to dampen overall horizontal speed instead of individual X/Y speed components#1952
Conversation
|
I'm reasonably certain this doesn't limit any esoteric parachute charging tech, but I've put up a demo branch at https://github.com/FlaminSarge/source-sdk-2013/tree/parachute-fix-demo that has a cvar to toggle this fix on and off. @SolarLightTF2 give it a look to see if I've broken anything. |
|
425 is a tad too high for more general usage (Soldier, Sticky Demo) since players are more likely to hover around 300-350-ish due to constant speed fluctuation, so this would be a buff akin to reverting the speed nerf that was made in the Jungle Inferno update. The speed of 425 was only achieveable on these classes/loadouts when using this "tech" to float in straight lines, as any attempt at strafing begins clamping it back down to 300-350. The "tech" to move at 400 on Soldier/Sticky demo is only used by a small portion of players purely as a means of traversal and not as part of air strafing or dodging attack while firing at enemies. Maybe 350 is a good middle ground since it is the value in between the minimum (intended) speed and the faster speed of 400-ish that was only attainable in straight lines. The lazy option would be to just set it to the intended value of 300, but this would be noticeable downgrade to the item. A seperate speed cap for charging players would be a very appreciated buff given how poorly this item pairs with Demo shields, but this is likely outside of the scope of this PR |
I was under the impression that moving anywhere that isn't straight along the cardinal directions can net players quite a bit more speed even if strafing as long as they don't dip too deeply into the cardinal directions, though in practice I don't know how easy walking that tightrope is to pull off. Putting this in draft while I verify the behavior for very low cvar values and for when current speed is close to cvar value (resulting in negative flReduction values). |
|
I'm not at home to test this PR at the moment. But as of currently, I mostly use the "tech" as a means of preserving momentum from a rocket jump, and only in straight lines. A few days ago I gathered footage with a speedometer plugin and observed strafing quickly deleting this excess speed. Being able to keep the speed of 425 while air strafing and dodging as Soldier would be a significant buff (if this is the behavior in the PR) |
|
For comparison: Current base jumper sometimes lets you chase Medics but cannot catch up to or flee from Scouts on a consistent basis, especially since trying to hit 425 hu/s is so angle-constrained (not to mention how it mainly works off of existing rocket jump momentum, and this extra speed can be lost easily from strafe attempts or knockback) A consistent 425 base jumper would be able to chase down Scouts or more easily escape Scouts, not to mention engagements vs every other class being buffed too. Dodging by air strafing in quarter-circles etc. would also be more effective as mentioned earlier. |
… instead of individual X/Y speed components B.A.S.E. Jumper handling was reducing X and Y speeds individually which could result in unexpected movement when deploying parachutes at high speeds or charging based on how the player was aligned with the map's coordinate grid. This commit updates the handling to dampen the XY speed correctly regardless of which direction the player is moving. This also increases the XY speed clamp to 425 which was the previous max speed people could reach if traveling along diagonals (sqrt(2*(300^2)), rounded up) to avoid nerfing it.
…speed checks Also prevents removing too much speed as current speed approaches tf_parachute_maxspeed_xy value
FlaminSarge
force-pushed
the
parachute-charge
branch
from
da29d77 to
6269e52
Compare
|
Changed to 350, have some folks give it a go on the demo branch and see how it feels. (For what it's worth, the average speed value for all angles a player could be traveling would end up as ~336.66, if I'm remembering math correctly; avg value of 300sec(x) from 0 to 45 degrees).
Oddly enough, due to the way all the movement gets calculated, charging while parachuting (both before and after patch) seems to add ~150HU/s to your speed (so 450 with cvar 300, and 500 with cvar 350); the patch just makes it go in the direction you're looking. |
FlaminSarge
changed the title
2 participants
Description
B.A.S.E. Jumper handling was reducing X and Y speeds individually which could result in unexpected movement when deploying parachutes at high speeds or charging based on how the player was aligned with the map's coordinate grid.
This commit updates the handling to dampen the XY speed correctly regardless of which direction the player is moving.
This also increases the XY speed clamp to
425 which was the previous max speed people could reach if traveling along diagonals (sqrt(2*(300^2)), rounded up) to avoid nerfing it350 per community recommendation as an in-between value of minimum to maximum (300-425) achievable speeds under the old bugged behavior. (As a note: the average speed cap was ~337 based on the average value of 300/cos(angle) between 0 and 45 degrees, so this 350 is a buff on average).The end result of this is that parachuting charging players will move in the direction they're looking, instead of the current behavior where they move at arbitrary off-angles based on how they align with the map's coordinate grid.
Demonstration (man):
Before fix, at angles of 0, 3, 40, 45, and trying to turn:
charging_pre_fix.mp4
After fix: at angles of 0, 3, 45, 40 (got the order wrong in editing, sorry), and trying to turn:
charging_post_fix.mp4