A KMP file contains information about how the course is played, such as start positions and check points. A variant on the KMP (KartMaP) format (Nitro KartMap) has been used in Mario Kart DS.

This article describes the Mario Kart Wii KMP format. For other formats, see KMP (File Format).

Header

A KMP file starts with the following header.

File header of a KMP file
Offset	Type	Description
0x00	Char[4]	File magic. Always RKMD (Revolution Kart Mapping Data) in ASCII.
0x04	UInt32	Length of the file in bytes.
0x08	UInt16	N = Number of sections in the file.
0x0A	UInt16	Header size in bytes.
0x0C	UInt32	Version number of the file. The final game format uses 0x9D8. loser_demo uses 0x9CE, draw_demo uses 0x910, old_mario_gc_hayasi and old_mario_gc_yabuki uses 0x640. old_mario_gc_narita is special as it doesn't contain a version number, the offsets are stored at 0x0C. This is the earliest version of a KMP file and was presumably the first ever KMP test. The ENPT entries are just an array of 3D float vectors which defines the points and ENPH doesn't exist. All these older versions of GCN Mario Circuit are missing many sections.
0x10	UInt32[N]	N section offsets. The type of each section can be detected by analysing the first 4 bytes of the section; it's always the section name. The offsets are relative to the end of this header.
N * 0x04 + 0x10		End of this header

Sections

The file consists of a series of sections, each describing a different aspect of the course. Each section has a header and entries. The header structure is equal for all sections, with one exception. Before version 0x726, KTPT only consisted of a magic, and then there is only one KTPT entry. This was most likely changed because battle arenas need multiple start points.

Section header for all KMP sections
Offset	Type	Description
0x00	Char[4]	The section magic in ASCII.
0x04	UInt16	Number of entries. For KTPT with version less than 0x726, the start position starts directly here.
0x06	UInt16	Additional value. POTI stores the total number of points for all routes. CAME store different values (see CAME section for details). For all other sections the value is 0 (padding).
0x08	End of header

KTPT

The KTPT (kart point) section describes kart points; the starting positions of racers. Each entry has the following structure:

Offset	Type	Description
0x00	Float[3]	A 3D position vector of the start position.
0x0C	Float[3]	A 3D rotation vector of the start position.
If version > 0x640
0x18	Int16	Player index. For races, the first entry is used to define a start area, independent of its value (usually set to 0xFFFF).
0x1A	UInt16	Padding.
Else
0x18	SByte	Player index.
0x19	Byte[3]	Padding.

ENPT

The ENPT (enemy point) section describes enemy points; the routes of CPU racers. The CPU racers attempt to follow the path described by each group of points (as determined by ENPH). More than 0xFF (255) entries will force a console freeze while loading the track. Each entry is a 0x14 byte structure as follows:

Offset	Type	Description
0x00	Float[3]	A 3D position vector of the enemy position.
0x0C	Float	Controls much the enemies leave the direct point-to-point line to the left and right side.
0x10	Byte	Point setting 1. Always 0 in Nintendo tracks.
0x11	Byte	Point setting 2.
0x12	Byte	Point setting 3.
0x13	Byte	Point setting 4.

ENPH

The ENPH (enemy path) section describes enemy points grouping; how the routes of cpu racers link together. Each entry is a 0x10 byte structure as follows (same structure as ITPH and CKPH):

Offset	Type	Description
0x00	Byte	Point start. The index of the first ENPT entry in this group.
0x01	Byte	Point length. The number of ENPT entries in this group.
0x02	Byte[6]	Previous groups. The indices of up to 6 the previous ENPH groups entries may have followed. Unneeded slots are set to value 0xFF. Theses values are used if a driver drives back or is respawned at an position before falling down.
0x08	Byte[6]	Next groups. The indices of up to 6 next ENPH group entries to follow. Unneeded slots are set to value 0xFF. Each driver uses one route randomly, but a short cut item can be set as condition. To increase the probability of one route, enter the section index more than once.
0x0E	Byte	Always 0 in racing tracks. Battle arenas use values between 0 and 7, but >0 only for dispatch points (see note below). The meaning is unknown yet.
0x0F	Byte	Always 0 in racing tracks. Battle arenas use values 0x00, 0x40, 0x80 and 0xC0, but >0 only for dispatch points (see note below). The meaning is unknown yet.

