Moving Terrain
This page is a part of the Custom Track Tutorial. Back to the main tutorial page.
Introduction
Moving terrain is a feature available in Mario Kart Wii most famously used in Koopa Cape, but also used in several other tracks. Wetland Woods is the first custom track to use moving water collision, proving that moving terrain is recreatable. This page explains how to create that sort of effect. There are three types of moving terrain associated with KCL: moving water (flag 0x0B), moving road (flag 0x15) and rotating road (flag 0x1D). Moving water is controlled by a route, whereas the other two are not.
Moving Water (KCL 0x0B)
Nintendo initially used moving water in Koopa Cape and DS Yoshi Falls as the main gimmick of each track. Moving water consists of three things: KCL, a route and an AREA. Players inside the AREA will follow the associated route when on KCL type 0x0B. Items and other objects are not affected by moving water.
KCL
The first part of making moving water is the KCL. The road or whatever you want to move should be of KCL type 0x0B. Despite being called "moving water", four initially unused variants of this type of KCL are not actually water. Without a route or AREA, this collision does not move players at all. It shares many properties with KCL type 0x16.
The variants you are most likely to use are variant 0x0000 and the unused variants (0x0004, 0x0005, 0x0006, and 0x0007). Variant 0x0000 is used in Koopa Cape's river section and underwater tunnel to provide a route-controlled moving terrain that moves players at a customized speed. These variants conserve the players' momentum caused by the terrain, meaning that once the player is in motion, they will continue to stay in motion upon leaving the KCL for some time, even at a driving km/h of 0. The unused variants appear to be the same as variant 0x0000 except that they do not display water particles and produce a different SFX.
Variant 0x0001 is similar to 0x0000 but its gravitational properties seem to be much stronger; it does not conserve terrain-caused momentum, and it is very difficult to accelerate or decelerate while on it. In Mario Kart Wii, it is only used in Koopa Cape's waterfall at the end of the river. It is advised to only use this variant when players are meant to only drive down a steep, watery slope when on it.
Variant 0x0002 is unique in the way that it uses two AREA settings (more information here) in addition to route settings (more information here). It is used in the final turn of Koopa Cape and in all three waterfalls of DS Yoshi Falls. This variant is used to create moving terrain that follows a route with both a customizable speed and acceleration/deceleration amplifier. Another feature of this variant is that the speed is nullified when using a Star or Mega Mushroom and a different sort of physics is used instead.
It is currently unknown how variant 0x0003 works, but it seems to be similar to variant 0x0001 in a lot of ways. It might be reliant on AREA settings, but not a route(?). It is only used at the end of the cliff where the moving water is on the final turn of Koopa Cape.
AREA
.png)
AREA type 0x03 is used to create a region that allows the player to be affected by a singular moving water route. Upon leaving the AREA, the moving water behavior is reset for the next time the player enters an AREA of type 0x03. For example, when using a multiple-point route, it can be observed that all moving water collision inside the AREA will not move the player until the player enters the route at any point. After entering the route, all moving water collision inside the AREA will attempt to push players in that same specific direction until leaving the AREA or entering another section of the same route, where the direction will once again change. (This is why taking an off-road shortcut in Koopa Cape's river section sometimes causes unusual sideways-moving water behavior for a brief moment.)
With overlapping AREAs of the same priority and of type 0x03, only the first entered AREA will be taken into account. Leaving the first AREA still resets the moving water behavior, even if you are in the second AREA. Depending on the AREA that is entered first, the exact same location can theoretically have multiple different moving water behaviors because only one AREA is taken into consideration at a time.
Using an AREA for Moving Water
First, the AREA point should encompass everything you want to be moving, and everything encompassed will be affected by the route of your choice. See this page for information on AREA placement. The AREA box should also be scaled large enough and rotated if necessary. To be safe, your AREA should be positioned so that the entire player hitbox is always inside when along the route, even while shrunken or in a Mega Mushroom.
AREA of type 0x03 uses a route ID to link the AREA to the route that will affect players. If the AREA has a route ID (set in the AREA entry), the moving terrain will follow the specified route. If it does not have a linked route (0xFF), you will move towards the AREA point itself.
Special AREA Settings for Variant 0x0002
Only when using KCL variant 0x0002 will you need to define two settings in your AREA. The first setting controls an acceleration and deceleration amplifier. The higher this value, the easier it is to speed up and harder it is to slow down, and vice versa. The second setting controls the moving water speed itself. It is advised to check Koopa Cape's or DS Yoshi Fall's KMP as a reference. The route settings are different for this variant in comparison to other variants, so continue reading to learn more.
Route
The route is crucial in determining where your moving water goes, as well as its speed. Nintendo uses two methods in its tracks to create routes: a multiple-point route method and a two-point route method.
Multiple-Point Routes
In Koopa Cape, Nintendo used a multiple-point route for its moving water. This method allows for very customizable directions for moving water, but at the cost of some added limitations on the creator. As stated in the AREA section of this tutorial, your route must be centered on your road and players should not be allowed to drive onto other moving water within the AREA after leaving the route. The ability for players to leave the route and stay within the AREA will cause all moving terrain elsewhere to perpetually move players in the last detected direction, which possibly may not be of your intentions.
A multiple-point route has a radius of approximately 2500un for its points. Therefore, Y-values matter when placing points.
Two-Point Routes
Instead of using multiple-point routes, DS Yoshi Falls uses two-point routes. When using routes with two points, route header setting #1 must be 0 (more info here). The benefit of two-point routes is that they do not rely on exact positioning and filling the entire road with the route. When using a two-point route, moving terrain will 'always' follow the direction of the route. Two-point routes do not have a radius, so large, open spaces can be used without worry. Therefore, it is recommended to use a two-point route as a general default for KCL type 0x0B unless you want a fully fledged-out route that follows a variety of directions, like the river in Koopa Cape.
Route Settings
Routes normally only use the first setting (with the exception of variant 0x0002). This setting controls the speed at which the route moves players. The higher the value, the faster players will go. Too high of values can cause unintended effects such as sideways slipstreaming and inability to drive. As a recommendation, values between 8 and 40 (in hexadecimal) are good.
Special Route Settings for Variant 0x0002
KCL variant 0x0002 uses both route settings, each with a different impact. Route Setting #1 is always 1. (When it is 0, the moving water does not push players at all.) Route Setting #2 uses value 1 to rotate the direction in which the terrain pushes players by 90° clockwise. This is only used on the multiple-point route on the final turn of Koopa Cape. Otherwise, Route Setting #2 is always 0 and travels in the direction of the route like normal.
Moving Road (KCL 0x15)
Moving road is used in Toad's Factory on the conveyor belts and in Coconut Mall on the escalators. There are five objects used in Mario Kart Wii that are used in conjunction with moving road, each with its own behavior. They are: BeltCrossing, BeltEasy, BeltCurveA, escalator, and escalator_group. Each object's purpose is to create a region where the moving road functions to move players and items and, in Nintendo's tracks, to provide a model to visually indicate the moving road. (When making a custom track, you do not necessarily need to make a model for the object since visual indicators can be implemented in another BRRES file. You can just set all materials to "Cull_All" in BrawlBox, if you want.) The escalators from Coconut Mall additionally have KCL files.
Usage in Toad's Factory
BeltCrossing is the first set of conveyor belts in Toad's Factory, BeltEasy is the second set and BeltCurveA is the third set. In Toad's Factory, all three are used on flat ground. While it is possible to implement them on inclines, absurdly steep slopes should not be used or else they become too impossible to drive on. All conveyor belts use a different behavior for players in a Star or Mega Mushroom.
The first two sets of conveyor belts are used to move players and items either eastward or westward, depending on the KCL variant used. With KCL 0x15, BeltCrossing is used with variants 0x0000 (west) and 0x0001 (east), and BeltEasy is used with variants 0x0002 (east) and 0x0003 (west). Players and items on these KCL variants will move in the specified direction at a constant speed until reaching the end of the collision or exiting their designated player/item region. BeltCrossing is slightly faster than BeltEasy.
The third set of conveyor belts (BeltCurveA) is used to move players and items clockwise or counter-clockwise around the object's position. Depending on the KCL variant used, and as defined in the KMP, the moving terrain will switch directions twice. In KCL 0x15, variant 0x0004 is used on roads that initially begin moving clockwise and variant 0x0005 is used on roads that initially begin moving counter-clockwise. The speed at which players and items move depends on how far away from BeltCurveA's position they are. Like the first two belt objects, it has a player region. Items work differently, so keep reading to learn more.
Player Region
The player region is the region around each conveyor belt object in which players are affected by the moving terrain in KCL 0x15. Incidentally, all three objects (BeltCrossing, BeltEasy and BeltCurveA) have a player region of (±25000un,±25000un) from the object's position with unknown height. Player regions are unaffected by rotation and scaling in the KMP (?).
Item Regions
The item region is the region around each conveyor belt object in which items are affected by the moving terrain in the way Nintendo intended it. In actuality, the moving road functions for items in the exact same way as they do for players outside the item region. Even when entering the item region from the outside while affected by the moving road, it acts in the same way as the players do. Inside the item region, newly placed items will enter an altered state in which they become unaffected by gravity and collision and continue to move due east or due west until leaving the item region. Upon leaving the item region, the items are reverted back to default behavior (falling with gravity, becoming affected by walls and roads, etc.).
BeltCurveA's entire player region is also its item region, so Nintendo uses KCL 0x1B with value 0x008 to change items back to their default state upon leaving the third set of conveyor belts in Toad's Factory. Item regions are unaffected by rotation and scaling in the KMP (?).
Here are the following item regions (height unknown) for each object, relative to the object's position:
- BeltCrossing = (0-25000un,±25000un)
- BeltEasy = (±3000un,±25000un)
- BeltCurveA = (±25000un,±25000un)
Recommendation
If you plan to use KCL 0x15 in your track or arena, you may want to tackle the situation differently depending on your case. When using BeltCrossing or BeltEasy, items will move along moving road at an incline (or fall over a cliff) only outside the item region. Inside the item region, items will either clip through the ground or fly into the air after being placed, at least until leaving the item region. As a general rule of thumb, you want to place BeltCrossing or BeltEasy in a position so that items are always outside the item region. This way, items are always affected gravity and other external collision upon leaving the moving road. Remember that BeltCurveA uses KCL 0x1B to change items back to the default state.
Usage in Coconut Mall
Moving road is used in Coconut Mall on the track's five escalators. Four of the escalators make up two escalator_group objects, while one escalator is an escalator object. The object escalator_group consists of two escalators (one with its speed multiplied by -1) and a Pianta (monte_a) that indicates when the escalators are changing. Other than this, it is currently unknown what other differences each object exhibits. Each of these two objects are customizable in the KMP to determine three different speeds (signed) and when to switch from speed 1 to speed 2 to speed 3.
In order to move players with these objects, KCL 0x15 is used in escalator.kcl with variants 0x0000 and 0x0001 (differences currently unknown). The direction (and negative direction) of the moving road can be rotated depending on the rotation in the KMP.
Just like the conveyor belts in Toad's Factory, players and items are affected by the moving road. There is also a hardcoded property used in escalator.kcl that forces players and thrown items to bounce around in frequency to the original escalator model's animation. The negative direction has the capability of causing players to clip through the collision depending on the KCL geometry, so avoid using the negative direction unless you are using it on an incline.
Unfortunately, items do not move along the plane(s) of the collision, which can potentially be difficult to work with. When placed on the moving road, items travel at the same angle as the original Coconut Mall escalators, with the same behavior as being inside the item region of the conveyor belt objects (ignoring gravity and other collision until leaving each escalator's defined region).
The defined region for moving road to exist, as well as the behavior it grants to items placed on the escalator object, is very restrictive in height only. It is currently unknown exactly how large the X and Z regions are, but the Y region works between 0un and +1700un from the object position. For best results, using a Y region between +200un and +1500un from the object position should take into account the hardcoded property properly.
Recommendation
If you are seeking to put an escalator into your track, you might find creating a custom escalator very restrictive to deal with. It is currently recommended to use the escalator object as it appears in Coconut Mall and to make the stairwell around the escalator about the same dimensions as used in Coconut Mall. If you do not care for the customizable speed/direction or the speed/direction change, you may also find that using BeltCrossing or BeltEasy may allow for more freedom during development of your track. For information on these objects, go here.
Usage in Custom Tracks
Plenty of custom tracks have already implemented moving road of KCL type 0x15. For reference, some custom tracks that use BeltEasy, BeltCrossing, BeltCurveA, or escalator in new ways as a form of moving terrain include DS Bowser Castle (Sniki) in the rotating room and spinning bridge, 3DS Bowser's Castle (Wexos & Atlas) and 3DS Rainbow Road (BigOto2) at the rotating cylinders and Escalator Action at its escalators. Please note that these tracks are some of the first to use collision of type 0x15 in completely new ways, so item and player regions may not be utilized optimally.
Rotating Road (KCL 0x1D)
Rotating road is initially only used in Chain Chomp Wheel and is activated with the presence of the casino_roulette object. This type of road is just like ordinary road except that it rotates players and items around the center of the world counter-clockwise when casino_roulette is present. The farther from the world's center, the faster players and items will travel. When casino_roulette is not present, this KCL type will not rotate anything on top of it and can be used as an alternative to KCL types 0x00 and 0x17.
Slot Details
Rotating road and casino_roulette do not function entirely the same outside of arena slot 1.4. As players and items rotate along casino_roulette or rotating collision, their position always continually updates, but only on arena slot 1.4 do their rotation update as well. On any other slot, the direction is not updated, making it similar to BeltCurveA and its respective collision.
KCL
KCL type 0x1D is not the only collision type that will rotate players around the world's center with the presence of casino_roulette. Collision of types 0x06 (only variant 0x0001) and 0x07 are also affected. The purpose of 0x1D and the other rotating KCL flags affected by casino_roulette is so that they can be used in KCL files that are not casino_roulette.kcl. Rotating road, as a result, is redundant when used in casino_roulette.kcl and will not be any noticeably different from non-rotating road, but can still be used for its unique variants if desired.
Regions of Possible Usage
With the presence of casino_roulette, a region of approximately 12000un from the center of the world (height unknown, shape unknown) is created to allow all rotating road collision to function outside of casino_roulette.kcl. Distances farther than 12000un will cause rotating road to act like ordinary road KCL.
All collision rotating as part of casino_roulette.kcl, on the other hand, can extend infinitely farther and still work, but becomes too difficult to drive on starting from approximately 27500un from the world's center.
Behavior
Items placed on rotating road or on casino_roulette.kcl will be put into an altered state, similar to collision of type 0x15. Items will be rotated around the world's center, ignoring just gravity. Items are still affected by other collision, meaning that it is possible for items to travel up slopes and stop at walls. Unlike BeltCurveA, collision of type KCL 0x1B (at least with value 0x008) cannot be used to change items back to the default behavior.
The casino_roulette Object
Nintendo uses casino_roulette as the main gimmick of Chain Chomp Wheel to rotate everything on a roulette around the world's center. The casino_roulette object consists of a rotating model with a simulataneously rotating casino_roulette.kcl file. Be careful when using objects on casino_roulette.kcl since they may not necessarily rotate with the object, let alone collide. Nintendo uses Twanwan as the main hazard of Chain Chomp Wheel, but the collision it rolls around on is actually part of course.kcl, not casino_roulette.kcl.
All collision, regardless of type and variant, will rotate around the center of the world in casino_roulette.kcl. Due to this, it is important to note that all drivable collision in casino_roulette.kcl, regardless of type and variant, will rotate players and items just like KCL type 0x1D does. Therefore, clever usage of this object can allow rotating slippery road or rotating off-road according to the whim of the track creator.
FAQs/Recommendations
If you plan on using casino_roulette in your track, there are a few questions you must ask yourself when developing your track or arena:
Am I using collision of types 0x06, 0x07, or 0x1D anywhere near the center of my track, and do I want them to be rotating players?
In Chain Chomp Wheel, two KCL flags of type 0x06 are defined: one rotates visually and the other does not. Nintendo addressed this problem by making the non-rotating boost panels variant 0x0000, and the rotating variants 0x0001. A similar situation can be observed in the custom track Marble Towers. The track contains a casino_roulette object and a few boost ramps, all near the world's center. Boost panels or ramps that are not intended to rotate the player should be checked and fixed as necessary. A possible workaround for using collision of type 0x07 is to use collision of type 0x06 with value 0x100.
Does my casino_roulette object even need a model or collision?
When using rotating road, you might not even want to use casino_roulette.kcl, or even a rotating casino_roulette model. If this is the case, you can simply edit the files to make the models invisible and the collision non-interactive.
Will my casino_roulette object collide with another part of my track as it rotates?
If you do plan on using a rotating casino_roulette model or collision, you must check your course model, KCL and KMP to ensure everything can work properly as they rotate around the world's center. You don't want to make the main route completely impassable at any given point in time due to how casino_roulette rotates. Also check if CPUs and items can still function as they follow their routes, respawn points do not unfairly drop players in unoptimal locations, etc..
Should I use casino_roulette or BeltCurveA?
Known differences are as follow:
- BeltCurveA can rotate in either direction (and even switch directions) while casino_roulette only rotates counter-clockwise.
- BeltCurveA can be placed anywhere, while casino_roulette is only at the origin of the world.
- The casino_roulette object has a customizable KCL file that rotates with the model.
- The casino_roulette object allows rotation of direction on arena slot 1.4.
- Collision of type KCL 0x1B only seems to work in conjunction with BeltCurveA.
- Items placed on KCL type 0x1D or casino_roulette are affected by external collision, while they are not when placed on KCL type 0x15.
- BeltCurveA has a larger region that affects players/items than casino_roulette, but casino_roulette.kcl can be used to overcome casino_roulette's region.
For more information on BeltCurveA, look here.
Using Objects
Nintendo used KCL to move players and items in a few of its tracks and arenas, but many more tracks use just objects to move players and items around instead. The best example of a track that uses a variety of moving objects, but no moving terrain collision, is Grumble Volcano. The objects VolcanoRock1 and VolcanoPiece are just a couple of the objects that can be used as an alternative way to create moving terrain. Here is a table of objects that can be used in some way as moving terrain:
| Object | .brres | .kcl | .breff/ .breft |
KMP settings | Slot(s) for effects |
s_itembox compatible? |
AREA type 8 compatible? |
Multiple models? |
|---|---|---|---|---|---|---|---|---|
| WLwallGC | ✓ | ✓ | 🗴 | ✓ | — | ✓ | — | low-poly |
| VolcanoRock1 | ✓ | ✓ | 🗴 | ✓ | — | ✓ | ✓ | 2 |
| bulldozer_left | ✓ | ✓ | 🗴 | ✓ | 1.4 | ✓ | — | low-poly |
| bulldozer_right | ✓ | ✓ | 🗴 | ✓ | 1.4 | ✓ | — | low-poly |
| Crane | ✓ | ✓ | 🗴 | ✓ | 1.4 | ✓ | — | low-poly |
| VolcanoPiece | ✓ | ✓[1] | 🗴 | ✓ | 3.4 | ✓ | ✓ | ≥14 |
| TwistedWay | textures | 🗴 | 🗴 | 🗴 | — | ✓ | — | low-poly |
| TownBridgeDSc | ✓ | ✓[1] | 🗴 | ✓ | 6.3 | ✓ | — | 🗴 |
| DKturibashiGCc | textures | 🗴 | 🗴 | 🗴 | — | ✓ | — | 🗴 |
| aurora | textures | 🗴 | 🗴 | 🗴 | — | ✓ | — | 🗴 |
| venice_saku | ✓ | ✓ | 🗴 | ✓ | A1.2 | ✓ | 🗴 | 🗴 |
| casino_roulette | ✓ | ✓ | 🗴 | 🗴 | A1.4 | — | — | low-poly |
| dc_pillar | ✓ | ✓[1] | ✓ | ✓ | — | technical[2] | — | base, shadow |
| dc_sandcone | ✓ | ✓ | ✓ | ✓ | — | — | — | 🗴 |
| venice_hasi | ✓ | ✓[1] | ✓ | ✓ | A1.2 | ✓ | 🗴 | shadow |
| quicksand | textures | 🗴 | ✓ | ✓ | A1.5 | only A1.5 | — | 🗴 |
| bblock | ✓ | ✓[1] | 🗴 | ✓ | — | ✓ | — | 9, technical |
| ami | textures | 🗴 | 🗴 | 🗴 | — | ✓ | — | 🗴 |
| RM_ring1 | ✓ | ✓[1] | 🗴 | ✓ | — | ✓ | — | 3, technical |
For information on how to use BeltCrossing, BeltEasy, BeltCurveA, escalator, and escalator_group, look here.
For more information on editing objects, look here.
Advanced Strategies Using LE-CODE
LE-CODE is a code extension for Mario Kart Wii that gives track creators much more freedom during track creation. Here are some examples of LE-CODE features that might help in altering or creating new collision.
ObjFlow.bin and GeoHitTable*.bin Files
LE-CODE allows tracks to implement track-dependent ObjFlow.bin and GeoHitTable*.bin files. These files control how players, items and objects interact with each other. Combining certain objects with these files might help create a desirable, new sort of collision to work with.
Extended Presence Flags
LE-CODE allows tracks to implement objects on a conditional basis using extended presence flags. In order to create a sort of "conditional collision" (which may or may not be moving), an object with a custom .kcl file can be given an extended presence flag.
Main Tutorials
Introduction –
Textures –
Scale –
Modeling ⇒ Using Blender –
BRRES: CTools
BRRES: BrawlBox –
BRRES: RiiStudio –
Minimap –
Solidity –
KCL: Wiimms Tools –
KMP Editing
Object Editing –
Cameras –
Cannons –
Post-effects –
Videos
Battle Arenas
Battle Arenas –
Enemy routes in battle arenas ⇒ Using Wiimm's Tools –
Coins
Misc. Tutorials
Getting Files –
BrawlBox Tricks –
Animations –
Shadows –
Mipmaps
Custom Effects –
Moving Terrain –
Music –
Ports –
Paint Remakes –
Tutorial Archive
Extended presence flags: Track Tutorial –
LE-CODE Track FAQ
Testing and Reviewing
Testing a Track –
Visual Review –
Track Transformation –
Fixing Errors
Software
3D Tools –
BrawlBox –
CTools Pack –
KMP3D –
KMP Cloud –
KMP Modifier
Lorenzi's KMP Editor –
MagicY –
Material Tool –
Post-Effect Editor –
Wiimms SZS Tools –
Wiimm's Tool Manager
Other
KMP Objects –
Custom Objects –
Model Database –
Tutorial Archive