Load Oar 0.9.0+/de
From OpenSimulator
 |
Languages: |
|
Contents |
Load Oar Konsolenbefehle
Diese Seite enthält Informationen über den Konsolenbefehl 'load oar' des OpenSimulator ab der Version 0.9.0.
Hinweis: Wenn Sie eine Version vom OpenSimulator vor 0.9.0 verwenden, dann bitte die ursprüngliche Seite verwenden.
Parameter
Der load oar Befehl in der OpenSimulator Version 0.9.0 hat das Format:
load oar [Parameter] OARDATEI.OAR
Die Datei OARDATEI.OAR muss gegeben falls den ganzen Dateipfad beinhalten. Parameter muss nicht angegeben werden, es können aber mehrere Parameter angegeben werden. Auflistung:
| Parameter | Since Version | Description |
|---|---|---|
| --merge | 0.6.8 | Specify to merge the contents of the reading OAR with the existing contents in the region. |
| --skip-assets | 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 --skip-assets 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. |
| --rotation | 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. |
| --rotation-center | 0.8, but deprecated 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 |
| --bounding-origin | 0.9 | The SW corner of a bounding cubiod that is used to 'cut out' data from the source OAR |
| --bounding-size | 0.9 | The size of the bounding cuboid used to 'cut out' data from the source OAR |
| --displacement | 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 --displacement "<128,128,0>". Note that you can specify a "Z" displacement which will move the objects up or down. Thus --displacement "<0,0,1000>" 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. | |
| --no-objects | 0.8 | Don't load any scene objects. |
| --force-terrain | 0.8 | Force terrain loading on --merge. Normally, --merge does not overwrite the existing region's terrain. |
| --force-parcels | 0.8 | Force parcel loading on --merge. Normally, --merge does not overwrite the existing region's parcel data. |
| --default-user "<first-name> <last-name>" | 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. |
| --debug | 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:
load oar NewRegion.oar
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:
change region BiggerRegion load oar Region00.oar load oar --merge --force-terrain --force-parcels --displacement <0,256,0> Region01.oar load oar --merge --force-terrain --force-parcels --displacement <256,0,0> Region10.oar load oar --merge --force-terrain --force-parcels --displacement <256,256,0> Region11.oar
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:
load oar --merge --force-terrain --force-parcels --rotation 30 --displacement <128,128,0> LegacyRegion.oar
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:
load oar --rotation 90 --bounding-origin <128,128,0> --bounding-size <256,256,4096> VarRegion.oar
Visualising how it works
The new 'load oar' parameters work in the following order and this is *important to remember*:
--rotation -359 to +359 degress. The source region is rotated by the desired amount anticlockwise in degrees. If not specified then no rotation takes place. The coordinates within the source region are the same after rotation, so for example the middle of a 256x256 region will still be at <128, 128> after a 45 degree rotation, but the original SW corner will now be at new coordinates <128, -53>.
--bounding-origin <x, y, z> --bounding-size <x, y, z> 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 <0, 0, 0> in the destination region unless modified by:
--displacement <x, y, z> The rotated and cropped data is offset into the destination region by this amount.
Some things to note:
--rotation 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.
In Pictures
The following four diagrams attempt to show examples of the work flow for various combinations of source and destination region sizes:
