MakePbo

MakePbo version 1.xx by mikero.

see readmegeneral.txt and fixes

---

MakePbo is a venerable program that dates back to the origins of OFP's cwc. It maintains full compatibility with those products while creating pbo's for Arma3 (and beyond)

As such, be a little kind when reading the documentation (and some of the idiosyncratic -options). Some of it will not make sense to the context you are trying to achieve, eg making an arma mission or addon.

Makepbo is by no means difficult to use, often simply requiring nothing more than

MakePbo NameOfFolder

Both the dll, and the exe itself, use heuristics in examining the folder contents to 'understand' what you're trying to achieve. This makes it as easy for a mission maker, as an addon maker, to use Makepbo without a plethora of options. Makepbo will figure most of it out, dependent on context of the folder and what it contains.

But, a wealth of -options are available dependent on what you are trying to achieve (compressed files, altered prefix, unincluded files, datestamps, auto conversion of wav), the list goes on...

ALL pbo types are supported by MakePbo: Ranging from ofp-cwc thru to arma3 / vbs lite with the sole exception of ebo files (genuine vbs2)

Be aware, immediately that a 'pbo' can have several different extensions. Specifically

• pbo
• ebo
• xbo
• ifa

The general case is that MakePbo will decide what extension to use.

---

Syntax: MakePbo [-options] Full\Path\To\Foldername [destpath and/or pboname[.pbo|ebo|xbo|ifa]]

Despite the wealth of options available, the most common and generally accurate syntax is

makepbo Full\Path\To\Foldername

Foldername.pbo will be produced in the parent folder of foldername

Options: (case INsensitive)

• -A ArmA (default)
• -C CWC
• -R Resistance
• -E Elite
• -Ve VBS2 EBO (not implemented)
• -Vm1 Vbslite pbo UK Mission
• -Vm2 Vbslite pbo US Mission
• -Vx1 xbo file UK
• -Vx2 xbo file US
• -N do Nothing special. Make a pbo wysiwig
• -B Binarise (default) Binarises all rapifiable files.
• -L Lintcheck: check any file that is rapifiable text (*.rvmat eg) but commit as unbinarised

rapifiable files (currently) mean

• *.rvmat
• *.bisurf
• *.fsm
• *.sqm
• *.bikb
• *.cpp
• *.ext (never saved as such)

• -T binarise and include config.cpp as config.cpp.txt (eg) allow .h (eg) to pass unmolested
• -G Check external references
• -Gs Show rap decoding (debug useful in conjunction with -G)
• -Gp Check externals but not proxies (ignored, no longer required)

• -P dont pause (bad status still reported and up to the controlling program to do something about it)

options with arguments

can be stated as

-option space argument OR

-option=argument

the latter allows proper detection of the first genuine non-option file reference

• -@[=]PrefixName this will over-ride $PBOPREFIX$ and use a direct over-ride

Compress files

• -Z[=] "default". Use internally decided files to compress which depend on context of pbo type
• -Z[=] "Comma,Separated,List"
• -Z[=] "file[.lst|.txt|<.ext>]" [.lst|.txt|<.ext>] can be either of the defaults, or an explicit extension

Exclude files

• -X[=] "none" exclude nothing
• -X[=] "Comma,Separated,Exclude,List"
• -X[=] ExcludeList[.lst|.txt|<.ext>]

