MoveObject

From Bohemia Interactive Community
Jump to navigation Jump to search

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