View source for Load Oar 0.9.0+

= Load Oar Console Command =

This page provides information on the 'load oar' console command from OpenSimulator version 0.9.0 onwards.

Once you have saved regions in OAR files, the 'load oar' console command will load the OAR file into the current region. There are many parameters that enable replacing the region's current contents or merging the OAR file's contents with the objects and terrain already in the region.

== Parameters ==
The load oar command in OpenSimulator version 0.9.0 onwards has the format:

 <tt>load oar [parameters] OARFILE</tt>

where "OARFILE" is the path to the OAR file to read in, and "[parameters]" is zero or more optional parameters from the following list:

{| class="wikitable"
! style="width: 10em" | Parameter
! Since
! Description
|-
| <tt>--merge</tt>
| 0.6.8
| Specify to merge the contents of the reading OAR with the existing contents in the region.
|-
| <tt>--skip-assets</tt>
| 0.6.9
| If set, this will not load any of the assets from the OAR, though all other data will be loaded. This saves a lot of time and database operations if loading an OAR multiple times on a grid -- specify <tt>--skip-assets</tt> after the first time the OAR is loaded on a grid as the assets would have already been loaded the first time the OAR files was loaded.
|-
| <tt>--rotation</tt>
| 0.8
| The degrees to rotate all the objects loaded from the source OAR. This rotates terrain, parcel data and objects (prims) and is degrees counter-clockwise.
|-
| <tt>--rotation-center</tt>
| 0.8, but depricated in 0.9
| The center around which to rotate objects on load. From 0.9.0 the source region's data is always rotated around it's center, prior to cutting a piece out and placing it. The parameter will likely be removed in 0.9.1
|-
| <tt>--bounding-origin</tt>
| 0.9
| The SW corner of a bounding cubiod that is used to 'cut out' data from the source OAR
|-
| <tt>--bounding-size</tt>
| 0.9
| The size of the bounding cuboid used to 'cut out' data from the source OAR
|-
| <tt>--displacement</tt>
| 0.8
| Specify a displacement that is added to all data as it is added to the destination region. The displacement MUST be specified as "<x,y,z>". So, for instance, to load an OAR from a 256x256 region into the middle of a larger 512x512 region, the parameter would be <tt>--displacement "<128,128,0>"</tt>. Note that you can specify a "Z" displacement which will move the objects up or down. Thus <tt>--displacement "<0,0,1000>"</tt> will put all the OAR's objects up high for a sky box.

The displacement is also applied to the terrain if it is included. The 'z' component is added to the terrain's heights.
|-
|
| 0.9
| Displacement is the offset into the destination region after the data from the source region has been rotated and cropped.
|-
| <tt>--no-objects</tt>
| 0.8
| Don't load any scene objects.
|-
| <tt>--force-terrain</tt>
| 0.8
| Force terrain loading on --merge.  Normally, --merge does not overwrite the existing region's terrain.
|-
| <tt>--force-parcels</tt>
| 0.8
| Force parcel loading on --merge.  Normally, --merge does not overwrite the existing region's parcel data.
|-
| <tt>--default-user "<first-name> <last-name>"</tt>
| 0.8
| Instead of setting object ownership to the estate owner, assign it to the named user.  This only applies to objects that have UUIDs that do not match any user account in the receiving grid's installation.  There is currently no option that will force a change of owner for all loaded objects no matter whether they match a user in the receiving installation.  One workaround to achieve this would be to save the OAR with the --publish "save oar" option to strip owner information and then reload it.
|-
| <tt>--debug</tt>
| 0.9
| When --debug is specified the command will output more information onto the console about where objects and parcels are being placed
|}

== Notes On Regions of Different Sizes ==
With the addition of regions that have a size that can be a multiple of 256x256 (i.e. a [[VarRegion]]) there is the possibility of loading OARs to and from regions of different sizes.
The load oar command now fully supports this and will load both smaller regions into larger ones and (cut out) pieces of larger regions into smaller ones. Parcel data is now handled correctly too.

= Example Uses =

== Replacing a region's contents with what's in an OAR file ==
Replacing a region with an OAR file for a region of the same size is as simple as:

 <tt>load oar NewRegion.oar</tt>

== Merging together four region's worth of contents ==
Say you have four adjacent 256x256 region ('Region00.oar', 'Region01.oar', ...) and you want to load them into a new 512x512 [[VarRegion]] ('BiggerRegion'). The commands would be:

 <tt>change region BiggerRegion</tt>
 <tt>load oar Region0.oar</tt>
 <tt>load oar --merge --force-terrain --force-parcels --displacement <0,256,0> Region01.oar</tt>
 <tt>load oar --merge --force-terrain --force-parcels --displacement <256,0,0> Region10.oar</tt>
 <tt>load oar --merge --force-terrain --force-parcels --displacement <256,256,0> Region11.oar</tt>

== Loading a 256x256 region's contents into the middle of a 512x512 sized region ==
If you have an OAR file for a 256x256 region ('LegacyRegion.oar' for instance) and you want to set it into the middle of a 512x512 region with the loaded region rotated by 30 degrees without messing up the rest of the larger region, the command would be:

 <tt>load oar --merge --force-terrain --force-parcels --displacement <128,128,0> --rotation 30.0 LegacyRegion.oar</tt>

== Loading part of a 512x512 VarRegion into a standard 256x256 sized region ==
Say you have a 512x512 VarRegion with an island in the middle that's about the size of standard region (256x256m), you could use the following command to rotate it, cut it out and place it in the standard region:

 <tt>load oar --rotation 90 --bounding-origin <128,128,0> --bounding-size <256,256,4096> VarRegion.oar</tt>

= Visualising how it works =

The new 'load oar' parameters work in the following order and this is *important to remember*:

<tt>--rotation</tt> -359 to +359 degress. The source region is rotated by the desired amount anticlockwise in degrees. If not specified then no rotation takes place. (This may result in a intermediate source region that is 25% bigger, depending on the rotation amount, but the coordinate system is maintained)

<tt>--bounding-origin <x, y, z></tt>
<tt>--bounding-size <x, y, z></tt> The (possibly rotated) source region is then cropped to a cube or rectangular cuboid defined by the coordinates given.

The resultant cuboid will then be placed at <tt><0, 0, 0></tt> in the destination region unless modified by:

<tt>--displacement <x, y, z></tt> The rotated and cropped data is offset into the destination region by this amount.


Some things to note:

<tt>--rotation</tt> applies to all of the source region's data, that is terrain, parcels and objects (prims). Both terrain, and even more so, parcels do not rotate well using arbitary rotations like 45 degrees as the edges will become jagged, but it's still supported.

The following four diagrams attempt to show examples of the work flow for various combinations of source and destination region sizes:

http://imagebin.ca/2NZGoAZffOgl/standard-to-standard.png

http://imagebin.ca/2NZJfk0nsoap/standard-to-var.png

http://imagebin.ca/2NZJxXOH6lue/var-to-standard.png

http://imagebin.ca/2NZKAL35VFdk/var-to-var.png