• -J Ignore lack of mission.sqm or config.cpp
• -D reDuction of description.ext
• -U allow unbinarised p3d
• -$ potentially allow unprefixed addons
• -Q Lint only (pretend to make a pbo, but just scan for errors (use in conjunction with G/GS)
• -W No DateStamps for files in pbo (helpful when re-generating consistent sha)

LINT ONLY Q option

this option DOES NOT MAKE A PBO. it scans unbinarised wrp and p3d for errors (in addition to general rvmat and config checking)

EXTERNAL REFERENCES

-G Check external references when rapifying

This is a safety check that the p3d and paa files (eg) as detected in a config.cpp (eg) are present on the p: drive

You can safely create a pbo without this option. It is 'there' as a confidence check that you haven't created typos

Note that the dll only checks when rapifying or lintchecking *any* file. The -G option warns of missing files, -GS shows which ones

SHA/CRC SIGNATURES

sha key signatures (Arma) or crc checks (elite) are automatically appended to end of file. when appropriate

---

Caveat. Bis unbinarised

MakePbo is not a drop in replacement for binpbo. Makepbo does not binarise p3d's and wrp files.

What it can do however is detect faults that binbpo does not. You really should use makepbo -Q before you use binpbo

WrpFiles

Makepbo will fail with warning messages if you attempt to add an unbinarised wrp.

The 'correct' option to use is -UQ[G] : check the wrp external references and other wrp internals for 'bad-ness' (but do not make a pbo)

P3DFiles

Makepbo will fail with warning messages if you attempt to add an unbinarised p3d and do not use the -U option

The 'correct' option is to use -U[G][Q]

This allows an unbinarised p3d to pass unmolested (and be checked for 'bad-ness').

Adding the -Q option above simply allows the exe to use it's very powerful analytics before passing to binpbo

MakePbo It is a popular exe for simply extracting an existing pbo, modifying the config.cpp (eg) and repackaging.

---

PBO PREFIX: This section does not apply to ofp.

Prefixes apply to addons, not mission or campaign pbo's. if mission/campaign pbos have prefixes, they are ignored by the engine. Be careful with this terminology. An addon, can contain missions.

all references in this document to '$PBOPREFIX$' and PboPrefix.txt are replaced by $PBOPREFIX$.txt

the dll reads any of above but only creates

$PBOPREFIX$.txt

Bis have severely stuffed it up with (lack of) relative addressing in ALL their files except for missions (and even there got much of it confusingly wrong).

The idea than a tank can't refer to it's own data in it's own pbo is beyond ridiculous. Instead, all references are hard references referring back to (as it happens) the same pbo. This makes moving objects around as oops objects a nightmare.

However, bis also got the idea of a prefix *seriously* right.

A prefix, (or sometimes a presumed prefix) is embedded in the header of all addons.

This sets the location of the pbo in concrete relative to the engine's internal file addressing. It is variously called namespace, virtual drive space, and etc. For shorthand purposes and sheer convenience to an addon maker, it is the 'P:\' drive. (could be any drive, but P: has become a de-facto standard)

A prefix will be embedded in a pbo by makepbo under the following cascading rules:

• Irrespective, no matter what, neither an ofp pbo or ANY 'mission' pbo will have a prefix.
• A mission pbo is defined as one without a config.cpp AND has a mission.sqm (mission ADDONS have config.cpp's)
• Although 'wrong' some pbo's have neither. These are addons.
• The -$ option will prevent a prefix under special conditions. See below.
• The -P option over-rides any other form of prefix definition determined by the dll. Otherwise
• If a $PBOPREFIX$.txt file is detected in the >>>primary<<< folder. It takes precedence.
• This is a method by which drag and drop applications can create prefix pbo headers, without further intervention.
• The content of this file, becomes the prefix header.
• The dll determines the prefix based on the input\folder\name. Output folder specifications (if any) play no part in prefix

makepbo any\where\fred ->prefix = any\where\fred

makepbo fred ->prefix=fred

• -$ option (not recommended)

Bis arma engines allow for a pbo without a prefix to assume a prefix of the name of the pbo.

If and only if

1. the pbo is an arma family addon (mission pbo's do not have prefixes)
2. the resulting prefix name is a unitary file Ie p:\fred (not a p:\somewhere\fred),
3. the resulting unitary file name IS the output filename
4. the -$ option is specified,

THEN no prefix will be written. (Otherwise the option is ignored).

This dll adds additional lines to the header and take the form of:

variable=value;

The most notable use of above is to specifically state THIS pbo's intended engine

Product=Arma3;

author=I am Famous;

prefix=what\ever (not recommended)

The previous kegetys single line statement

what\ever is supported (not recommended)

---

Reduction

-D option will compile, then decompile *.fsm , *.bikb's and description ext in an effort to reduce #defines and extraneous data.

The resulting output text is intended to produce a smaller footprint, and remove #include dependencies

it will fail with an error message if desc.ext contains EXEC/EVALS

---

Compression

Any pbo can be compressed for ANY engine. Since many low grade pbo extractors 'out there' don't understand compression, this can be used as a mild form of obfuscation.

The results of compressing mission pbos can achieve better than 75% reduction in payload.

For addons, the results are less spectacular (between 5..10%) because pax's (which form the majority of files in an addon) are generally the largest in size and are (mostly) pre-compressed anyway.

syntax:

Default is no compression. (no -z option)

MakePbo -Z "Comma,Separated,Ignore,List" [ otheroptions...] folder....

MakePbo -Z IgnoreList[<.ext>|.lst|.txt] [ otheroptions...] folder....

The 1st method uses parameters directly from the command line. This list MUST be enclosed in quotes. (if ,,, or spaced args)

The 2nd method utilises (an often common) ignore list. The content of which should be same as a command line entry (obviously), except quotes in this case are optional.

.lst or .txt extension is optional for the 2nd method. You can alternatively specify a different .extension

compression will only occur to each 'file' if resulting output is smaller that original.

YOU MUST SPECIFY A LIST if using the Z option

If you want DEFAULT files to be compressed use "" or "default"

The current dll defaults to ignore are

• .wav

• .jpg

• .ogg

and for arma, this is extended to pac/paa files because of terrain streaming

if you want ALL files compressed use "all" (the dll will not 'see' .all extensions, and hence compress all files)

However, note that, under no circumstances will the dll compress a file to make it LARGER.

This frequently occurs for pax files. The result is, that pax will be stored untouched.

note that compression applies to file extensions not file names.

"Comma, Separated, .Ignore, *.List"

The format is pretty much free form. Spacing between args is permitted any of the following forms are mutually equivalent.

• .ogg

.ogg

ogg

Note that compression can take considerable time to achieve. It is 'safe' however to simply allow the dll to attempt to compress it's internal, default, file list.

NOTE for vbs2

encrypted AND compressed files *cannot* co-exist. If compression is specified, the pbo is encrypted along with any uncompressed files. The compressed files (if any) remain unencrypted.

---

===Optional destination===

can take several forms

• MakePbo [MyPath\]MyAddon

// ->output to [MyPath\]MyAddon.pbo

MakePbo [MyPath\]MyAddon ThisAddon

//

->output to CurrentDir\ThisAddon.pbo

• MakePbo [MyPath\]MyAddon ThisAddon\

//

->output to CurrentDir\ThisAddon\MyAddon.pbo

MakePbo [MyPath\]MyAddon ThisAddon\ThisPbo

//

->output to CurrentDir\ThisAddon\ThisPbo.pbo

MakePbo [MyPath\]MyAddon \ThisAddon

//

->output to \ThisAddon.pbo

• MakePbo [MyPath\]MyAddon \ThisAddon\

//

->output to \ThisAddon\MyAddon.pbo

MakePbo [MyPath\]MyAddon \ThisAddon\ThisPbo

//

->output to \ThisAddon\ThisPbo.pbo

Note that, under ALL circumstances, if 'ThisAddon' happens to be the name of a folder, it is equivalent to stating 'ThisAddon\'

Note: extension type is not required and has consequence for users specifying an XBO target but, in fact, the dll discovers it's a vbs2 lite mission.

under that, special, unique circumstance, the intended.xbo is renamed to .pbo (a vbs 2 lite quirk)

• MyAddon is subject to pboname.h. see versioning readme

---

PBO OUTPUT NAME

the rules are as follows

'standard' behaviour is to place an NameOf.pbo in the parent folder of where\ever\NameOf Folder.

example:

makepbo any\where\fred //-> any\where\fred.pbo

makepbo fred //-> fred.pbo

specifying output

makepbo some\folder any\where ->any\where\folder.pbo

makepbo some\folder any\where\this.pb0 -> any\where\this.pbo

pboname.h

if a pboname.h is detected in the primary folder, it replaces the output name.

NOTE THAT

1) destination folders remain the same

2) if a destination PBO is named, the pboname.h is ignored

NOTE THAT

drives: and or \root\path specifications are as equally valid as relative addressing

---

-X PBO EXCLUSIONS

Rules:

In order of precedence:

1) under no circumstances are .xxx folders examined or included. They are what their intention is :- Hidden

