Difference between revisions of "Sloped Step Boost"
(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...") |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | {{P2_Title|Step | + | {{P2_Title|Sloped Step Boost}} |
==Overview== | ==Overview== | ||
| − | Step | + | '''Sloped Step Boost''' (also known as Step Slope Boost or SSB) 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 | + | 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. | |
| − | + | 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]< | + | |
| + | 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 | + | 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 | + | 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 /> | ||
Latest revision as of 05:14, 1 November 2023
Contents
Overview
Sloped Step Boost (also known as Step Slope Boost or SSB) 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
- ↑ The distance of 18 units is determined by
m_flStepSizeproperty. - ↑ 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