Note: Battle arenas have dispatch points. A dispatch point is an enemy route with exact 1 point. Only dispatch points use values other than zero at offsets 0x0E and 0x0F. The PREV and NEXT links of a standard route points usually to a dispatch point, which have multiple NEXT links to both ends of other standard routes.

ITPT

The ITPT (item point) section describes item points; the routes of items such as red shells. The items attempt to follow the path described by each group of points (as determined by ITPH). More than 0xFF (255) entries will force a console freeze while loading the track. Each entry is a 0x14 byte structure as follows:

Offset	Type	Description
0x00	Float[3]	A 3D position vector of the item position.
0x0C	Float	The range which the bullet bill can be controlled. Factor 1 allows about 10 units left and right movement.
0x10	UInt16	Point settings 1.
0x12	UInt16	Point settings 2.

ITPH

The ITPH (item path) section describes item point grouping; how the routes of items link together. Each entry is a 0x10 byte structure as follows (same structure as ENPH and CKPH):

Offset	Type	Description
0x00	Byte	Point start. The index of the first ITPT entry in this group.
0x01	Byte	Point length. The number of ITPT entries in this group.
0x02	Byte[6]	Previous groups. The indicies of up to 6 the previous ITPH groups entries may have followed. Unneeded slots are set to value 0xFF. Theses values are used if a driver drives back or is respawned at an position before falling down.
0x08	Byte[6]	Next groups. The indicies of up to 6 next ITPH group entries to follow. Unneeded slots are set to value 0xFF. The first link is the standard route. The other links are only used, if a driver enters the route or if a red shell has already selected a driver.
0x0E	UInt16	Unknown. Only seen as 0.

CKPT

The CKPT (checkpoint) section describes check points; the routes players must follow to count laps. The racers must follow the path described by each group of points (as determined by CKPH). More than 0xFF (255) entries are possible, if the last group begins at index ≤254. But it is not recommended, because Lakitu appears. Each entry is a 0x14 byte structure as follows:

Offset	Type	Description
0x00	Float[2]	A 2D position vector (X and Z coordinate) of the left point of the check point line.
0x08	Float[2]	A 2D position vector (X and Z coordinate) of the right point of the check point line.
0x10	Byte	Respawn index. This is a zero based index link into the JGPT section to respawn players at once they have entered this checkpoint. For the lap count trigger and for the key check points it is important, that the respawn point is before the check point.
0x11	Byte	Checkpoint type.
0x12	Byte	Previous check point in this group's sequence. The ID is absolute. 0xFF for the first point of the group.
0x13	Byte	Next check point in this group's sequence. The ID is absolute. 0xFF for the last point of the group. The check point area is a quadrilateral created by the 2 points of the current check point and the 2 points of the next check point. For end of groups, all by CKPH linked points are used to create multiple check point areas. A check point is triggered, if a player enters (one of) this quadrilateral.

Checkpoints are separated in 3 type classes:

Lap count trigger (type 0x00): When passed in right direction it increases the lap count, if you pass in reverse direction it decreases the lap count. All players start in lap 0 and after passing the line in lap 1. The shown lap number is the maximal reached one and never smaller than 1. If 2 or more lap counters exist, the track has an online positioning bug: Each player is counted as position 1 after crossing any lap counter with the effect of bad items.
Key checkpoint (types 0x01 – 0xFE): If you cross 01 you need to follow all in order before lap count trigger works. Used to prevent ultra shortcuts. These kind of check points is also relevant for respawning if falling down far away from other check points. A good idea is to place a key check point directly before and another behind the lap count trigger.
Normal checkpoint (type 0xFF): Used for setting respawns and checking in which position you are.

CKPH

The CKPH (checkpath) section describes check point grouping; how the routes of check points link together. Each entry is a 0x10 byte structure as follows (same structure as ENPH and ITPH):

Offset	Type	Description
0x00	Byte	Point start. The index of the first CKPT entry in this group.
0x01	Byte	Point length. The number of CKPT entries in this group.
0x02	Byte[6]	Previous groups. The indicies of up to 6 the previous CKPH groups entries may have followed. Unneeded slots are set to value 0xFF.
0x08	Byte[6]	Next groups. The indicies of up to 6 next CKPH group entries to follow. Unneeded slots are set to value 0xFF.
0x0E	UInt16	Unknown. Only seen as 0.

GOBJ