2) Option -N (No rapify, no binarise, no nada) is the wyswig option. No files are ignored, no files are examined, no files are checked. What you see is truly what you get.

3) config.cpp

It is very normal to exclude *.cpp *.h and *.hpp. After binarisation, they have done their job. The best way of including them in a pbo, is to simply not Rapify, (option -wysywig)

EVEN IF *.cpp is specified to be excluded, a config.cpp file (and any of it's

1. includes) are special in that they will binarised to .bin and thus not actually

ignored. Not included, but not ignored.

4) If nothing is specified on the command line, the default exclusions are:

• .folder +
• "thumbs.db,*.h,*.cpp,*.bak,*.png,*.dep,*.log"
  

Thru an unfortunate but popular use of hpp files as included sqf files, hpp is not part of this list. It should be.

Command line options

-X none

NOTHING will be excluded

-X "comma,separated,list"
When more than one file type is excluded, eg, commas, the list must be specified between quotes. Spacing is permitted.

-X An\Exclude\File\Somewhere

the dll accepts default extensions of .txt or .lst : There is no need to state SomeWhere.LST

---

exclusion syntax

• .bak and .bak are synonomous
  

Specific.file
SpecificFolder


Note that:
the above syntax only supports the most primitive of wildcard (*.)
there is no mechanism to exclude path\to\folder or path\to\file
All folders of a given name will be excluded, All files similarly.

