sm-plugins/rngfix
1
0
Fork 0
mirror of https://github.com/jason-e/rngfix.git synced 2025-12-06 18:08:33 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update technical overview

Browse Source
This commit is contained in:
rio 2018-10-07 21:34:05 -05:00
parent 3aea927d8a
commit 46cabbe2d6
1 changed files with 30 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
tech.md
View File

@ -68,7 +68,7 @@ The rationale behind this is that, if the player is "landed" on the ground, then
--- ---
**Telehops** [Post-tick] **Telehops** [Post-tick]
If the plugin detects that a `trigger_teleport` was activated during this tick, and either: If the plugin detects that a `trigger_teleport` was activated during this tick, the player did *not* activate one the previous tick, and either:
* The plugin predicted right before the tick that a collision would occur during this tick (resulting in a change / loss of velocity) * The plugin predicted right before the tick that a collision would occur during this tick (resulting in a change / loss of velocity)
*or* *or*
* The plugin detected that the client landed during the simulation of the tick (resulting in an instant removal of Z velocity) * The plugin detected that the client landed during the simulation of the tick (resulting in an instant removal of Z velocity)
@ -77,6 +77,8 @@ Then the player's velocity is restored to the velocity they would have had after
The engine simulates each tick in a sequence of discrete steps, which to put it simply starts with a complete simulation of player movement including collisions with any solids, and only *after* this has finished does the engine check to see if the client is touching any triggers and activates them. This means it is not all that unlikely that a player will collide with something inside of or behind a thin `trigger_teleport` before triggering it, despite passing through it to even reach the point of collision. Occurrences of this issue are more prevalent on **lower** tickrates. The engine simulates each tick in a sequence of discrete steps, which to put it simply starts with a complete simulation of player movement including collisions with any solids, and only *after* this has finished does the engine check to see if the client is touching any triggers and activates them. This means it is not all that unlikely that a player will collide with something inside of or behind a thin `trigger_teleport` before triggering it, despite passing through it to even reach the point of collision. Occurrences of this issue are more prevalent on **lower** tickrates.
This fix is not applied if the player also activated a `trigger_teleport` on the previous tick to account for the speed-stopping teleport hubs some mappers use, especially on surf maps. These hubs typically teleport the player into a tiny box (or even inside a clip brush), and then at that location the player activates another `trigger_teleport` -- or sometimes one of several based on their `targetname` or `classname`. These are explicitly set up to stop the player's speed, and thus the fix should not be applied.
--- ---
**Stair Sliding** [Post-tick] **Stair Sliding** [Post-tick]