MoveFolder
MoveFolder Version 1.xx by Mikero
see readMeGeneral and fixes
MoveFolder is the successor to SetP3d which was written in 02script and quite difficult to
maintain. The intent of MoveFolder is to move some, or all of the content of a pbo or series of pbos, to another one.
Because of BI's astonishing inability to use relative addressing, p3d's must reference the pbo they are in to get at their own data. Ditto, rvmats, ditto sqx, ditto configs. If you move anything to another pbo (folder), the items within that folder need their addressing revised. Insane, but there you go.
MoveFolder allows any combination p3d's, wrps, rvmats and configs and all their associated data to be transferred to a different pbo. It does so by renaming (and copying) all appropriate file references encountered in these files to the new prefix. MoveFolder only alters items in the target folder, all other files are unaffected.
MoveFolder can be terrifying to the un-initiated.
The sheer volume of changes it makes to files can be staggering, and can take a
long time to complete. The two things to bear in mind are:
- No matter what it does, no matter how gigantic (or trivial) the changes made: movefolder does not touch or alter existing source(s).
- you no longer have to do these changes by hand with the attendant mistakes and hours of your time trying to.
MoveFolder has two distinct modes of operation:
- standard p3d alteration, or,
- using a config.cpp/bin
The need for this application are many but prime examples would be:
- Merging multiple pbo's into a single pbo.
- splitting a big pbo into smaller ones.
- retrieving only those p3ds of relevance from arma1,dayz or ifa to a different engine
MoveFolder works with any mixture of plain jane or binarised file formats of any file type.
MoveFolder is not intended for use with
missions. your mileage will vary. For islands see end of document.
Installation:
MoveFolder uses the venerable MoveObject.exe as it is
core. you must also have a copy of moveobject.exe installed
MoveFolder comes with an auto-installer. This ensures
it is part of mikero's pbo tools suite. Many of the tools interact with each
other. MoveFolder is no exception.
If you choose to install it manually, you clearly know
what you're doing.
How to:
All operations require a 'Pdrive'. MoveFolder
infers the drive from the folder-to-make. It is normally P:\. If you specify
C:\"my documents\some\where", you also believe in Santa Klaus.
Method 1: p3d's only
- simply create a new folder in 'Pdrive':\any\where. This folder is, ultimately, your new pbo.
- drop any number of p3d's, and only p3d's, into that folder.
- use the gui to browse to this destination
- crunch.
Assuming all references in those p3d's point to valid files elsewhere on the 'pdrive', MoveFolder will build a corresponding data\ folder accordingly. MoveFolder recursively scans this folder as rvmats or proxies are being added, checking them in turn for their own external references, and so on.
If a p3d does not have valid references. eg my\great\addon\data\sexy.paa
does not exist. then you, not MoveFolder , has a problem. You can hardly expect
it to copy phantoms.
You can subsequently add to this folder, other p3d's.
MoveFolder will account for them. The already done, p3d's (and rvmats) are not
affected.
You can then add or create config. sounds or scripts or
anything else into this folder. Should you subsequently use MoveFolder again
(because you need yet another p3d) it has no effect on what's there already
including your added scripts (eg).
Method2:: config only
1) browse to the source folder containing the config of interest
2) browse to a newly created empty destination folder or use the
browse facility to create one.
3) crunch
A sanity check is made for method 2 that the
destination folder is empty. There is no particular reason for this other than
to prevent you inadvertently destroying some\thing you didn't intend.
Nitty Gritty
source: The source config.cpp or bin. It's location does
not have any bearing on the location of the files it refers to.
destination: The new folder where you want these items
to be built. this folder subsequently becomes a pbo in it is own right.
gui options:
- Move CA/A3 Off by default. if you want future proofing against the engine check this option to copy all relevant files into this new space. This makes the p3d truly independent.
- Move Proxies
Off by default. Any proxies p3d's used are placed in this folder too. It is 'standard practice' for building furniture eg to be in a separate pbo.
set this option if you want to copy that furniture into stand-alone.
If ca/a3 is also set, then it is proxies are also added. Otherwise not.
- Pause output
show the results of moveobject's renaming operations, rather than briefly flash the screen.
Architecture
MoveFolder provides the following tree architecture
Pdrive:\Any\Prefix\FolderOfP3d(s)
- 'FolderOfP3ds' becomes the new pbo
- Any\Prefix is your project and tag name
all p3d's must be in this root folder.
all sounds will be written to ~Sounds\
all rtm's will be written to ~Anims\
all sqx will be written to ~Scripts\
all textures and materials will be written to ~data\
MoveFolder attempts to copy the
original pbo's architecture where possible. if the original rvmats were in
data\rvmats, this app will place them similarly. if not, they go into the common
~data\ folder.
- texture rules
MoveFolder considers pax, png or tga to be equivalent. it copies whichever of these files is found with the latest file date for unbinarised p3d's and copies only a pax for binarised.
config.cpp and bin
Creating new pbo's from just p3d content is not normally sufficient. configs
which handle those p3d's normally have additional damage rvmats, picture= and
icon= specifiers, along with sounds rtms and scripts. While these additional files are
often only related to the p3d, there is nothing in the p3d that utilises them.
Hence they wont be detected for transfer.
MoveFolder will create the necessary contents of a pbo
folder simply by examining a config.cpp or config.bin sourced from some other
folder.
For this mode of operation, all that is required is the config. (not p3d's)
Any and all file references detected in the config are
copied over and massaged (with the usual options applying of 'move ca/a3' and
'move proxies'). This includes p3d's.
be aware that the end result is a NEW config.cpp in the target folder.
Independent config pbo
it is common practice for designers to separate their
pbo's into ones containing p3ds and data, and one containing a config only, for
those models.
the produced config.cpp can be transferred to any pbo the
designer wishes. it is NOT prefix sensitive.
model.cfg via config.cpp
For unbinarised p3d's MoveFolder checks for the existence
of a 'model.cfg' or a 'nameofmodel.cfg' in the same folder as the p3d
if present,it copies it to the root of the target folder.
there is a possibility of failure where two or more
model.cfg's exist emanating from different p3d source folders
identical file names from sources
where a filename conflicts with the same name but from a diffferent source
folder. example
ca\data\default.rvmat
ca\any\where\else\default.rvmat
a check is made for indentical content. If the same. the first file
encountered is used as a substitute for the others.
where files are not identical they are labelled
cpy_<filename.ext>
eg
cpy_default.rvmat
This process is iterative.Where three files eg are from different sources,
the results would be
default.rvmat
cpy_default.rvmat
cpy_cpy_default.rvmat
Islands
There is currently modest support for moving islands.
MoveFolder behaves slightly different for islands in that it assume you want
to move the island and it is textures but NOT the p3d objects associated with it.
For this reason, p3d's are ignored when a wrp is detected
The only other difference is that textures and rvmats go into a ~layers\
folder. (pictures and icons described in a config.cpp still go into ~data\