Difference between revisions of "Sloped Step Boost"

From P2SR Wiki

(Created page with "{{P2_Title|Step Slope Boost}} ==Overview== Step Slop Boost is a glitch that converts speed from one axis to another (for example horizontal to vertical) while adding a little...")
 
(rewritten to be more accurate)
Line 1: Line 1:
{{P2_Title|Step Slope Boost}}
+
{{P2_Title|Sloped Step Boost}}
  
 
==Overview==
 
==Overview==
Step Slop Boost is a glitch that converts speed from one axis to another (for example horizontal to vertical) while adding a little bit of additionnal speed when hitting a specific configuration of slopes.
+
'''Sloped Step Boost''' is a glitch that results in an additional velocity given from a step slope collision due to an error in the code.
  
 
==Explanation==
 
==Explanation==
When you're walking on ground and hit a wall or a slope you're not supposed to walk on, it triggers a step logic - basically tries to allow the player to move above whatever player collided with so they can stand on it. It does so by checking if you could stand on anything solid if you were moved 18 units up, along your current velocity vector, and back down (that's also why the maximum height of step you can walk onto is 18 units).  
+
When you're walking on ground and hit a wall or a slope you're not supposed to walk on, it triggers a step logic, which tries to move the player up the step without stopping them. It does so by checking if the player can stand on anything solid if you were moved 18 units up, then along their velocity vector, and back down 18 units<ref>The distance of 18 units is determined by <code>m_flStepSize</code> property.</ref>.
  
When that's true, something interesting happens. If the conditions are right, the game will tweak your velocity in a certain way. In older Source branches, all that happened is the Z component of your velocity was set to the one resulting from the slope collision. However, for Portal 2, a bunch of movement code was rewritten to support sticky gel (which wasn't ultimately used), so lots of strict axis-based assignments like this were replaced with vector math. Apparently, some Valve employee had a bad day and fucked up the math horribly.
+
If the step check succeeds, two sets of position and velocity vectors are used: one being a result of a regular movement and collision from current player position (referred in code as <code>down</code> position and velocity), and the other being a result of a step move, that is, a movement and collision from a position 18 units above the player's position (referred in code as <code>up<code> position and velocity). What was in developers intention is that when <code>up<code> position is further from player's initial position than <code>down</code> position, player's velocity is set to a sum of horizontal part of <code>up<code> velocity and vertical part of <code>down</code> velocity.
  
Essentially what happens is the upward velocity resulting from the slope collision gets added to each component of your velocity as a value, and then once again to the vector itself. What that means in practice is, with right conditions, you can gain lots of velocity instantaneously from seemingly nowhere.
+
However, because of incorrectly written code<ref>The relevant part of game movement's code can be viewed here: https://github.com/perilouswithadollarsign/cstrike15_src/blob/f82112a2388b841d72cb62ca48ab1846dfcc11c8/game/shared/portal/portal_gamemovement.cpp#L3233</ref>, the resulting velocity is a sum of the entire <code>up<code> velocity, vertical part of <code>down</code> velocity and a unit vector scaled by the vertical factor of <code>up</code> velocity.
As an example, let's say you're colliding with a slope with velocity [-1000, 0, 0], and velocity resulting from a slope collision becomes [-200, 0, 400]. If conditions are right and the faulty math code is triggered, you're ending up with velocity vector [200, 400, 1200]<ref>This explanation was found by Krzyhau in [https://discord.com/channels/146404426746167296/1165354343470465145 this thread]</ref>.
+
 
 +
This essentially means that if vertical component of <code>up</code> velocity is a non-zero value (in other words, a movement along your current velocity vector from a position 18 units higher would result in a collision with a slope), that value is not only preserved, but added to each component of velocity vector, with an additional bonus of vertical factor of <code>down</code> velocity, ultimately giving you much more velocity than you should receive from a step collision.
 +
 
 +
As an example, let's say you're colliding with a slope with velocity <code>[-1000, 0, 0]</code>, and velocity resulting from a slope collision for both <code>up</code> and <code>down</code> cases becomes <code>[-200, 0, 400]</code>. If conditions are right and the faulty math code is triggered, you're ending up with velocity vector <code>[200, 400, 1200]</code> - even more than you had before the slope collision.
 +
 
 +
