Vehicle Parts

The aim of this document is to give a detailed breakdown of all supported parts by ZModeler and Midtown Madness 2.

Suffixes
Sample parts list: WHL0_H:m WHL1_H:m BODY_H BODY_M

The suffix is the extention of the part name, the part after the underscore, doesn't include ":m". In the sample we have "H", three times - 2 high wheels and a body, and one instance of "M" - one medium body.

The suffixes refer to the level of detail. The game displays varying levels of detail on parts, depending on the viewing distance. BODY_H being shown when the viewing distance is at it's smallest and BODY_VL at the farthest.

:m/M Flag
The ":m" or ":M" flag exists on almost every part, most commonly on wheels, breakables, turning parts, and headlights not to be confused with hlights. The :m flag defines an object that will have a mtx file. The MTX file defines the origin, center of gravity, minimum, and maximum extent of the object. An object with this flag should also have a .dgbangerdata file.

m/M flag characteristics, there are 3 main things to know about the flag;
 * 1) The m/M flag is case sensitive, are should be treated with care.
 * 2) The flag performs different roles or meanings in ZModeler and Midtown Madness 2.
 * 3) The flag roles vary from part to part.

When first importing or upon creation of a vehicle in ZModeler, if the m/M flag is present, it signifies that the part has a correctly formatted and present geometry/*.mtx file. If the flag is not present when exporting a vehicle to geometry/*.pkg then no *.mtx data will be created for the part.

No flag? If the flag was to be removed, in ZModeler, it represents present axis and positional data of the part, therefore, without the flag it is likely to cause the game to crash or the parts in question to behave incorrectly.

Case sensitivity controls visibility in breakable parts on the vehicle selection screen of Midtown Madness 2. BREAK1_H:m would make the part in question visible in the vehicle selection screen, so therefore, ":M", makes the part invisible in this context.

However this varies from part to part. Brekables become invisible during vehicle selection, with a capitalised M flag, and are visible again in game. The same is not true for fender and wheel objects. Wheels become invisible during vehicle selection, and are still recognised by the game, but not visible during game, nor present. A conventional four wheeled vehicle would be unbalanced due to the missing wheel, and in game causes some issues with acceleration. The same is true for the fender object, but it causes no acceleration issues.

m/M flag not supported by:

BODY SHADOW HLIGHT TLIGHT BLIGHT BOUND

This section is incomplete and the flag is also unsupported by other parts.

Body
Supported parts:

BODY_H BODY_M BODY_L BODY_VL This part supports all suffixes, but not the m/M flag.

BODY parts are obviously the vehicle's body. There are 4 levels of detail.

Compulsory parts:

BODY_H

If this part is not present, your game will crash upon city loading.

Wheels
Supported parts:

WHL0 WHL1 WHL2 WHL3 WHL4 WHL5

This part supports suffixes and the m/M flag. WHL objects also require a support file located in tune/banger/%basename%_WHL#.dgbangerdata, where %basename% is the vehicle's basename value and # represents the part ID number.

WHL parts are the vehicle's wheels.

Wheel numbering: 0 = front left 1 = front right 2 = rear left (1) 3 = rear right (1) 4 = rear left (2) 5 = rear right (2) From this, even numbers are evidently the left side of the vehicle and odd numbers are the right.

Compulsory parts:

WHL0 WHL1 WHL2 WHL3

If at least 4 wheels are not present, your game will crash upon city loading.

Breakables
Supported parts:

BREAK0 BREAK1 BREAK2 BREAK3 BREAK01 BREAK03 BREAK12 BREAK23

This part supports suffixes and the m/M flag. BREAK objects also require a support file located in tune/banger/%basename%_BREAK#.dgbangerdata, where %basename% is the vehicle's basename value and # represents the part ID number.

BREAK parts are the vehicle's breakable parts. The breakables will break when that part of the vehicle has incurred suffient impact.

Some examples of breakable parts are the external mirrors, sidelights, exhaust parts, windows, and hoods or bonnets.

Breakable part numbering: 0 = front left 1 = front right 2 = rear right 3 = rear left 01 = front 03 = left side 12 = right side 23 = rear

The numbering is fairly straight forward for breakables. Imagine the vehicle top down, see image. Starting front the top left of the vehicle, the corners are numbered in a clockwise fashion, starting from 0 - unlike the wheels which are numbered alternatively, from left to right. the side and the rear breakable numbers appear to be random but infact are a combination of the two nearest corners. So BREAK23 comes from it's two nearest neighbours, BREAK2+BREAK3=BREAK23.

Fenders
Supported parts:

FNDR0 FNDR1

This part supports suffixes and the m/M flag. FNDR objects also require a support file located in tune/banger/%basename%_FNDR#.dgbangerdata, where %basename% is the vehicle's basename value and # represents the part ID number.

FNDR parts are the vehicle's fenders. The best example of fenders used in MM2 are on the Panoz Roadster, when the two front wheels turn either left or right, the wheel guards or covers turn with the wheels. Rear fenders do not exsist or are not supported.

On common and conventional road going cars, the FNDR object may seem obsolete, however alternative part ideas include objects such as brake discs and support arms, to help bring some extra quality to modern vehicle products.

Fender part numbering: 0 = front left 1 = front right

Numbering always begins from the front left of the vehicle, and because there are only 2 fender objects, there is no complexity behind the numbers.