This page will contain a number of Frequently Asked Questions about truck building and (hopefully) some answers to them.
Are you insane?
Yep.
When I use BINedit with either solid or textured mode turned on, it displays models in the 3D view all blacked out. Why?
BINedit needs a lot of colours to properly display textured faces - at least 64K. Usually you will need to set your monitor to High Color or True Color - 256 colours are not enough! Note however that the program will work in 256 Color mode, it just won't show the correct colours.
I made a truck but when I try to use it on my computer the garage window in the Driver Check-In is blacked out. If I try to start a race with it selected I get an error.
Your truck .POD is missing an essential file or files. Check that you didn't leave out one or more files (especially model and texture files) out of your .LST when you made the .POD.
Same as above except that the truck works for me but not for one or more other people.
Again, check that all the files for the truck are in the .POD and that you didn't leave any out. Sometimes the game will delve into your other folders (ART, MODELS etc) to find the files it needs to run the truck, but when it is used on another computer that computer will not be able to find those files.
I checked the files and they're all there, what else could be wrong?
If you PodZipped or otherwise removed the stock MTM2 files from the .POD, but you or anyone else doesn't have their stock MTM2 .PODs mounted (especially Truck2.pod), the game will be unable to find the stock files and the truck won't work. To correct this either put those stock files in the .POD or remount your stock .PODs.
My truck works but it's paint isn't right, it's either the wrong colours or in black and white.
Check that your .POD file isn't missing any .ACT files. These files contain the colours of the .RAW files, so if they are missing the .RAW will be displayed in black and white. If the files are in the .POD and/or the truck's paint is in colour but those colours are very wrong, check that you haven't made an alteration to the .RAWs (especially adding a new colour) without saving the .ACT. As the .ACT stores the colours of the texture file, if the wrong .ACT is loaded for the wrong .RAW then the colours will not appear correctly.
The truck I made looks weird in the game (wrong paint or body shape), nothing like how I made it. Or, I just mounted a new truck and now it or one of my other trucks looks weird.
This is most probably a file conflict. If the game finds two (or more) files with the same name, it will use the first one it finds and ignore any further files with the same name.
If your truck's paint doesn't look right, you probably have a texture file conflict, where the filenames of your texture files and of some other truck's texture files have the same name. The game sees one texture file, loads it, then assumes that all the other texture files with the same name are the same. This means that when it loads your truck, it is applying the wrong texture file to it, hence the paint looking funny.
If your truck's body (or wheels, axles etc) looks totally wrong, this is probably a model file conflict: one model file has the same name as another, and again the game loads the first ones it finds and ignores the rest. This means that a truck is loaded with the wrong body! However, and this is where it gets really weird, the game sometimes still loads the correct texture files so the truck will be displayed with the right paint (although maybe not mapped correctly) on the wrong model.
The MTM File Searcher or BIN Texture Replacer program gives me an error about the file being larger than 64,000 bytes when I try to use it on a .BIN file, what's that all about?
These MDMRE programs have a limit on the size of the files that they can process (64Kb). Remember that these programs were written for MTM1, so people didn't have as fast machines as today and, critically, didn't make really complex .BIN models. There was no need to process a .BIN file larger than 64Kb. Unfortunately nowadays we have the ability and the programs to make really complex .BIN models whose file size often exceeds this limit by at large margain. To get around this you have to plan how you build a truck, so if you want to use the BIN Texture Replacer on a certain part, the .BIN model is not too big to do so (one reason why I save all my process .BINs seperately before putting them on the final truck, as I may want to use it for something else). If you want to use the BIN Texture Replacer on an existing model that is too big, you will need to use BINedit to delete part of it to reduce the file size. A neat trick is to delete half of the model and save what's left as, say, model1.bin, then reopen the orginal model and delete the other half and save as model2.bin. This should cut the file size in half, allowing you to use the BIN Texture Replacer program on each half and then put the two halves back together again.
Tracked2 won't run on my computer the way you describe, I can't even get it to run in a DOS-box under Windows.
There's not much you can do about this. Depending on your computer's hardware and software, Tracked2 *may* let you run it under Windows and let you flip between programs using Alt+Tab, or it *may* decide to run in a very dictatorial DOS mode. It just seems to run differently on different machines.
I can run Tracked2 under Windows, but I can't take screenshots like the ones you've got. What sort of black magic is this?
At first I thought this was a video card issue that prevented people taking screenshots, but I've also stumbled across another possibility. Because Tracked2 works off MTM2's game engine and settings, if you have your game set on the high-res (640x480 200MHz) mode, Tracked2 will run in the same high-res mode. You will notice that most of the screenshots in this site have been taken in a low-res mode, because I usually have my game in a low-res (either the 166MHz or 133MHz) mode, because my computer's a bit old. I can take screenshots with it in these lower-res modes, but when I put the game in high-res and opened Tracked2, I found I was unable to take screenshots - it just refused to do it.
So, if you have your game in high-res and can't take screenshots in Tracked2, try reducing the resolution mode in the game and then reopen Tracked2. If it still doesn't let you take screenshots, it's probably a video card problem.
I tried driving a new truck in the game, when the track suddenly flooded with water!
This is caused by having unused vertices on the .BIN model of the truck. It is very important to have no unused vertices on a truck model, otherwise strange things will happen in the game! For this I turn to an example:
Here, Malibu350 tried driving an early version of Slick714's Wild Thang replica, only to find that whenever you got within 30 feet of water, the "Noah phenomenon" kicked in.
This weird bug seems to be caused by certain types of 3D-accelerator hardware when a truck whose body model has unused vertices on it gets near water. There are a number of strange things that can happen, but the one that is immediately obvious is when it causes the water to rise with the truck and floods the entire track! The obvious solution is to make sure you use BINedit's "Delete All Unused Vertices" function on all .BIN models. Failing that, turning 'water effects' off in the graphics options will definately solve it.
The wheels of my truck aren't even on the ground - they're sitting in the back of the bed. What the heck is this?...
This one had a lot of people stumped for a long while - sometimes you'd get a truck, but instead of having all four wheels planted squarely on the ground where they should be, some or all of them are sitting up on the back. Obviously, you can't drive a truck with a wheel configuration like this.
According to enocell (and goodness knows how he found this out), this error is caused by the following two lines in the .TRK file:
axlebarOffset
0.742188,-3.250000,-0.062500
driveshaftPos
0.000000,-2.550000,-0.062500
These are the lines that specify the coordinates of the axlebars and driveshaft of the truck, respectively. Enocell says that a truck which is for the older version of MTM2 (the older version was warez, it had a different version number than the "real" MTM2) won't have these lines in it's .TRK file. If you try to use a truck with a .TRK file like this in "real" MTM2, the wheels will end up in the back of the bed. So all you need to do to fix it is open up the .TRK and add in the lines (copy them from another truck, or specify the axlebar and driveshaft positions yourself).
I'd like to add my own experience to this: it seems that any sort of incorrect data in these particular lines will shove your wheels up behind your cab. For example, the pic above shows a truck that I'd been messing around with (the Ford race truck from 4x4Evo, converted by ZOtm_BigDOGGe) - I'd made some changes, and then when I went into the game found the rear wheels sitting on top of the truck's bed. I eventually discovered that I'd made a typo in the .TRK file:
axlebarOffset
1.199219,- 2.200000,-0.121094
driveshaftPos
0.000000,-1.500000,-0.121094
Can't see what's wrong? I'll point it out: there is a space between the minus sign ('-') and the coordinate of the second axlebar offset coordinate. Pretty amazing that one little thing like that can have such a profound effect, eh? Once I'd found the cause of the problem, all I had to do to fix it was delete the space, and everything worked properly again.
I've been working on a truck and when I go to test it in the game, some of the parts (including shocks and frame) don't appear on the truck when you see it in the Driver Check-In. Also, the same thing happens in racing; you can't see those same parts in Views 3 and 4, but you can see them in the other views...
This makes me think that maybe you've made more than one body model for the truck (perhaps a development model), and the game is using it at points.
MTM2 uses three body models for each truck, for example for Bigfoot you have Bigfoot.bin, Bigfoot1.bin and Bigfoot0.bin. In a nutshell these different models have different levels of detail: Bigfoot.bin is high-detail, Bigfoot1.bin is medium and Bigfoot0.bin is low detail. While you're playing, the game will switch between these models - when you're close enough to see all the detail, it will use the high-detail model, but when the truck is far away you won't see the detail, so it uses one of the lower detailed models instead. This improves game performance, by using detailed (and therefore, more laggy) models only when necessary (although you don't have to build the med and low detail models for your own trucks).
Now perhaps what you've done is made a model of your truck without the frame, and saved it with the name truck0.bin or truck1.bin. Then you worked on it some more (added a frame) and produced truck.bin. But when you built the .POD, the truck0/1.bin model was included (perhaps you're using Tracked2 to pod your trucks? Hey, I'm a theorist OK?). Then you get into the game, and it sees a .bin model with a 0 or a 1 after the filename, and decides to use it for when the truck is far away (why shouldn't it? that's how it was programmed).
The result is that, close up, you see your truck as it should appear, with all the added parts (frame and so forth). But when the truck gets a distance away (view 3 or 4, or in the Driver Check-In), the game reverts to using truck0/1.bin - which doesn't have the frame. So you see the truck with the frame when it's close, but as soon as it gets a little way away, *poof* the frame disappears.
So check whether you haven't got a .bin model in there that the game is using as a med- or low-detail model. I remember one case where a guy had a truck that turned into Bear Foot when it moved away - one of the Bearfoot.bin models had been saved as the same filename as his truck, with a 0/1 after it...