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 have not 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 is 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 is own data in it is 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 Operation Flashpoint 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
- the pbo is an arma family addon (mission pbo's do not have prefixes)
- the resulting prefix name is a unitary file Ie p:\fred (not a p:\somewhere\fred),
- the resulting unitary file name IS the output filename
- 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 is 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 is 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 is
- 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 is 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 have not changed it is 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 is 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 is 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 is 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 is 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 is compression, it is encryption, it is (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 is 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 is borders (or open in full screen mode) to view
very-long-filenames eg, to suit your purpose.
Enjoy