---

Versioning using pboname.h/hpp

mikero march 09

revised: june 2011

Preamble:

---

Pbo prefixing was introduced With Elite-Xbox and continues with Arma.

---

Essentially, the NameOf.pbo is entirely irrelevant.

---

All references to the contents of a pbo are by way of it's prefix, NOT, nameof.pbo

This means (as a test for yourself) you can rename ANY one of the official Addons to PinkElephants.pbo ,and nothing breaks.

As a result, versioning is possible. In ofp, this was a nightmare, requiring every mission that used that addon to be revised to requiredAddons[]= new name

In arma, simply create

MakePbo MyGreatAddon

later

MakePbo MyGreatAddonV1

MakePbo MyGreatAddonV2

and so on.

• providing* you haven't changed it's prefix, earlier missions and reliant

addons, remain compatible.

There are several ways to achieve versioning

1) Makepbo.exe SameFolder. Rename Resultant pbo to whatever

2) MakePbo.exe SameFolder NewPboName

These options are difficult to achieve in a batch 'packing' enviroment where everything is hardwired

3) MakePbo.exe NewFolder.

This is an impossibility for P:MyGreatAddon because visitor and oxygen will look for oldname for existing models. It is also impossible for svn / git repositories.

4) use pboname.h in SameFolder

pboname.h/hpp overcomes these limitations and should be considered versioning documentation.

The dll looks for 'pboname.h/hpp' in the primary folder. if encountered, the resultant pboname is altered to

pboname="MyBestAddonEver1.00V22"; // or whatever

the difference between 'h' and 'hpp' is that hpp will be included in your pbo, 'h' will not

See sample pboname.h

Note that pboname is ignored/over-ridden if you deliberately specifify an output pboname on the commandline (not an outputfolder, an outputpbo)

example

makepbo.exe MyAddon Some\Folder // pboname in effect

makepbo.exe MyAddon Some\Folder\SomePbo \\ pboname disabled

      ExtractPbo Gui    

ExtractPbo (Gui) and ExtractPboDos version 2.xx by mikero.

WIN VISTA and beyond. This exe is not compatible with winxp.

See readmeGeneral and fixes

---

ExtractPboDos is a dos console only application for spread freaks.

ExtractPbo is the gui version which contains ExtractPboDos inside

ExtractPbo works in an identical manner to ExtractPboDos in console mode.

ExtractPbo does what it's name suggests.

ExtractPbo covers the nuances of all Bis 'pbo' files from the very first cwc demo to Arma3. This includes (but is not limited to):

• Cold war crisis
• Resistance
• XBox Elite
• Arma1,2,3
• Arrowhead
• Ifa (ifa files)
• vbs2lite (xbo files)

