The POD.INI file is what tells Monster Truck Madness 2 where to find the track and truck POD files you have "mounted" for your game.   You will find the pod.ini file in the mtm2 folder.   For example, here:

C:\Program Files\Microsoft Games\Monster Truck Madness 2\

If you want to add or remove tracks or trucks from the game, this file has to be edited.   Usually, you don't need to concern yourself too much with this because there are many good programs (Podini and PodIt are two favorites) that will help you edit the pod.ini file quickly and easily.   However, there are a few circumstances that cause problems, so it's a good idea to know a thing or two about how this file works.

Firstly, the pod.ini file is a very simple ascii (i.e., txt) file.   It is not a program.   Because it's just a text file, it is easy to edit, and you can open it in any program that can edit text files (for example, notepad).

The picture shows the pod.ini file as it is installed by the game.
 

At this stage of things, there are only a few things to note.

1.) the number at the top matches the number of pod files in the list.   If this number is incorrect, then the game will start behaving strangely.   Fortunately, all the podding programs calculate this number automatically.

2.) the first six pod files are necessary for the game to work and should never be removed.

3.) the remaining thirteen pods are the stock tracks.   If you need to know which pods are for what tracks, please see the mtmg Traxx Help pages.   It is recommended that you do not unmount stock tracks.

4.) the black mark at the bottom of the list is the DOS "end of file" marker.   It sometimes causes problems with pod mounting programs.   The solution is to uncheck it at the first opportunity.

Need to look at it more closely.   Download the real thing here (1k) without the black mark.

Note. Adding a track to the pod.ini list is called "mounting" a track or truck. Some people will call it podding a track or truck but this is technically incorrect because podding is when you "make" an addon game pod.

When you add a track or truck using a pod mounting program, the new pod file is usually just added to the bottom of the list and the number at the top is adjusted so that the count is correct.   For example, like this:
 

While the number at the top of the list must always be correct, the order that the pod files appear in is not as rigid.   For example, after you mount a track or truck using a pod mounting program, you can then open up the pod.ini file in notepad, rearrange the order of the pod files, then save it again.   For example, all three arrangements (one above and two below) will work equally well.
 

The difference between these three arrangements will be evident in the races screen in the game.   The track (BigOval for this example) will appear at the bottom of the list or in the middle or as the first track in the list in the races screen.   But either way, the game and tracks will work just fine.

The maximum number of pod files you can have loaded at one time is:
 

After a clean install	30
After running the patch	99

Pod files do not need to be in the mtm2 folder.   They can be anywhere on the hdd.   But the path directing the game to it must be accurate and complete or the game will not work.   For example:
 

D:\Tracks\track.pod

There can be no spaces in a pod name or in the path to a pod file.

Now, before we can get into some intermediate troubleshooting or some advanced exploitation of this information, we need to know how the game uses the pod.ini file.

Assuming everything is in working order, we launch the game, then goto the races screen and select the track we want to use.   The process is the same for stock or add on tracks.   Now we click the go button and the game starts loading files.   But, oddly, it does not just look in the track's pod for the files it needs.   Instead, it looks through all the pod files, starting with the first one in the list.   In the stock situation, for example, that would be the startup.pod.   If it finds all the files it needs, it loads the track and starts the race.   If it doesn't, it loads what it can find and then moves to the next pod in the list looking for more files.   Again, in the stock situation, that would be the music.pod.   If it still doesn't find everything it needs, it moves to the next pod and the next and the next.   Until, finally, all the files necessary for running the track are loaded into the game and the race can begin.
 

Whether or not you think this is a good way to work, this first come first serve method saves megabytes, even gigabytes of hdd space, since the files common to all tracks can be shared.

The first come first serve file sharing system is the principle behind the podzip program.   The theory goes: if a track uses a stock texture or model, but the game loads the first files that it finds in the list, then it is not necessary for the new track pod to contain the stock files since the game will never use them anyway (it will always use the files from the stock track pods since those are what it will find first).

The exception to this rule is FixMore4 pod which also takes advantage of the first come first serve system.   Though the aim is a little different, the theory is the same: Yeastman has created texture, model and sound files with exactly the same names as the ones used in the stock game.   By placing the fixall pod at the top of the list, the game will search there first for the files it wants.
  Of course, when it finds the Yeastman files (in the fixall.pod), these new files, rather than the ones in the stock pods, are loaded into the game.   All tracks that use these stock files will now run with the Yeastman replacements.   The hope is that the game will look and run in an improved way.

The trouble begins when some nincompoop carelessly or inadvertently creates models and textures that use the same names as models and textures already made for other tracks (whether stock or add on).   Which ever of the conflicting tracks is mounted higher in the list will wreak havoc on the track(s) below it.   This is why it is imperative to use unique file names when you make new models and textures.   You must also rename any models that you edit so that your new model does not conflict with tracks using the old model.

Examples of good and bad names.
 

Bad name choices	Better name choices	Description
black.raw	mybktxtr.raw	my black texture
road.raw	mtrpcrn.raw	my track pavement corner
droad.raw	mtrdcrn.raw	my track dirt corner
billboard.bin	mbb1sgrt.bin	my billboard 1 s'great

To be sure, if you create your models and art using names like "road" or "dirt" you will surely run into conflicts with other/older tracks, or with less imaginative tracks makers.   The best advice here is to personalize your work and try to find a system of naming that will forever be unique to yourself yet open enough to leave room for creating an infinite number of models and art.
 

C'mon, the english language has something like 100,000 common word in the lexicon, and an endless number of acronyms based on them.   And that's only one language.   Unique names are not hard to think up. See the supplement notes for slice60 for some good name ideas.

The last word on pod.ini conflicts.   There is one situation where a track mounted lower in the list can create problems for one above it.   In this scenario, we would have two tracks that use stock textures but,

- The offending (lower) track would have new textures using stock names.
- The affected (higher) track would have removed the stock textures using podzip.
- Both tracks would have to be mounted above the stock pods.

For example, like this:
 

In this situation, the new track would want to use stock textures, but the first ones the game encounters in the list are in the problematic pod created by a careless track maker.

The only solution is to send the offending track to the recycle bin.

I hope this helps.