Checkpoint: Difference between revisions

Created page with "'''Checkpoints''', or '''CPs''', are a mechanic in ''Mario Kart Wii'' used to track progression through the lap. They handle lap counts and respawn locations. The checkpoint system attempts to prevent unintended shortcuts from counting the lap. However, there are several oversights in the system, which makes it possible to skip a majority of the track and still get a lap count. == Overview == Checkpoints are (convex) quadrilaterals on the XZ plane, spanning inf..."
 
Mikul (talk | contribs)
Addition of anomalies, minor rewrites, TODOs for structuring
Line 4: Line 4:


== Overview ==
== Overview ==
<TODO i am going to look at restructuring a lot of this -Michael>
Checkpoints are (convex) quadrilaterals on the XZ plane, spanning infinitely up and down, which cover the entire track. Only the vehicle's origin point (i.e. its center) is used to determine what checkpoint it's currently in. The current checkpoint value is used to determine the Race% value (as explained below), as well as the respawn point after being counted out of bounds. These values stop updating if the vehicle enters an area without an active checkpoint.
Checkpoints are (convex) quadrilaterals on the XZ plane, spanning infinitely up and down, which cover the entire track. Only the vehicle's origin point (i.e. its center) is used to determine what checkpoint it's currently in. The current checkpoint value is used to determine the Race% value (as explained below), as well as the respawn point after being counted out of bounds. These values stop updating if the vehicle enters an area without an active checkpoint.


Line 13: Line 15:
The intended functionality of key checkpoints is preventing unintended shortcuts. If the vehicle progresses through the track as intended, it crosses each KCP in order, eventually activating the final KCP and the finish line to receive a lap count. On the other hand, if the vehicle skips a key checkpoint, the next checkpoint regions are not activated, preventing as the finish line checkpoint remains deactivated.
The intended functionality of key checkpoints is preventing unintended shortcuts. If the vehicle progresses through the track as intended, it crosses each KCP in order, eventually activating the final KCP and the finish line to receive a lap count. On the other hand, if the vehicle skips a key checkpoint, the next checkpoint regions are not activated, preventing as the finish line checkpoint remains deactivated.


=== Lap%, Race% ===
=== LapCompletion, RaceCompletion ===
'''Lap%''' and '''Race%''' are two float values used internally to keep track of the vehicle's progress through the lap. Lap% is a value between 0 and 1, and it is updated each time the vehicle enters a new checkpoint. Race% is not bounded, the integer and decimal parts represent the current lap count and lap progress respectively, and it is updated each frame that the vehicle is inside a checkpoint.
'''LapCompletion''' and '''RaceCompletion''' are two float values used internally to keep track of the vehicle's progress through the lap and race. LapCompletion is a value between 0 and 1, and it is updated each time the current checkpoint changes. RaceCompletion consists of an integer and decimal portion, where the integer portion represents the current lap count and the decimal portion represents lap progress. Unlike LapCompletion, RaceCompletion is updated on every frame.


The Race% value increases linearly within each checkpoint, from the back to the front. The exact value of Lap% and the decimal part of Race% roughly correspond to the proportion of lap driven, but the values are arbitrary and not very accurate in many cases.
The LapCompletion value increases linearly within each checkpoint, from the back to the front. The exact value of Lap% and the decimal part of Race% roughly correspond to the proportion of lap driven, but the values are arbitrary and not very accurate in many cases. <TODO this is wrong, rewrite tomorrow, make a shaded diagram of GV lapcompletion or something>


The Lap% value is involved in a failsafe to prevent lap skips. If Lap% increases by more than 0.95, then Race% decreases by 1 (to subtract a lap). Likewise, if Lap% decreases by more than 0.95, then Race% increases by 1. These failsafes are known as the '''95% rule''', and '''reverse 95% rule''' / '''5% rule''', respectively.
LapCompletion is used in the '''95% rule''' and '''5% rule''' that are used to combat ultra shortcuts and delayed lap counts. RaceCompletion is used in determining the progression through the race, and consequently the positions of players. It is rarely involved in any useful glitches or exploits.


=== Lap count rules ===
=== Lap count rules ===
Line 30: Line 32:
*Else, if the new checkpoint value is a different CP in the last KCP region and the Lap% value increases by over 0.95, then the lap count decreases by 1.
*Else, if the new checkpoint value is a different CP in the last KCP region and the Lap% value increases by over 0.95, then the lap count decreases by 1.


