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

1. simply create a new folder in 'Pdrive':\any\where. This folder is, ultimately, your new pbo.
2. drop any number of p3d's, and only p3d's, into that folder.
3. use the gui to browse to this destination
4. 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\