POD

POD is binary file format used to store uncompressed normally separate files in one big file (similar to a ZIP file with compression turned off). Terminal Reality has used POD files ever since the days of Terminal Velocity. The POD file format used by Terminal Reality for the games Monster Truck Madness 1 & 2 and many others. The POD format is intended to provide a package of related files. For example, one track could be one POD.

Version history
POD1 - The first POD version was used in Terminal Velocity, Hellbender, Fury, Monster Truck Madness 1 & 2, and Cart Precision Racing.

EPD - Fly! introduced the "enhanced" pod file format, identified by the .EPD file extension. This file version includes longer file names, and CRCs per file.

POD2 - Nocturne used POD version 2 files. This version of the POD file allowed for filenames of unlimited length, an audit history, and CRCs per file.

POD3 - POD version 3 has little information available about it. However, plans were to remove the CRC over the entire POD, move the file diectory to the end of the POD, and remove the restriction that the file data appear in the same order as the directory, and plans were to add interdependency records so dependent or related POD files are detected and/or mounted.

Version indentification
If the extension is .EPD, then we have an .EPD POD

If the first four bytes of the file are "POD2" or "POD3" then we have that type of POD.

Otherwise, assume a POD1 (legacy) POD.

Conventions
POD writers should adhere strictly to the POD file format. POD readers should allow any POD which it can reasonably process. For example, POD builders should not insert slack or padding space into the POD in any place that is not specfically permitted. However, if there is slack or padding, then a POD reader should allow this.

POD files are stored in binary. All multi-byte fields are stored in Intel (LSB first) order.

A POD file is divided into sections, ie, the header, the directory, the data area, etc. Unless otherwise stated, each section immediately follows the prior section, with no padding or alignment.

Filenames are not to be considered case sensitive.

Duplicate filenames are not permitted.

A POD writer should output the directory in sorted order. However, a POD reader should never assume that the directory is in any particular order.

All strings must be terminated by '\0' characters.

Data format
Numbers - either signed or unsigned integer values - are stored in the "little endian" format used by all Intel machines. Little endian means that the least significant byte is stored first. The four bytes 0x11 0x22 0x33 0x44 (or short: 11 22 33 44) in a file represent the number 0x44332211, not 0x11223344 as one might expect. Usually programmers read the values by reading 4 bytes directly into a four byte integer variable. That way, no conversion is necessary.

General info
The term #variable_name in this file should be read as "the value stored in the variable called variable_name".

Number of Files
The POD archive starts with a four byte value that represents the number of files stored in the POD.

Comment Space
The first value is followed by 80 bytes that are often set to zero, but may contain any information. PODMate2, for example, uses the space to store the comment "Merged by PODMate2.02, (c)1997 Oliver Pieper" as a zero terminated string, as does TRI sometimes (COCKPIT.POD: "Cockpits are cool").

Directory
After the Comment Space comes the POD's Directory, starting at offset 0x54 (decimal: 84). It is a sequence of #num_files structures, each 40 bytes long and taking this form:

File_palette_name usually is a zero terminated string with the name of a file. In MTM1, however, there can be a special case: If the file is a .RAW file (.RAW files are the MTM texture files), it is followed by a zero byte, followed again by the name of the .ACT palette file that belongs to the .RAW file. According to Guitar Bill, it is not necessary to either read or write the .ACT name from/to PODs. MTM1 seems to default to METALCR2.ACT in both cases.

File_lnth is the length (i.e. the number of bytes) of the stored file. This is always the case, and there's no exception for .RAW files, as I thought before.

File_offset is the starting position within the POD archive where the actual data of the stored file is located. In other words: if file_offset is 0x12345, the the file data starts 0x12345 bytes from the beginning of the POD archive. See the previous paragraph on obtaining the length of the stored file.

File data
After the last Directory entry follows the unmodified data of the files stored in the POD archive. The structure of that part of the POD file can only be determined by evaluating all the information extracted from the POD Directory structure (3.3).

Documented by Olvier Pieper.

Editors
Several POD file editors have been made:


 * C-POD
 * Podview
 * Winpod

Links

 * http://www.viaregio.de/pieper/mtm/pod_file_format.shtml POD file format by Oliver Pieper
 * http://mtm2.com/~mtmg/misc/fileformats/pod.html POD file format by Phineus