== Exploits ==
== Glitches & exploits ==


=== Ultra shortcut ===
=== Ultra shortcut ===
Line 38: Line 40:
It is also possible to quickly decrease the lap counter with a similar method. Going from any but the last CP in the final KCP region to KCP 0, while decreasing the Lap% value by less than 0.95, does not trigger the failsafe to increment the lap counter by 1.
It is also possible to quickly decrease the lap counter with a similar method. Going from any but the last CP in the final KCP region to KCP 0, while decreasing the Lap% value by less than 0.95, does not trigger the failsafe to increment the lap counter by 1.


=== CP 1 trick ===
=== CP1 trick ===
Entering a checkpoint from the front results in a higher Lap% value than entering from the back. For example, entering CP 0 from the back results in a Lap% of 0.0000; moving into CP 1 and then back causes Lap% to update to a higher value, while still being in KCP 0. This is useful for making the 95% rule requirement more lenient when performing ultras.
Because LapCompletion only updates upon entering a new checkpoint, it can effectively be "boosted" by driving into the next checkpoint ahead and back into the current one. This updates your LapCompletion to a value towards the front of the checkpoint, rather than the back. It is most commonly applied by driving forwards to CP1 and back into CP0 to make the 95% rule easier to satisfy, hence the name. However, it can also be used to satisfy the 5% rule when performing delayed lap counts, such as on the Rainbow Road unrestricted flap.


=== Delayed lap count ===
=== Delayed lap count ===
Line 49: Line 51:
=== Ghost checkpoints ===
=== Ghost checkpoints ===
:''Main article: [[Ghost checkpoints]]''
:''Main article: [[Ghost checkpoints]]''
The vehicle is considered to be inside a checkpoint if it is between the quadrilateral's side boundaries, in front of the "back" line, and behind the "front" line. However, due to a sign error during one of the calculations, with certain configurations of checkpoints it is possible to be considered simultaneously in front of the first CP, behind the second CP, and within side boundaries of both. In this case, a failsafe is triggered which considers the vehicle to be right on the line connecting the two CPs. This causes the effective range for certain checkpoints to extend far past the quadrilateral itself. The calculation error generally occurs when the front and back lines of a CP are not parallel.
The vehicle is considered to be inside a checkpoint if it is between the quadrilateral's side boundaries, in front of the "back" line, and behind the "front" line. However, due to a divide by zero error during calculations, some checkpoint configurations cast regions where one is simultaneously considered in front of the first checkpoint, behind the second checkpoint, and within side boundaries of both. In this case, a failsafe is triggered which places the driver on the boundary between the two checkpoints. These regions can be cast far beyond the boundaries of the checkpoint quadrilaterals themselves, and in many cases they extend infinitely outwards.
 
There are multiple checkpoint configuration patterns that can cause ghost checkpoints. However, they generally occur when the boundary between two checkpoint quadrilaterals is slanted, and the side boundaries of those checkpoints are otherwise parallel.
 
<put an image here or something>
 
==== Split path ghost checkpoints ====
<blah>
 
 
Ghost checkpoints can be viewed for any track or KMP file through the [https://gcp-finder.fly.dev/ Ghost Checkpoint Viewer], written by EPIK95.


=== Lap underflow ===
=== Lap underflow ===
Line 60: Line 72:


The timer failsafe is far too strict to underflow the lap counter in the time limit on any Nintendo track, and because lap times after the failsafe are not calculated properly, they are not valid flap runs. Regardless, underflowing the lap counter is banned in every category according to the [[Category rules | TAS ruleset]], including Unrestricted.
The timer failsafe is far too strict to underflow the lap counter in the time limit on any Nintendo track, and because lap times after the failsafe are not calculated properly, they are not valid flap runs. Regardless, underflowing the lap counter is banned in every category according to the [[Category rules | TAS ruleset]], including Unrestricted.
== Anomalies ==
These are unintended behaviors that show up as a result of checkpoint misuse. As the game makes assumptions about the shape and configuration of checkpoints, breaking these rules can lead to unexpected consequences. As Nintendo tracks were made with these assumptions in mind, these effects generally only come into play on custom tracks, but they are documented for completeness regardless.
=== Concave checkpoints ===
TODO
=== Incomplete split paths ===
TODO
=== Fake key checkpoints ===
TODO
=== Split path key checkpoint loading ===
TODO