An interesting observation is that the wall or slope you're hitting to trigger a step movement doesn't have to be the one the game attempts to step on.
 +
 
 +
Additionally, the game actually checks for a ceiling when attempting to test for <code>up</code> movement 18 units higher by tracing player's bounding box upwards, and if there's a hit on its way, it does the movement from that position. This allows to manipulate the <code>up</code> movement initial position and gives an ability to invoke the step slope boost without higher steps. Example of this can be seen in Portal Carousel's entry corridor, where by strafing next to a tilted wall you can achieve described behaviour.
  
 
==Usage==
 
==Usage==
This glitch currently has no known uses, although some are being looked into for LP purposes.
+
This glitch currently has no known uses, although several theoretical TAS-only routes are being considered at the moment of writing this article.
  
However, it provides an explanation for a long known boost in Portal Carousel, for which the exact cause was often dismissed as "weird geometry".
+
However, it provides an explanation for a long known boosts (like the one at the end of entry corridor in Portal Carousel or the one at the beginning of elevator stairs in Pit Flings) for which the exact cause was often dismissed as "weird geometry".
  
 
==References==
 
==References==
 
<references />
 
<references />

Revision as of 04:55, 1 November 2023

Sloped Step Boost


Overview

Sloped Step Boost is a glitch that results in an additional velocity given from a step slope collision due to an error in the code.

Explanation

When you're walking on ground and hit a wall or a slope you're not supposed to walk on, it triggers a step logic, which tries to move the player up the step without stopping them. It does so by checking if the player can stand on anything solid if you were moved 18 units up, then along their velocity vector, and back down 18 units[1].

If the step check succeeds, two sets of position and velocity vectors are used: one being a result of a regular movement and collision from current player position (referred in code as down position and velocity), and the other being a result of a step move, that is, a movement and collision from a position 18 units above the player's position (referred in code as up position and velocity). What was in developers intention is that when up position is further from player's initial position than down position, player's velocity is set to a sum of horizontal part of up velocity and vertical part of down velocity.

However, because of incorrectly written code[2], the resulting velocity is a sum of the entire up velocity, vertical part of down velocity and a unit vector scaled by the vertical factor of up velocity.

This essentially means that if vertical component of up velocity is a non-zero value (in other words, a movement along your current velocity vector from a position 18 units higher would result in a collision with a slope), that value is not only preserved, but added to each component of velocity vector, with an additional bonus of vertical factor of down velocity, ultimately giving you much more velocity than you should receive from a step collision.

As an example, let's say you're colliding with a slope with velocity [-1000, 0, 0], and velocity resulting from a slope collision for both up and down cases becomes [-200, 0, 400]. If conditions are right and the faulty math code is triggered, you're ending up with velocity vector [200, 400, 1200] - even more than you had before the slope collision.

An interesting observation is that the wall or slope you're hitting to trigger a step movement doesn't have to be the one the game attempts to step on.

Additionally, the game actually checks for a ceiling when attempting to test for up movement 18 units higher by tracing player's bounding box upwards, and if there's a hit on its way, it does the movement from that position. This allows to manipulate the up movement initial position and gives an ability to invoke the step slope boost without higher steps. Example of this can be seen in Portal Carousel's entry corridor, where by strafing next to a tilted wall you can achieve described behaviour.

Usage

This glitch currently has no known uses, although several theoretical TAS-only routes are being considered at the moment of writing this article.

However, it provides an explanation for a long known boosts (like the one at the end of entry corridor in Portal Carousel or the one at the beginning of elevator stairs in Pit Flings) for which the exact cause was often dismissed as "weird geometry".

References

  1. The distance of 18 units is determined by m_flStepSize property.
  2. The relevant part of game movement's code can be viewed here: https://github.com/perilouswithadollarsign/cstrike15_src/blob/f82112a2388b841d72cb62ca48ab1846dfcc11c8/game/shared/portal/portal_gamemovement.cpp#L3233