The GOBJ (geography object) section describes objects; things on the course such as item boxes, pipes and also control objects such as sound triggers. Each entry is a 0x3C byte structure as follows:

Offset	Type	Description
0x00	UInt16	Object ID to identify the Object.
0x02	UInt16	Unknown. Only seen as 0.
0x04	Float[3]	A 3D position vector of the object.
0x10	Float[3]	A 3D rotation vector of the object's rotation in degree.
0x1C	Float[3]	A 3D scale vector of the object's scale. Value 1.0 is the neutral scale.
0x28	UInt16	Route used by the object. This is index link into the POTI section. The value 0xFFFF means "no route".
0x2A	UInt16[8]	Up to 8 object specific settings.
0x3A	UInt16	Presence flag. Bit flag that sets whether an object shows up in a specific game mode. xxxx xxxx xxxx xABC: A: 3 or 4 player offline. B: 2 players online and offline. C: Single player online and offline, and time trails.

Each object has a origin. The origin is a well defined point. If it is placed directly on the ground, the position of the object is perfect. For example the item box has its origin about 50 units below the lowest visible point. The positioning of objects is done in this order:

First a object is scaled around the origin. For some animated objects like the item box, the scale factors are ignored.
Then the object is rotated. The rotation is done in three steps. For some animated objects the rotation values are ignored.
1. Right-handed rotation around the X-axis using the X-coordinate of the 3D vector.
2. Right-handed rotation around the Y-axis using the Y-coordinate of the 3D vector.
3. Right-handed rotation around the Z-axis using the Z-coordinate of the 3D vector.
As last operation the object is shifted to the position (the origin is set to the position coordinates). For some objects with a route, the start position is the first (or indexed) point of the route.

POTI

The POTI (point information) section describes routes; these are routes for many things including cameras and objects. Each entry is a 0x04 byte structure as follows, which is followed by a 0x10 byte structures:

Offset	Type	Description
0x00	UInt16	Number of points in the route.
0x02	Byte	Route setting 1, 0 or 1 in Nintendo's tracks. 0: Object or camera goes directly from point to point with a hard direction change. 1: Enables a smooth motion.
0x03	Byte	Route setting 2, 0 or 1 in Nintendo's tracks. 0: Use route cyclic (go to first point after leaving last point). 1: Use route forward, then backward, then forward and so on.

Route Point

Each route point has the following structure:

Offset	Type	Description
0x00	Float[3]	A 3D position vector of the route position.
0x0C	UInt16	Route point settings. If used for speed or time, the value is based of 1/60s.
0x0E	UInt16	Additional setting, depend on the object.

AREA

The AREA (area) section describes areas; used to determine which camera to use for example. The size is 5000 for both the positive and negative sides of the X and the Z axes, and 10000 for only the positive side of the Y axis. Each entry has the following structure:

Offset	Type	Description
0x00	Byte	Area shape. 0 = box, 1 = cylinder.
0x01	Byte	Area type. Values 0 – 9.
0x02	Byte	CAME index. The camera which is linked to this area.
0x03	Byte	Priority value. A higher number means a higher priority to choose which area activates if multiple areas intersected.
0x04	Float[3]	A 3D position vector of the area.
0x10	Float[3]	A 3D rotation vector of the area's rotation.
0x1C	Float[3]	A 3D scale vector of the area's scale.
0x28	UInt16	AREA setting 1. Used by type 2, 3, 8 and 9.
0x2A	UInt16	AREA setting 2. Used by type 3.
If version > 0x640
0x2C	Byte	Route ID used by type 3.
0x2D	Byte	Enemy point ID. This value is used by type 4.
0x2E	UInt16	Padding? Always 0.

CAME

The CAME (camera) section describes cameras; used to determine cameras for starting routes, time trial pans, etc. The byte at offset 0x06 in the section header is the index of the first camera to use in the opening pan around the track. The byte value at offset 0x07 in the section header is the first camera used in the videos on the track selection menu of the track. This value is ignored, as the videos have already been generated and stored. Each entry has the following structure:

Offset	Type	Official Name	Description
0x00	Byte	camType	Camera type.
0x01	Byte	nextCamera	Next camera entry index. Value 0xFF means none.
0x02	Byte	?	Unknown. Only seen as 0.
0x03	Byte	pathID	Route used by the camera. This is index link into the POTI section. The value 0xFF means no route.
0x04	UInt16	pathSpd	Velocity of the camera point in units per 100/60 sec (=distance/1.67 sec).
0x06	UInt16	fovySpd	Velocity of zooming in units per 100/60 sec (=units/1.67 sec).
0x08	UInt16	atSpd	Velocity of the view point in distance per 100/60 sec (=distance/1.67 sec).
0x0A	Byte	?	Unknown. Only seen as 0.
0x0B	Byte	?	Unknown. Only seen as 0.
0x0C	Float[3]	pos	A 3D position vector of the camera.
0x18	Float[3]	dir	A rotation 3D vector. Almost always 0,0,0.
0x24	Float	fovy	Zoom start. The angle of view (field of view). Angles >180 create curious effects.
0x28	Float	fovy2	Zoom end. The camera changes the zoom to this value. Offset 0x06 (Velocity) controls the speed of zooming.
0x2C	Float[3]	at	Start vector of the view point (type 5) or the relative camera position (type 3).
0x38	Float[3]	at2	Destination vector of the view point.
If version > 0x640
0x44	Float	camTime	The time how long this Camera is active, in frames. Only used for intro cameras.

JGPT

The JGPT (jugem point) section describes Jugem points; the respawn positions. The index is relevant for the link of the CKPT section. Each entry is a 0x1C byte structure as follows:

Offset	Type	Description
0x00	Float[3]	A 3D position vector of the respawn position.
0x0C	Float[3]	A 3D rotation vector to define the direction for the players.
0x18	UInt16	ID of this respawn position. For all Nintendo tracks the value is set to the index.
0x1A	Int16	Range.

CNPT

The CNPT (cannon point) section describes cannon points; the cannon target positions. Each entry is a 0x1C byte structure as follows:

Offset	Type	Description
0x00	Float[3]	A 3D destination of the cannon. This point defines a destination tangent or border of a ball around the cannon, which is the landing zone.
0x0C	Float[3]	A 3D angle vector of the direction to release players from the cannon in. The second value (Y-rotation from cannon start point) is the most important value, because it declares the shooting direction. The players flight in the entered direction until they reach the defined tangent.
0x18	UInt16	ID of this cannon position.
0x1A	Int16	Shoot effect. 0xFFFF = straight, 0x0001 = curved, 0x0002 = curved AND slow, 0x0003 = slow.

MSPT

The MSPT (mission success point) section describes end positions. After battles and competitions have ended the players are placed on this point(s). Each entry is a 0x1C byte structure as follows:

Offset	Type	Description
0x00	Float[3]	A 3D position vector of this point.
0x0C	Float[3]	A 3D angle vector of this point.
0x18	UInt16	ID of this entry. For all Nintendo tracks the value is set to the index.
0x1A	UInt16	Unknown.

For battle arenas always 4 records are defined.

STGI

The STGI (stage info) section describes stage information; information about the course. Each entry has the following structure:

Offset	Type	Official Name	Description
0x00	Byte	totalLap	Lap count. Always 03 in Nintendo tracks. This byte was used in early development and is no longer in use, however it is still set correctly for all race track (03) and competitions with different lap count. There is a cheat code which makes the game use this value as lap count in normal races.
0x01	Byte	corner	Pole position when starting a race. 0 = left, 1 = right.
0x02	Byte	startPos	Player distance when starting. This defines how close together all players are when starting a race. 0 = Normal, 1 = Narrow.
0x03	Byte	flareTobi	0x01 to enable lens flare flashing. (Tobi is japanese for "jump").
0x04	UInt32	flareColor	Flare color, in XXRRGGBB format. Always 0xE6E6E6 or 0xFFFFFF in Nintendo tracks. This is the lighting color that covers the screen by the lensFX object in RGBA format.
If version >= 2320
0x08	Byte	?	Flare alpha??. Always 50 or 70 in Nintendo tracks. If the version is not met, this field will be read as 75.
0x09	Byte[3]	-	Always 0 in Nintendo tracks, most likely padding. The two last bytes of this field, is used as the two first bytes of a float value, for the speed modifier cheat code.

Tools

The following tools can handle KMP files:

KMP (File Format)/Mario Kart Wii

Contents

Header

Sections

KTPT

ENPT

ENPH

ITPT

ITPH

CKPT

CKPH

GOBJ

POTI

Route Point

AREA

CAME

JGPT

CNPT

MSPT

STGI

Tools

Navigation menu

Page actions

Page actions

Personal tools

Navigation

Search

Tools