MoveObject
MoveObject Version 1.xx by Mikero
read genreadme.txt
see fixes.htm
MoveObject will rename file paths inside *any*
- wrp,
- rvmat,
- pew,
- p3d,
- All pbo types
- folder
whether binarised or plain.
- In the case of a pbo or folder, the above file types are worked on inside the pbo / folder.
- Pbo's are considered to be ifa,pbo,xbo,ebo
- In the case of a folder, an additional check is made to alter the contents of any of the accepted $PBOPREFIX$.txt's
The intention of moveobject is that you should be able to extract ANY of
these file types from one addon, and place it in another addon without fuss.
For anyone who's been there and dun that, hand editing the path names inside
individual p3d's, let alone 30 or so p3d's, well, frankly, just throw money
There are two classes of usage using moveobject. Listing
content, and separately, renaming content.
usage
MoveObject [-options...] NameOfFile[.ext] [from] [to]
MoveObject [-options...] NameOfFolder [from] [to]
MoveObject NameOfFile[.ext] replacementlist
MoveObject NameOfFolder replacementlist
[.ext] is p3d by default. Any other file type (wrp eg) must be specified
options (case insensitive) |
|
don't pause | |
-F | output list to NameOfFile.lst, not
screen |
-R | Remove old p3d user flags (no replacement
list required) |
-X | unconditionally replace all file
references with lower case (does not affect any that ARE all lowercase) |
-W | allow land_xxx class changes in binary
wrps (see below) |
======================================================
Wrp Land_XXX classes :::Applies ONLY to arma binary
wrps
=====================================================
moving objects from one path to another is fine.
Renaming p3d's is NOT.
The reason being the binary wrp contains embedded information about that p3d in
it's classed models. If you change to another model, that information is
invalid. The dll checks for the special case of a 'classed model' being renamed
(not the path, the model). There is no affect in renaming ordinary p3d's. only
those that are land_classed.
There is of course an exception to above where, in fact, you have *also* renamed
the p3d! In that special circumstance, the wrp information remains valid, and
you genuinely do want to call it something different.
-W allows this.
=====================================================
-List examples
MoveObject NameOfRVmat.rvmat
Moveobject folder >pipe.txt 2>&1 //
full folder tree
the list option is used to
a) check what paths are in the model to change
b) check the change took place
Rename Example
MoveObject MyOldP3d MyGreatAddon\somewhere\data MyNewAddon\Henry\Marbles\wherever\you\want
Note that on success, the original file(s) are not preserved. It is your
responsibility to tuck them away safely somewhere.
The target file is NOT altered if an error is encountered.
The two tandem batch files in the package are examples of how to make a global
change to all files in a given folder
There usage may not be necessary with the folder option
introduced at a revision i don't now recall. They are preserved for your
interest.
Notes:
All renaming must be from start\of\folder.
- renaming marbles will not work.
- renaming some\folder\marbles will work
if you specify a leading slash, it will be ignored. It is
neither correct, nor incorrect to do so. It is however, extremely convenient to
use dos tabbing to fill out the full pathway. Similarly (because of dos tabbing)
a drive: specifier is also ignored.
Bis have made their usual cock up of hard versus relative
addressing in their file structures. They are unlikely to ever fix what is
beyond their abilities. No matter what, no if's and no maybe's. ALL
bis addressing is \hard\path. So thi makes ooops object modelling a frustrating
and pointless waste of effort.
However, because of their own internal mess, *some*
path specifications must have a preceding slash, some must *not* have, and other
types don't care. Move object takes care of which is what without you worrying
about it.
Where you have differing child paths, (and most models have lots
of differing child paths) you need to successively invoke MoveObject until
you are complete starting with children then parents. MoveObject eases this by
accepting a txt file of iterative lists.
Restrictions:
ofp unbinarised p3d's (odol-sp3x) cannot have
- more than 32 character default path
more than 32 character texture names
more than 58 character proxy names
Wrp unbinarised Operation Flashpoint files (4WVR) cannot have
- more than 32 character texture names
p3d model names > 76
p3d model names <3
wrp unbinarised arma files (8WVR) cannot have
- less that 3 characters for p3d model names
Be prepared to wait a very long time on 1gig wrp files
Parameter List:
the text file must contain the following format (as if each line were passed on
the command line)
OldName1 space NewName1
OldName2 space NewName2
the parser for this is very primitive and very unforgiving
Enjoy