Extractpbo will specifically not extract vbs2 'ebo' files.

In the following documentation a 'pbo' is considered to be: .pbo, .ifa, ,ebo, .xbo

This is a powerful dos console extractor that extracts ANY pbo from CWR thru to VBS2 LITE (xbo files)

ExtractPbo uses a heuristic approach to output the best possible results to the best-possible output folder. While you can over-ride the default options the general scenario is that the extractor will

• Derapify binarised content (mission.sqm, config.bin. *rvmat ,etc)
• Decompress a pbo (ofp only)
• Decrypt Elite and VBS2 Lite pbo's
• Autodetect the type of pbo / xbo / ebo
• Verify valid compression for p3d and paa content (eg)

In the specific case of non-ofp pbo's , the prefix is accounted for by writing the file pboPrext.txt to the output.

An erroneous pboPrext.txt file if detected in the pbo itself, is never extracted.

usage

extractpbo [-options...] NameOfPbo[.pbo|.xbo|.ebo]/aFolder/AnExtractionList [SomeFolder]

.extensions are not required. a 'pbo' is considered to be ANY *.xbo,*.ebo,*pbo

options (optional, case insensitive)

-L list only

-LB brief dir style output

-P do not pause (allow the controlling program to handle the return status)

-S silent (default)

-N Noisy

-D Derapify file(s) where relevant (default)

-R Dont Derapify file(s)

-Y Don't prompt if overwriting a folder

-A deprecated

-T used spaced (not tabbed) derap output

-W Warnings are errors

-V1 force extraction of vbs2 lite uk

-V2 ditto us

normally, the dll will detect which type it is. In extreme circumstances the heuristic model might fail, and you can force it to one, or the other.

Note missions (pbo) and addons (xbo) are equivalent.

-F filelist[,...] name(s) of file(s) to extract

extracted file(s) will appear in their 'correct' position in the relevent output folder tree

thus, multiple instances of config.cpp (eg) can be extracted.

a minor form of wildcard the aster dot sequence can indicate 'all' extensions of that type

-K ignore prefix

OUTPUT FOLDER

Distinctions exist between folder output for OFP vs non OFP (ARMA)

• in OFP the NameOfPbo is sacrosanct. It must form part of the output to have any meaning to the engine.
• in ARMA the prefix inside the pbo is sacrosanct. It will form part of the output.

The dll detects the difference.

Thus:

For OFP:

extractppo thing.pbo >> contents to thing\

extractpbo thing.pbo anywhere >> contents to anywhere\thing\

For ARMA:

extractppo thing.pbo >> contents to thing\'prefix'\

extractpbo thing.pbo drive:\anywhere >> contents to contents to anywhere\'prefix'\

the anywhere clause for arma allows creation of a p:\ca by specifying

extractpbo thing P:\

Note that the -K option ignores the prefix and writes to output as per ofp

this can be a convenience when decoding very long paths

---

Be WARNED

Normally, extractPBO does two important things

1) it checks before over-writing a folder

2) it erases all output folder content in an 'all bets are off' approach before extracting the pbo

using the anywhere option causes these 2 features to be disabled.

if you have crap in the output folder(s). the crap will remain in the output folder(s)

if you specify an 'interesting' destination. you will get, 'interesting' results.

---

extraction behaviour

• • Fundamentally, a folder is created of the same name as the pbo in the same

folder as the pbo.

• • Arma pbo's will, in addition, create subfolders based on the detected

prefix. Thus:

ExtractPbo Thing

OFP: pbo thing.pbo -> thing\.....

ARMA: pbo thing.pbo -> thing\Prefix\......

Option -K is used to force OFP behaviour

ExtractPbo -k Thing //Arma prefix subfolders are NOT created (but the $PREFIX% is still supplied correctly)

thing.pbo -> thing\..... (prefix is ignored)

• • ============================

• • Specifying a destination

• • ============================

ExtractPbo thing P:\

thing.pbo ->P:\prefix\.... will create a perfect namespace based on the prefix.

ExtractPbo thing -k P:\

thing.pbo ->P:\thing\prefix\....

ExtractPbo thing P:\SomeWhere

