Author: Mikero
All Mikero tools 'behave', install, and operate in an identical manner. You are strongly advised to read the General Readme once.
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.
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:
MoveFolder has two distinct modes of operation:
The need for this application are many but prime examples
would be:
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.
A no nonsense auto installer saving you sweat and tears.
Do not run this, or any tool from bis, as administrator.
'Admin' is not what you think it is, it is an alias for 'Microsoft Office Use only'.
Consider yourself warned.
MoveFolder uses the venerable MoveObject as its core.
You must have a copy of MoveObject installed.
Grab the self installers for these here
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.
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, have 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).
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.
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
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\
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.
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 different 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\
Clean
Clean is the most powerful of all the abilities. The intent is to remove unused crud from the data folder. As a natural progression to developing your models you probably choose to use different textures, different paa's. Another cause is when you delete a p3d as no longer needed. Clean, will discover that it's paa's aren't being used by anything else, and remove them.
Note that clean cannot account for paa's (or rvmats) you might only be using in the config.cpp.
For this reason, a backup folder is created of the original data. It is your responsibiltiy, when satisified, to remove it.