Check Point

KMP

File formats

Lists

Tutorials

Tools

This article explains how to define good check points (KMP/CKPT) for a Mario Kart Wii track following the new quadrilateral model.

Introduction

When starting with the analysis of the KMP in 2009, the section CKPT with 4 real values and 4 additional bytes for each point was also found. It was clear, that these 4 values are the x- and z-coordinates of a left and a right check point. And so the line model for check points was born. The line model says, that a check point is triggered when a driver crosses the line. This line model works very well for the most circumstances.

In 2012, the racing group around Wiimm found situations that can't be explained with the line model. It was AndyKs idea that quadrilaterals are important. With beginning of 2013, Wiimm created different test tracks to test the behaviour offline and online. The tests confirmed the quadrilateral model. This model helped Wiimm to fix the Position Jump Bugs of many tracks. The quadrilateral model says that a check point is triggered when a driver enters the check point quadrilateral. A second rule is that the driver must always stay in a checkpoint quadrilateral. So the quadrilaterals must cover all (normally) reachable parts of the track.

In Autumn 2013, Wiimm edited about 30 tracks to fix the position jump bugs and to confirm the quadrilateral model. In this phase he detected that all quadrilaterals have to be convex and that concave or other malformed quadrilaterals may lead to position jump bugs again.

This article will now explain the background of the quadrilateral model and how to set up a good check point section.

What is a check point?

Check points basics
red: road
gray: offroad
black: fall down
blue: check points
cyan: frame of quadrilateral
green: see text

A check point is defined in the CKPT section of the KMP file. Technically, a check point (CKPT) is defined as a horizontal line between 2 two-dimensional points and with some attributes (4 bytes; see below). However, each of these lines forms a check point quadrilateral together with its following line. On junctions (last point of a group with more than 1 following group), a check point defines multiple quadrilaterals, one with each following check point.

This quadrilateral model is important to understand the whole concept of check points. For example, take a look at the image on the right. The driving direction is from top to bottom.

CP1 and CP2 together build the first check quadrilateral. To trigger CP1, the player can enter the quadrilateral from 3 sides (green arrows). This is also true for mandatory check points and for the lap counter. It is important that all drivable areas are covered by such quadrilaterals. In the image on the right the quadrilaterals include the complete offroad and also parts of fall down areas. The check quadrilateral in which the player falls down decides which respawn point is used.

After CP2 there is a route split. This is managed by 3 groups: The first one with CP1 and CP2 uses 2 next links to 2 other groups (CP3a+CP4a and CP3b+CP4b). It is clear that the first quadrilaterals behind the junction must overlap. Generally, overlapping quadrilaterals are not problematic as long you create clear routes with only convex quadrilaterals (see below).

Attributes

Each check point defines 4 bytes for 4 attributes:

respawn index: Index into KMP/JGPT for restarting the player if falling down in the related quadrilateral. Incidences to not defined respawn points let the game freeze if activated.
check point type: The type of check point. 0xff defines a normal check point, 0x00 a lap counter and all other values define a mandatory check point (see below).
previous check point: This impact is not fully discovered yet. It is usually the index of the previous check point, or 0xff for the first point of a group.
next check point: The index of the second check point to build the quadrilateral. It is usually the index of the next check point, or 0xff at junctions (last point of group).

Mandatory check point/quadrilateral

The second attribute (a byte values) defines the type of the check point (quadrilateral). A value of 0xff (-1 as signed number) means that it is a normal quadrilateral without a special meaning. Such quadrilaterals can be omitted by the drivers without side effects.

All other types of quadrilaterals (values 0x00–0xfe) are mandatory or key quadrilaterals. Type 0x00 is not only a mandatory check point, it is also the lap counter (see next section). A driver must trigger these check points in ascending order without missing one. If the driver reaches a mandatory quadrilateral and has missed a prior one, Lakitu appears. A track may define multiple check points with the same type to allow alternative ways.

One detail is important: The system detects the missing of a mandatory check point only, if a higher mandatory check point is reached. If for example mandatory check points 0, 1, 2 and 3 are defined and the drivers triggers 1 and 2, there is no need to trigger 3 before reaching the lap counter. So it's a good idea to place the last mandatory check point in the near before the lap counter.

There are other effects of mandatory check points: If a driver leaves the quadrilaterals, the system assumes its position in the last triggered mandatory quadrilateral. This is also important, if falling down, because the respawn point defined by the last triggered mandatory quadrilateral is then used. So it's a good idea to create (fall down) walls, so that drives can't leave the quadrilaterals.

Lap counter

The lap counter is the special mandatory check point with type 0x00. All players start in lap 0. Every time a player enters a lap counter quadrilateral in driving direction, the lap counter is increased by one. When a player reaches lap 4, its race is terminated. When driving backwards, the lap counter is decreased and negative lap numbers are possible. However, the Wii will only display lap numbers between 1 and 3. This behavior can be changed by cheats and code modifications.

The lap counter model of above works fine offline. And offline it is no problem to have multiple lap counters. But online, multiple lap counters force a permanent Position Jump Bug.

The following part is a proofed model to explain the online behaviour of lap counters:

The Wii uses 2 different algorithms for players on the local Wii and players of other Wiis that are connected via network. These foreign players only rarely send position and status records (every 1/3 seconds for a 12-player-game). So the Wii must simulate and estimate the foreign players. Therefore, there is another algorithm. And this algorithm only accepts the very first lap counter to increase the laps.

When the local and a foreign player enter a middle lap counter quadrilateral, the local lap count is increased, but not the foreign. The result is that the local player is counted as first, because he is the only one in the second lap. The real problematic is that all players get items only planned for the first position independent of their real positions.

Convex Quadrilaterals