thing.pbo ->P:\Somewhere\prefix\...

ExtractPbo -K thing P:\SomeWhere

thing.pbo ->P:\Somewhere\thing\.........

=================

Specifying a relative destination address

=================

you can't. drive: MUST be specified

Other examples

extractpbo thing

will extract thing.pbo to thing\ folder and derapify any content (such as mission.sqm) that has been binarised

extractpbo -f -r mission.sqm thing.pbo

will extract a single file (and NOT derapify)

extractpbo -L thing

does a dir listing of pbo content along with added info

extractpbo -f *.p3d nameofpbo

will extract ONLY p3d files

extractpbo ExtractionList.any [toSomewhere]

will extract files contained in extraction list. Nameof extraction list can be anything other than .pbo, or foldername

line syntax for each line is identical to command line.

global parameters FROM the command line operate as defaults if not respecified in the list

extractpbo Folder [toSomewhere]

will recurse subfolders of above searching for pbo files.

==warning messages====

"1st/last entry has non-zero real_size, reserved, or BlockLength field"

"reserved field non zero anywhere in entry bodies (except xbo)"

Normally an attempt to prevent extraction and should present no issues. But, users should suspect something wonky in the author's implementation

"no shakey on arma";

early pbo makers did not create the appended 21 byte sha. This causes issues only if attempting to sign the pbo for MP play

"residual bytes in file" // throws an error anyway

something has been either misinterpreted, or the pbo maker is at fault

"arma pbo is missing a prefix (probably a mission)";

missions do not require prefix entries. But, as a matter of de-riguer, they normally have them.

---

ExtractPbo,exe is ExtractPboDos.exe with Window dressing (pun intended).

Major Features:

• Dual Dos-Console or Windows Mode.
• Drag n Drop Interface fully exploited.
  • Drop (and open) pbo's onto the dialog
  • Drag or drop single files or entire folders INTO or OUT OF the pbo
  • Double Click Automated viewing of (almost) any pbo file in it's relevant application (texview,visitor, rvmat, ogg)
  • Renaming/Deleting/Adding/Moving any part of the pbo tree

This application implements a consistent user interface. To whit:

• All files extracted from a pbo are unconditionally:
  • DeCrypted if encrypted.
  • DeCompressed if compressed.
  • Unparsed to humanly readable text (config.bin, rvmat, bisurf eg)
• All Saved As pbo's are unconditionally:
  • Encrypted if vbs2lite
  • Uncompressed
  • Parsed (Rapified)

To keep the interface noise free and simple to use, there is no facility for selective Parsing/Compression/Encryption. All of these 'features' use tried and proven algorithms inside the dll including which types of files require modification.

Dos Mode:

It will operate, just like before, in dos (console) mode, allowing batch file processing, drag n drop, and dos console operations. It will behave as nature intended, and as described, in the ExtractPbo readme. A more versatile and extensive range of -options exist in this mode for the connoisseur (or insane). The very popular Arma2P extractor for instance uses Dos Mode.

Windows Mode:

Windows mode is how most (new) users will prefer to use it.

Switching between Dos and Windows Mode:

ANY parameters supplied on the command line invoke Dos Mode. This occurs as a natural result of simply using it in a dos console to begin with and specifying a pbo to extract, or, dropping a file onto the exe icon. On the other hand, simply invoking this exe from a dos console with NO parameters, invokes the gui.

Windows mode uses previously recorded 'session' data of which files, what targets, to start with (including window positioning and size).

Forcing Windows Mode:

-w on the command line, or, by checkbox.

Be wary of using this option. Dos batch files expecting dos results, will fail.

---

ExtractPboGui will extract the content of any 'pbo' except encrypted vbs2. (yes, it does extract vbs2lite)

The over-riding philosophy of all MikeroTools (not just this one) is to maintain backward compatibility. To this end, the same 'behaviour' can be expected from files emanating from the very first cwc demo, Resistance, Xbox Elite, Arrowhead, TOH, Arma3, IFA extensions, Vbs2lite. There are nuances to each type which the underlying dll takes care of. They are hidden from the user (and hidden from developers using the dll who only want to 'see' a uniform API). ExtractPboGui utilises over a decade of lessons learned in the dll about things-pbo. Underneath the covers it is exceptionally powerful and above all, robust.

