PMC Editing Wiki

User Tools

Site Tools

Trace: • terrain-processor • terrain-processor • animations • lod
ofp:file_formats:pbo

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
ofp:file_formats:pbo [2007/07/09 01:18] – created pbo initial page snakemanofp:file_formats:pbo [2024/07/31 12:51] (current) – links added. snakeman
Line 1: Line 1:
-====== PBO File Format ======+====== OFP PBO File Format ====== 
 + 
 +[[https://www.pmctactical.org/forum/viewforum.php?f=43|OFP Forum]], [[:ofp|OFP Home]], [[ofp:file_formats|OFP File Formats]], [[ofp:tools|OFP Tools]], [[ofp:missions|OFP Missions]], [[ofp:modeling|OFP 3D Modeling]], [[ofp:terrain|OFP Terrain]] 
 + 
 +**Operation Flashpoint (OFP)** aka ArmA: Cold War Assault (CWA)
  
 PBO file structure and packing method PBO file structure and packing method
Line 5: Line 9:
 ====== Introduction ====== ====== Introduction ======
  
-A pbo file originally meant 'packed bank of files'. Through use however, it has come to represent a single 'package' to achieve a result. Such as a mission, such as, an addon. +A pbo file originally meant 'packed bank of files'. Through use however, it has come to represent a single 'package' to achieve a result. Such as a mission, such as, an addon.
  
 A **.pbo** file is the output produced by the Mission Editor when 'exporting' and contains nothing more (and nothing less) than the content of all the files and folders making up a mission or campaign, or addon. It is a single file representation of a folder tree. The key to grasp is that anything you uniquely make in a folder, such as a mission, such as a campaign, such as an addon, can be conveniently packaged into a single file, called, a **pbo**. A **.pbo** file is the output produced by the Mission Editor when 'exporting' and contains nothing more (and nothing less) than the content of all the files and folders making up a mission or campaign, or addon. It is a single file representation of a folder tree. The key to grasp is that anything you uniquely make in a folder, such as a mission, such as a campaign, such as an addon, can be conveniently packaged into a single file, called, a **pbo**.
Line 28: Line 32:
   - a checksum (elite) or a signature key (ArmA)   - a checksum (elite) or a signature key (ArmA)
  
-The header defines each file contained in the pbo, its size, date, name, whether it's compressed, and where it 'is' in the following data block. __Every__ file, even zero length ones, are recorded in the header and each is referred to as an 'entry'. Entries, and consequently the 'file' they refer to, are contiguous. +The header defines each file contained in the pbo, its size, date, name, whether it's compressed, and where it 'is' in the following data block. __Every__ file, even zero length ones, are recorded in the header and each is referred to as an 'entry'. Entries, and consequently the 'file' they refer to, are contiguous.
  
 However, note that there is no provision for, and no ability to, store empty folders. Folders as such are indicated simply by being part of the filename. There are no, folder entries, and consequently, empty folders, cannot be included in a pbo because there is no filename associated with them. Put another way, an empty folder, if it could be stored (and it can't), would appear to be an empty filename when dePbo'd. However, note that there is no provision for, and no ability to, store empty folders. Folders as such are indicated simply by being part of the filename. There are no, folder entries, and consequently, empty folders, cannot be included in a pbo because there is no filename associated with them. Put another way, an empty folder, if it could be stored (and it can't), would appear to be an empty filename when dePbo'd.
Line 43: Line 47:
   Asciiz  filename; //a zero terminated string defining the path and filename,   Asciiz  filename; //a zero terminated string defining the path and filename,
                     //         ''relative to the name of this pbo''.                     //         ''relative to the name of this pbo''.
-                    //Zero length filenames ('\0') indicate first (optional), or last (non optional) entry in header.  +                    //Zero length filenames ('\0') indicate first (optional), or last (non optional) entry in header. 
-                    //  Other fields in the last entry are filled by zero bytes. +                    //  Other fields in the last entry are filled by zero bytes.
    .    .
   ulong   PackingMethod; //0x00000000 uncompressed   ulong   PackingMethod; //0x00000000 uncompressed
Line 50: Line 54:
                          //0x56657273 Product Entry (resistance/elite/arma)                          //0x56657273 Product Entry (resistance/elite/arma)
   ulong   OriginalSize;  // Unpacked: 0 or same value as the DataSize   ulong   OriginalSize;  // Unpacked: 0 or same value as the DataSize
-                         // Packed: Size of file after unpacking. +                         // Packed: Size of file after unpacking.
                          // This value is needed for byte boundary unpacking                          // This value is needed for byte boundary unpacking
                          // since unpacking itself can lead to bleeding of up                          // since unpacking itself can lead to bleeding of up
Line 56: Line 60:
   ulong   Reserved;   ulong   Reserved;
   ulong   TimeStamp;     // meant to be the unix filetime of Jan 1 1970 +, but often 0   ulong   TimeStamp;     // meant to be the unix filetime of Jan 1 1970 +, but often 0
-  ulong   DataSize;      // The size in the data block. +  ulong   DataSize;      // The size in the data block.
                          // This is also the file size when **not** packed                          // This is also the file size when **not** packed
  };  };
Line 70: Line 74:
   - End of header   - End of header
  
-An end of header is (of course) mandatory. It is normally indicated by all other entries also being zero in the struct. However, a sometimes seen case is a 'signature' of 0x43707273 in the compression method for the pbo overall. An indication, that some, none, or all, of the pbo is compressed. Somewhat useless. +An end of header is (of course) mandatory. It is normally indicated by all other entries also being zero in the struct. However, a sometimes seen case is a 'signature' of 0x43707273 in the compression method for the pbo overall. An indication, that some, none, or all, of the pbo is compressed. Somewhat useless.
  
 The truth of the matter is that it doesn't matter muchly. Detection of the end of header, and, when applied, detection of a start of header, is indicated by __no file name__. The content of these entries is immaterial, the engine makes no use of them. However, certain 3rd party addon makers rely on the fact that *most* pbo extraction tools expect fields to be zero (even though they don't matter). As such, this prevents _some_ pbo's from being extracted by those tools. The truth of the matter is that it doesn't matter muchly. Detection of the end of header, and, when applied, detection of a start of header, is indicated by __no file name__. The content of these entries is immaterial, the engine makes no use of them. However, certain 3rd party addon makers rely on the fact that *most* pbo extraction tools expect fields to be zero (even though they don't matter). As such, this prevents _some_ pbo's from being extracted by those tools.
Line 176: Line 180:
 Data compression in ofp is a mild, but effective, form of run length encoding, allowing (up to) 4k of previous data to repeat itself. Data compression in ofp is a mild, but effective, form of run length encoding, allowing (up to) 4k of previous data to repeat itself.
  
-Compression is indicated when a signature of 0x43707273 **and** the filesizes do not match in the entry. +Compression is indicated when a signature of 0x43707273 **and** the filesizes do not match in the entry.
  
 The following code __also__ applies to the packing method employed in wrp OPWR files which have no header info simply a block of known output length that must be decoded. The following code __also__ applies to the packing method employed in wrp OPWR files which have no header info simply a block of known output length that must be decoded.
Line 187: Line 191:
  packet  packet
  {  {
-    byte    Format;                  +    byte    Format;
     byte    packetdata[...];      // no fixed length     byte    packetdata[...];      // no fixed length
  }  }
Line 207: Line 211:
 There are three bytes in the block a little further past the format flag that will be passed directly to the output when encountered, and there are FIVE pointers. There are three bytes in the block a little further past the format flag that will be passed directly to the output when encountered, and there are FIVE pointers.
  
-In this example, first byte of packetdata  is passed to output,  2 bytes are read to make a pointer, next byte is passed (ultimately) to output and so on. +In this example, first byte of packetdata  is passed to output,  2 bytes are read to make a pointer, next byte is passed (ultimately) to output and so on.
  
 <code> <code>
  For the very last packet in the block, it is almost inevitable that there will be  For the very last packet in the block, it is almost inevitable that there will be
- excessive bits. These are ignored (truncated) as the final output length is always  + excessive bits. These are ignored (truncated) as the final output length is always 
- known from the Entry. You cannot rely on the ignored bits in the format flag (up to seven + known from the Entry. You cannot rely on the ignored bits in the format flag (up to seven
  of them) to be any particular value (0 or 1).  of them) to be any particular value (0 or 1).
 </code> </code>
Line 238: Line 242:
 </code> </code>
  
-With the values of rpos and rlen there are three basic situations possible: +With the values of rpos and rlen there are three basic situations possible:
  
 <code> <code>
  rpos + rlen < FL // bytes to copy are within the existing reconstructed data  rpos + rlen < FL // bytes to copy are within the existing reconstructed data
- block is added to the end of the file, giving a new length of FL = FL + rlen. + block is added to the end of the file, giving a new length of FL = FL + rlen.
 </code> </code>
  
 +<code>
 rpos + rlen > FL // data to copy exceeds what's available rpos + rlen > FL // data to copy exceeds what's available
 +</code>
  
 <code> <code>
  In this situation the data block has a length of FL – rpos and it is added to the reconstructed  In this situation the data block has a length of FL – rpos and it is added to the reconstructed
- file until FL = rpos + rlen. + file until FL = rpos + rlen.
 </code> </code>
  
Line 264: Line 270:
 ====== Bibliography ====== ====== Bibliography ======
  
-cpbo http://www.kegetys.net/arma/+cpbo https://www.kegetys.net/arma/ 
ofp/file_formats/pbo.1183943898.txt.gz · Last modified: 2007/07/10 09:52 (external edit)
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

All PMC web site download services are temporarily suspended until web site yearly fees have been recovered, want to download addons/mods? Then Support PMC.

If you are grateful for all the work PMC has done in the past 25 years, use Support PMC page.