Use only convex quadrilaterals. Only the green parts are inside a check point.

There is a simple and fast algorithm to find out if a point is interior of a quadrilateral (and of any convex polygon): Find out if the point is on the correct side of each border line. If only one test fails, the point is outside. It is only an assumption that Mario Kart Wii uses this kind of algorithm, but tests and fixed tracks reinforced this assumption.

At the picture on the right you see 3 examples for check point quadrilaterals:

The 2 check point lines of each figure are blue.
The 2 additional quadrilateral borders of each figure are cyan.
The yellow arrows point to the correct line side and normally to the inner side of the quadrilateral.
The green area are the interior points found by the algorithm.
The red area are interior points, that are not found by the algorithm.

And now look at the first figure. It is a clearly defined convex quadrilateral. All interior points are on the correct side of all 4 borders (yellow arrows and green area).

The second figure shows a concave quadrilateral with the result, that parts of the quadrilateral are detected as outside (red). The third figure shows an example, where 2 check point line are crossed. Because of the wrong direction of the right border, all points are outside. If a driver enters a red area, a Position Jump Bug occurs. You can fix both by adding one more check point.

Another error is that 2 corners of the quadrilateral are at the same position or very near. That makes it impossible to calculate a line between the 2 points. Make sure that the points are at least 10 units away.

The summary is that only convex quadrilaterals are usable. All other forms result in Position Jump Bugs.

Groups (Sections)

Note about naming: The classic SZS Modifier calls it sections and the printed indices are one based (but internally zero based). When Wiimm implemented his KMP compiler, he decided to call it groups with zero based indices to avoid naming and numbering conflicts. Some of the newer KMP tools follow this new naming.

In some tracks, a driver can choose different ways at junctions. If the ways are not side by side, the check point routes must follow the way individual.

For this reason, groups are possible. Technically, a group is only a sequence of check points defined by the KMP/CKPH. The advantage of a group is that 6 different other groups can be defined as successor. So a 6 way junction is possible.

At joining points, a new group must be defined. All predecessor groups point to this new group.

KMP setup

In a KMP file, the check points are stored as simple list in the section CKPT. The groups are organized by the KMP section CKPH. Groups and points are referenced by a zero based index.

Each group of CKPH defines:

The index of the first point of CKPT.
The number of points in this group.
6 links to next groups (forward links).
6 links to previous groups (backward links).

If a link is not used, it is set to value 0xff (-1). The previous links should correspondent to the next links. This allows players to drive backwards. Wiimms SZS Tools calculate the previous links automatically.

The points of CKPT also have a previous and next link. Generally, the previous link is set to the index of the previous point and the next link to the next point. But the previous link of the first point of a group and the next link of the last point of a group must be set to 0xff to advise a group lookup. Wiimms SZS Tools can define the links fully automatically, if the parameter @AUTO-NEXT is set to 1.

Respawning

Each check point has a link to a respawn point (first attribute). When a driver falls down within a check quadrilateral, he is respawned at the linked respawn point. If the driver falls outside of any check quadrilateral or falls down after he has missed a mandatory check quadrilateral, the respawn point linked by the last registered mandatory check point or sometimes by the following mandatory check point is used (this is subject of further investigation).

For mandatory check points, it is important that the respawn area lays before the check point or clearly inside the related check point quadrilateral, so that the player enters the check quadrilateral again. Overall, respawn points must be placed that a driver never miss the entrance of mandatory check quadrilateral.

In fact, respawn point are not only points, but areas. See »Respawn Point« for details.

Usual Errors

This section will show you some of the most common errors. Most of them are made because check points were thought to be lines instead of quadrilaterals.

Fixed bug of GCN Rainbow Road. This is a »wkmpt DRAW« export displayed in 3DS Max.

Curves

In the picture on the right you see a typical error found in many (sharp) curves.

On the left side, the track author defined some check point lines, not knowing they together work in quadrilaterals. This leads to the magenta parts of the (red) roads, which are not covered by a check point quadrilateral. As soon as a driver stays in this part, the Wii can't estimate its position, resulting in a Position Jump Bug.

On the right side, this was fixed by defining more check point lines so that the resulting quadrilaterals cover up all parts of the road. It's no problem to create overlapping quadrilaterals as long as they are at least 3 steps away from each other. The best solution is to place mandatory check points (dark blue with octahedrons) somewhere between the overlapping quadrilaterals.

Fixed bug of GBA Rainbow Road. The right yellow circle is constructed for demonstration only.

Wrong distance

In the next example you see 2 more usual errors.

In the left yellow circle, the 6 right points are placed exactly at the same position with the result that the distance between the points is zero. And a zero distance means that a normal can't be calculated. But normals are always used to check, if a point resists in a 2D or 3D area.

In the right yellow circle, 2 check point lines are crossed. That makes a quadrilateral calculation impossible.

Both bugs will resulting in a Position Jump Bug. The right half of the picture shows a fixed set up of the check points. All quadrilaterals are clearly defined and intermediate quadrilaterals have no overlays.

Automatic Bug Detection

Wiimms SZS Tools have a built-in algorithm to detect wrong (not convex) quadrilaterals. This algorithm is used in 2 different ways:

The commands »wkmpt CHECK« and »wszst CHECK« print warnings about malformed quadrilaterals and also, if an enemy or item route point is outside of all check quadrilaterals.
The command »wkmpt DRAW« draws wrong quadrilaterals in red instead of blue.

Links

Wiiki

KMP/CKPT : Definition of the check points.
KMP/CKPH : Definition of the check point groups.
KMP/JGPT : Definition of the respawn points.
wkmpt DRAW : Export KCL and KMP objects as Wavefront OBJ file.
Position Jump Bug.

Wiimms SZS Tools