Difference between revisions of "Sloped Step Boost"

From P2SR Wiki

m (Jerry moved page Step Slope Boost to Sloped Step Boost without leaving a redirect: glitch being renamed lmao)
m (fix code blocks)
Line 7: Line 7:
 
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 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>.
  
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.
+
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.
  
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.
+
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.
  
 
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.
 
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.

Revision as of 04:56, 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