Options available in this gui are intentionally bare minimal. The intent being, 'just extract the damn thing'.

Installation:

Self installer: sit back and watch the pretty lights.

Manual Install:

Anywhere that gives you a thrill, but take note that dePbodll is also required for this gui. (of course)

'pbo'

In this documentation 'pbo' is meant to infer SomeFile.pbo

To avoid the risk of tediousness everywhere else, a 'pbo' can actually be an .xbo .ebo, .ifa, or, indeed, a .pbo. If a .toh ever gets introduced (or any other 'pbo' extension) you can be sure the underlying dll will 'understand' it's a Packed Binary Object.

Gui options:

PboName

Use the browse button (...) to select any 'pbo' from anywhere, including net drives.

Output Path

Use the browse button (...) to select the beginning of the extraction point or simply type or paste it in. The Browse button allows you to create new folder(s) for the beginning should you wish to.

Note most carefully. This is the beginning path of all extracted content. From this point on, the nature of the pbo determines how that path will be filled (by prefix, by pboname)

If you wanted to re-create the bis engine's view of 'files', you would set the Output Path to "P:\"

Destination Folder

ExtractPboGui autogenerates this path based on the OutputPath above, catenated with the internal prefix of the selected pbo (if any), or it's pboname (if none). There is no facility to change this catenated prefix.

Allow Overwrite

If the Destination Folder already exists, you will normally be asked before extracting. Allow Overwrite removes this sometimes annoying safety feature.

Be aware this is the Destination Folder being over-written, not, the entire Output Path.

Remove Folder Before Extraction.

In a fair and reasonable world, you wouldn't want 'stale' paa's remaining via some previously extracted content. Or any other 'file' you might have placed there. Unfortunately the nature of Arma prefixed pbo's is such that nost of the pbo's live inside the file space of some other pbo. If you extracted Air3.pbo and THEN extracted Air.pbo (it's root). Air3 content would be inadvertently removed.

BUTTONS

EXTRACT

Should speak for itself. The main purpose of this application!

SAVEAS

For whatever reason wanted, the current contents of this pbo can be saved anywhere, including a new name for the pbo, or indeed an existing pbo including the original. (protection dialogs exist).

The 'current' contents may indeed be 'as is' or some/ all /none of the contents may have been renamed/ added to, moved, or deleted.

Sneak Peak

The file and folder header entries of the 'pbo' are listed in this panel as soon as any valid file is selected. While exceptionally useful for advanced work, you can safely ignore them for simply extracting your 'pbo'.

Output Screen

Is (almost) identical to the dos console screen output on the dos mode of this exe

Initially it shows the basic pbo header type whenever a pbo is selected. This, together with Sneak Peak, is useful when you're browsing multiple pbo's, not necessarily wanting to extract them.

Ultimately, this screen lists the content as it is being extracted: it's compression, it's encryption, it's (de)Rapification, and any errors encountered.

DRAG n DROP

The list below of possibilities should all be intuitive.

You can:

• Drop pbo's anywhere on the gui and they open automatically.
• Drag or drop any file or folder from, to, the currently open pbo

Dropping files into the pbo are problematical in the sense of bi's braindead file referencing but opportunity's exist to drag out, fix a texture, drop it back in as but one, of many possibilities.

Dragging out (or simply viewing) a single file such as the all important config.bin/cpp speaks for itself.

• Double Click (almost) any file in the pbo to 'view it' with it's relevant application
• Rename files or folders in situ
• sanity checks prevail that you don't rename extensions from rvmat to paa (eg)
• delete files or folders in situ
• Move files or folders in situ Again, with BIS's braindead file referencing the usefulness is problematic, But, it can be done, for whatever purpose.
  
• Direct drag of 'ofp/vbs/arma' files from one Gui to another 'vbs/arma/ofp' Gui (mix n match upgrades)
• Change the prefix

Expandable Dialog

As implemented, the Gui initialises in 'basic view'. Simply extend the edges of it's borders (or open in full screen mode) to view very-long-filenames eg, to suit your purpose.

Enjoy