OpenSimulator - User contributions [en]

0.9.0.0 Release

2016-07-06T12:55:47Z

Jak.daniels: /* Archives */

{{Languages|0.9.0.0_Release}}
=Release Notes=
== General ==
Welcome to OpenSimulator 0.9.0.0, an open-source multi-user 3D virtual environment and metaverse server platform.

As ever, OpenSimulator is a highly complex system. Various usage scenarios (standalone, grid, hypergrid, etc.) in combination with different dependencies (e.g. different versions of mono on Linux/Mac) can sometimes produce unexpected or unstable behaviour.

If you are upgrading from a previous version of OpenSimulator, then we strongly recommend that you start off with the default configuration files and port over any changes you made to your older version of OpenSimulator.

You can download this release of OpenSimulator from [[Download]]

== Pivot Release: 0.8.2.1 ==

Due to database migration renumbering, if you are upgrading from a version of OpenSimulator prior to 0.8.2.1, then you MUST first upgrade to *0.8.2.1* and then proceed to upgrade to 0.9.0.0.

== Known issues ==
* For outstanding bugs please see the OpenSimulator Mantis bug tracker.

== Requirements ==
OpenSimulator requires:

* .NET Framework 4 when running under Windows.
* At least Mono 2.8 when running under Mono (Linux or Mac). However, we recommend using at least Mono 2.10 as Mono 2.8.x has been reported as less stable in some situations when running OpenSimulator. Mono 3 has also been reported as working well with OpenSimulator.

== Backwards Compatibility Notices ==

=== Database ===

=== Scripts ===

Scripts may need to be recompiled when upgrading to 0.9.0.0. If you see script errors on the server console, the best course of action is to delete the script dlls that live under the ScriptEngine folder. Note: do not delete the .state files in those folders; all other file extensions can be deleted.

Alternatively, you can set
DeleteScriptsOnStartup = true
once, then switch it back.

== Changes and Fixes ==

=== General Robust Server ===

=== General Simulator Server ===

=== Archives ===

* The Load Oar command now fully supports the loading of (selectable parts of) a var region into a normal sized region as well as loading standard regions anywhere into a var region.
* Parcel data is now dealt with properly and supports rotations just like terrain and objects
* There are some changes to the parameters to Load Oar which are documented here: http://opensimulator.org/wiki/Load_Oar_0.9.0%2B

=== Avatars ===

=== Classifieds ===

=== Configuration ===

* New configuration variable under [EntityTransfer]: LandingPointBehavior. Possible values are LandingPointBehavior_OS and LandingPointBehavior_SL. This option exists to control the behavior of teleporting gods into places that have landing points and telehubs. Historically, there has been a difference: OpenSim (OS) has honored landing points and telehubs even for avatars with god permissions; SL lets gods land wherever they want. Default is LandingPointBehavior_OS.

=== Friends ===

* No significant changes in this release.

=== Groups ===

=== Hypergrid ===

=== Instant Messaging ===

=== Inventory ===

=== Map ===

=== Mesh/Sculpt ===

* No significant changes in this release.

=== Monitoring ===
* No significant changes in this release.

=== NPC ===
* No significant changes in this release.

=== Objects ===

=== Physics ===

* ODE Now supports variable-sized regions
* New ODE-based physics module: ubODE. This one came from avination and seems to support more advanced physics features.

=== Profiles ===

=== Region/Estates/Parcels ===

* No significant changes in this release.

=== Region Cross/Teleport ===

* No significant changes in this release.

=== Scripting ===

* llCastRay: with ubODE, this function finally works reliably in detecting large prims and meshes

=== Services ===

=== Sound ===

* No significant changes in this release.

=== Stats ===

=== Terrain ===

* No significant changes in this release.

=== Voice ===
* No significant changes in this release.

=== Tests ===

* No significant changes

== Acknowledgements ==

Many, many thanks to all the developers, testers and community members who contributed to this release and who help out with OpenSimulator generally. Your hard work makes this all possible.

[[Category:Release Notes]]

0.9.0.0 Release

2016-07-06T12:29:38Z

Jak.daniels: /* Archives */

{{Languages|0.9.0.0_Release}}
=Release Notes=
== General ==
Welcome to OpenSimulator 0.9.0.0, an open-source multi-user 3D virtual environment and metaverse server platform.

As ever, OpenSimulator is a highly complex system. Various usage scenarios (standalone, grid, hypergrid, etc.) in combination with different dependencies (e.g. different versions of mono on Linux/Mac) can sometimes produce unexpected or unstable behaviour.

If you are upgrading from a previous version of OpenSimulator, then we strongly recommend that you start off with the default configuration files and port over any changes you made to your older version of OpenSimulator.

You can download this release of OpenSimulator from [[Download]]

== Pivot Release: 0.8.2.1 ==

Due to database migration renumbering, if you are upgrading from a version of OpenSimulator prior to 0.8.2.1, then you MUST first upgrade to *0.8.2.1* and then proceed to upgrade to 0.9.0.0.

== Known issues ==
* For outstanding bugs please see the OpenSimulator Mantis bug tracker.

== Requirements ==
OpenSimulator requires:

* .NET Framework 4 when running under Windows.
* At least Mono 2.8 when running under Mono (Linux or Mac). However, we recommend using at least Mono 2.10 as Mono 2.8.x has been reported as less stable in some situations when running OpenSimulator. Mono 3 has also been reported as working well with OpenSimulator.

== Backwards Compatibility Notices ==

=== Database ===

=== Scripts ===

Scripts may need to be recompiled when upgrading to 0.9.0.0. If you see script errors on the server console, the best course of action is to delete the script dlls that live under the ScriptEngine folder. Note: do not delete the .state files in those folders; all other file extensions can be deleted.

Alternatively, you can set
DeleteScriptsOnStartup = true
once, then switch it back.

== Changes and Fixes ==

=== General Robust Server ===

=== General Simulator Server ===

=== Archives ===

* The Load Oar command now fully supports the loading of (selectable parts of) a var region into a normal sized region.
* Parcel data is now dealt with properly and supports rotations just like terrain and objects
* There are some changes to the parameters to Load Oar which are documented here: http://opensimulator.org/wiki/Load_Oar_0.9.0%2B

=== Avatars ===

=== Classifieds ===

=== Configuration ===

* New configuration variable under [EntityTransfer]: LandingPointBehavior. Possible values are LandingPointBehavior_OS and LandingPointBehavior_SL. This option exists to control the behavior of teleporting gods into places that have landing points and telehubs. Historically, there has been a difference: OpenSim (OS) has honored landing points and telehubs even for avatars with god permissions; SL lets gods land wherever they want. Default is LandingPointBehavior_OS.

=== Friends ===

* No significant changes in this release.

=== Groups ===

=== Hypergrid ===

=== Instant Messaging ===

=== Inventory ===

=== Map ===

=== Mesh/Sculpt ===

* No significant changes in this release.

=== Monitoring ===
* No significant changes in this release.

=== NPC ===
* No significant changes in this release.

=== Objects ===

=== Physics ===

* ODE Now supports variable-sized regions
* New ODE-based physics module: ubODE. This one came from avination and seems to support more advanced physics features.

=== Profiles ===

=== Region/Estates/Parcels ===

* No significant changes in this release.

=== Region Cross/Teleport ===

* No significant changes in this release.

=== Scripting ===

* llCastRay: with ubODE, this function finally works reliably in detecting large prims and meshes

=== Services ===

=== Sound ===

* No significant changes in this release.

=== Stats ===

=== Terrain ===

* No significant changes in this release.

=== Voice ===
* No significant changes in this release.

=== Tests ===

* No significant changes

== Acknowledgements ==

Many, many thanks to all the developers, testers and community members who contributed to this release and who help out with OpenSimulator generally. Your hard work makes this all possible.

[[Category:Release Notes]]

Show stats

2015-12-29T14:27:49Z

Jak.daniels: /* Web access to stats */

=Introduction=

"show stats" is a new statistics gathering mechanism is slowly being added to OpenSimulator to integrate previously separate and ad-hoc mechanisms. For this system, you can see a short statistics summary with the command "show stats" and a much longer list of statistics with the "show stats all" command (which unfortunately doesn't yet include those in the summary!).

Use the "help show stats" command on the console for more information.

See [[Monitoring]] for information on other statistics gathering mechanisms for OpenSimulator.

See [[Stats Manager]] for information on how to register stats with this mechanism.

=General Concepts=
The full name of a stat has three components, separated by periods (.). In order, these are

* '''category''' - The category of the stat (e.g. server, scene)
* '''container''' - The containing object for this stat. For example, on scene this is the scene name (e.g. region 1). For server, this is the component to which the stat relates (e.g. memory, processor).
* '''name''' - The stat itself. For example, ClientLogoutsDueToNoReceives or SimFPS.

= Console commands =

From the console, there are several ways to display the stats:
* <tt>show stats</tt> returns simulator statistics in a legacy format
* <tt>show stats all</tt> displays all the registered stats one line per stat.
* <tt>show stats category container</tt> displays all the stats within a particular category/container

= Recording =

Saving statistics information can be very useful for later analysis. There are commands to save both a snapshot and a continuous record of stats information. There is also a facility to fetch stats information via a URL.

== stats save console command ==
'''Command added in development code from 20th March 2014.'''

This command will save a snapshot of current statistical data to a given path. For example

# stats save stats.txt

If the file already exists, the stats will be appended.

== stats record console command ==

'''Please note that in OpenSimulator 0.7.6 this command was "debug stats record".'''

'''Unfortunately, a bug in OpenSimulator 0.8 means that the command "stats record start|stop" will not work properly and will report a usage error with the old command name. The workaround is to repeat the last command twice (e.g. "stats record start start").'''

'''This bug was fixed in OpenSimulator 0.8.0.1'''

This is an experimental facilty starting in OpenSimulator 0.7.6 which will record the results of "show stats all" to a log file every 5 seconds. The aim is to record statistical information throughout a session for later analysis. The logging is enabled with the console command. It works on both the simulator and a ROBUST instance.

# stats record start
Now recording all stats to file every 5000ms

To stop logging, either shutdown the server or use the command

# stats record stop
Stopped recording stats to file.

The log file used has the same name as the main logfile for the executable with the word "Stats" appended. For instance, turning on stats logging for OpenSim.exe will write to the file OpenSimStats.log. For Robust.exe, this will write to RobustStats.log.

Currently and in OpenSimulator 0.7.6, this logging requires entries in OpenSim.exe.config (and Robust.exe.config for Robust). If you are using your own version of these files then you will need to adapt them for the logging entries.

The performance impact of such logging should be low, though the log file size can grow quite large.

== Web access to stats ==

If <tt>[Startup]ManagedStatsRemoteFetchURI</tt> is defined and set to some value, the simulator statistics are available over the web via HTTP GET operations. The URL is the simulator's HTTP server URL appended with the value in <tt>ManagedStatsRemoteFetchURI</tt>.

The URL fetched accepts four different query parameters:

* '''cat''' which specifies a category to fetch. If no category is given, the special category "all" is use which return all categories;
* '''cont''' specified a container. If not specified, the special container "all" is used to return all containers
* '''stat''' specifies the name of the particular stat. If not specified, the stat "all" is used to return all stats.
* '''callback''' specifies if the returned JSON data is to be wrapped in a callback function.

For instance, for a simulator at IP address 10.1.1.4 with the INI settings:

<pre>
[Network]
http_listener_port=9000
[Startup]
ManagedStatsRemoteFetchURI=ManagedStats
</pre>

example data fetches are:

; wget http://10.1.1.4:9000/ManagedStats/
: returns all stats registered in the simulator
; wget http://10.1.1.4:9000/ManagedStats/?cat=server
: returns all stats registered with the category "server"
; wget http://10.1.1.4:9000/ManagedStats/?cat=server&cont=threadpool
: returns all stats for the "threadpool" container within the "server" category
; wget http://10.1.1.4:9000/ManagedStats/?cat=server&cont=threadpool&stat=STPMinThreads
: returns the value for the specific stat

The data is returned in JSON format grouped as you might expect with maps of categories containing maps of containers containing maps of stats. For instance, the response to <tt>http://10.1.1.4:9000/ManagedStats/?cat=server&cont=threadpool</tt> might look like:

<pre>
{"server":
{"threadpool":
{"BuiltinThreadpoolIOCPThreadsAvailable":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"BuiltinThreadpoolIOCPThreadsAvailable",
"Name":"BuiltinThreadpoolIOCPThreadsAvailable",
"Description":"BuiltinThreadpoolIOCPThreadsAvailable",
"UnitName":"threads",
"Value":1000.0
},
"BuiltinThreadpoolWorkerThreadsAvailable":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"BuiltinThreadpoolWorkerThreadsAvailable",
"Name":"BuiltinThreadpoolWorkerThreadsAvailable",
"Description":"BuiltinThreadpoolWorkerThreadsAvailable",
"UnitName":"threads",
"Value":499.0
},
"STPActiveThreads":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPActiveThreads",
"Name":"STPActiveThreads",
"Description":"STPActiveThreads",
"UnitName":"threads",
"Value":15.0
},
"STPConcurrency":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPConcurrency",
"Name":"STPConcurrency",
"Description":"STPConcurrency",
"UnitName":"threads",
"Value":45.0
},
"STPInUseThreads":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPInUseThreads",
"Name":"STPInUseThreads",
"Description":"STPInUseThreads",
"UnitName":"threads",
"Value":0.0
},
"STPMaxThreads":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPMaxThreads",
"Name":"STPMaxThreads",
"Description":"STPMaxThreads",
"UnitName":"threads",
"Value":45.0
},
"STPMinThreads":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPMinThreads",
"Name":"STPMinThreads",
"Description":"STPMinThreads",
"UnitName":"threads",
"Value":15.0
},
"STPWorkItemsWaiting":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPWorkItemsWaiting",
"Name":"STPWorkItemsWaiting",
"Description":"STPWorkItemsWaiting",
"UnitName":"threads",
"Value":0.0
}
}
}
}
</pre>

= Analysis =
Tools to analyze record stats data are under development at https://github.com/justincc/opensimulator-tools/tree/master/analysis/opensimulator-stats-analyzer. This includes summary and graphing tools.

=Types=

There are currently three types of statistic.

== Number ==
This is just a number, possibly with a unit. For example

server.threadpool.STPActiveThreads : 15 threads

== Change over time ==
This is a number that also shows the last delta between samples and also a moving average of deltas over the last 20 samples, each taken 5 seconds apart. For example

clientstack.test one.IncomingUDPReceivesCount : 98, 1.2/s, 1.7/s

== Percentage ==
This is a percentage with the antecedent and consequent also given. For example

clientstack.test one.PacketsReused : 37.91% (116/306)

=Statistics=

'''This information is highly subject to change as suitable data gathering is an evolving area. Need to keep adding stats.'''

==clientstack==

These are stats for the LLUDP clientstack that sends and receives UDP messages for viewers connected with the Second Life protocol. Each stats with clientstack.<region-name>.

{| border="1"
! Stat name !! Units !! Description
|-
| InboxPacketsCount || messages || The number of messages that have been pre-processed by an inbound network thread but are now waiting to be processed by the main Incoming Packets thread. If this number exceeds 0 for more than one sample then your simulator cannot cope with the number of UDP messages that clients are sending. Region performance will be degraded from the user perspective.
|-
| IncomingPacketPoolCount || messages || The number of packet objects currently in the memory pool to deal with incoming messages. This pool is used to reduce memory churn and hence improve simulator performance. The actual number is never an issue since OpenSimulator will create new pool objects as required.
|-
| IncomingPacketsMalformedCount || messages || Number of malformed packets that the simulator received from viewers. A high and increasing number may indicate a network attack.
|-
| IncomingPacketsOrphanedCount || messages || Number of well-formed packets that the simulator received but did not relate to any currently logged in viewer. Because viewers can disconnect in the middle of a datastream, we would expect to see a certain number of such packets in the course of normal operation. However, if the number is very high (e.g. tens of thousands) and/or increasing then this may indicate a network attack.
|}

==httpserver==

These are stats for OpenSimulator's built-in HTTP server. Statistics are partitioned (contained) by the incoming port number to which they relate. For example, httpserver.8002.HTTPRequestsServed are all the HTTP requests served that came in to port 8002.

{| border="1"
! Stat name !! Units !! Description
|-
| HTTPRequestsServed || requests || The number of HTTP requests served.
|-
| ProcessedPollResponses || responses || The number of responses sent to the viewer in response to poll requests.
|-
| QueuedPollResponses || responses || The number of responses queued for the next viewer poll.
|}

==scene==

These are stats relating to the graphical simulated scene.

Each starts with scene.<region-name>.

{| border="1"
! Stat name !! Units !! Description
|-
| RootAgents || avatars || The number of root agents in the scene. A root agent is associated with an avatar since a root agent is needed for full sim functionality (e.g. moving around).
|-
| ChildAgents || agents || The number of child agents in the scene. A child agent has limited functionality and is used by the viewer mainly to observe events in another scene (i.e. so that the user can see what's occuring in neighbouring regions).
|-
| FrameTime || ms || The amount of time taken by OpenSimulator to complete the last frame. The standard frame time is 18.18ms. In normal conditions there will be some small variation above and below this number, probably due to the low resolution of thread sleeping. This number may occasionally jump if the underlying VM (Mono or .NET) takes a long time to perform a garbage collect. If this number is consistently higher then your simulator is overloaded.
|-
| PhysicsTime || ms|| Amount of time spent performing physics engine operations in a scene frame. If this is consistently high enough to make the FrameTime exceed the 18.18ms standard then region performance will be degraded. You will need to reduce the number of physical objects in your region. For OpenSimulator 0.7.6, ODE is used single-threaded and so extra cores will make no difference to performance.
|-
| SpareTime || ms|| The amount of time that was left over after OpenSimulator had performed all operations required in the current scene loop. During this period OpenSimulator sleeps the thread.
|-
| SlowFrames || frames || In theory, this records the number of frames which took more than the standard frame time to execute. However, this measure may be buggy.
|}

==server==
These are stats relating to the server itself.

===thread===

These are the times in milliseconds since the monitored thread last performed any activity. This is the same as the "LAST UDPATE" information shown by the "show threads" command.

===threadpool===

These are server threadpool stats.

Each starts with server.threadpool.

{| border="1"
! Stat name !! Units !! Description
|-
| BuiltinThreadpoolIOCPThreadsAvailable || threads || The number of pooled thread objects waiting to handle incoming IO requests. OpenSimulator sets this to a very high number by default. If you ever see this approach zero then your simulator is severely overloaded with respect to processing raw incoming IO requests.
|-
| BuiltinThreadpoolWorkerThreadsAvailable || threads || The number of pooled thread objects in the Mono/.NET native threadpool available to handle requests. If you have async_call_method = UnsafeQueueUserWorkItem (or QueueUserWorkItem though "unsafe" is fine for our purposes) then is used for all OpenSimulator's threading requirements. If you have async_call_method = SmartThreadPool (which is the current default), then SmartThreadPool handles all the heavy thread launching requirements (and so see the server.threadpool.STP* stats). If this figure approaches zero then you simulator is severely overloaded.
|-
| STPInUseThreads || threads || The number of SmartThreadPool threads currently in use. If this climbs to the maximum allowed by STPMaxThreads then the simulator will experience general performance degradation. In this case, try increasing the MaxPoolThreads setting in the [Startup] section of OpenSim.ini (e.g. to 150).
|-
| STPMaxThreads || threads || Maximum number of threads that the SmartThreadPool will use. This is set by the MaxPoolThreads setting in the [Startup] section of OpenSim.ini (or OpenSimDefaults.ini).
|-
| STPWorkItemsWaiting || items || The number of work items waiting because all SmartThreadPool threads are busy with current work items. You will see this start to climb if STPInUseThreads == STPMaxThreads. You never want to see this situation - if you have work items waiting then try increasing your MaxPoolThreads setting.
|}

User:Jak.daniels

2015-11-23T18:54:48Z

Jak.daniels: Replaced content with "{{Quicklinks}}"

User:Jak.daniels

2015-11-23T18:54:27Z

Jak.daniels: Jak Daniels

{{Quicklinks}}

= 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 --displacement <0,256,0> Region01.oar</tt>
<tt>load oar --merge --force-terrain --displacement <256,0,0> Region10.oar</tt>
<tt>load oar --merge --force-terrain --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 --rotation-center <128,128,0> LegacyRegion.oar</tt>

Load Oar 0.9.0+

2015-11-23T18:52:29Z

Jak.daniels: /* Loading a 256x256 region's contents into the middle of a 512x512 sized region */

{{Quicklinks}}

= 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, terrain and parcels already in the region.

'''Note: If you are using a version of OpenSimulator less than 0.9.0 then please see the original [[Load Oar]] page.'''

== 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 Version
! 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 --rotation 30 --displacement <128,128,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. 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>.

<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.

== In Pictures ==
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

Load Oar 0.9.0+

2015-11-23T18:49:27Z

Jak.daniels: /* Parameters */

{{Quicklinks}}

= 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, terrain and parcels already in the region.

'''Note: If you are using a version of OpenSimulator less than 0.9.0 then please see the original [[Load Oar]] page.'''

== 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 Version
! 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. 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>.

<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.

== In Pictures ==
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

Load Oar 0.9.0+

2015-11-23T18:48:55Z

Jak.daniels: /* Load Oar Console Command */

{{Quicklinks}}

= 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, terrain and parcels already in the region.

'''Note: If you are using a version of OpenSimulator less than 0.9.0 then please see the original [[Load Oar]] page.'''

== 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. 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>.

<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.

== In Pictures ==
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

Load Oar

2015-11-23T18:47:55Z

Jak.daniels: /* Merging together four region's worth of contents */

{{Quicklinks}}

= Load Oar Console Command =
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.

'''Note: As of Opensimulator 0.9.0-dev the 'load oar' has changed slightly in order to support more features. Please see the [[Load Oar 0.9.0+]] page.'''

== Parameters ==
The load oar command 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
|-
| --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 <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.
|-
| --displacement
| 0.8
| Specify a displacement that is added to all objects in the OAR file as they are added to the 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.
|-
| --rotation
| 0.8
| The degrees to rotate all the objects loaded from the OAR.
|-
| --rotation-center
| 0.8
| The center around which to rotate objects on load.
|-
| --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.
|}

== 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. In general, loading an OAR from a smaller region into a larger region will do what you expect. Trying to load a larger region into a smaller region will generate many errors although, if you have adjacent smaller regions, some of the objects will be loaded into the adjacent regions. Try at your own risk.

= 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 --displacement <0,256,0> Region01.oar</tt>
<tt>load oar --merge --force-terrain --displacement <256,0,0> Region10.oar</tt>
<tt>load oar --merge --force-terrain --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 --rotation-center <128,128,0> LegacyRegion.oar</tt>

Load Oar

2015-11-23T18:47:44Z

Jak.daniels: /* Notes On Regions of Different Sizes */

{{Quicklinks}}

= Load Oar Console Command =
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.

'''Note: As of Opensimulator 0.9.0-dev the 'load oar' has changed slightly in order to support more features. Please see the [[Load Oar 0.9.0+]] page.'''

== Parameters ==
The load oar command 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
|-
| --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 <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.
|-
| --displacement
| 0.8
| Specify a displacement that is added to all objects in the OAR file as they are added to the 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.
|-
| --rotation
| 0.8
| The degrees to rotate all the objects loaded from the OAR.
|-
| --rotation-center
| 0.8
| The center around which to rotate objects on load.
|-
| --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.
|}

== 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. In general, loading an OAR from a smaller region into a larger region will do what you expect. Trying to load a larger region into a smaller region will generate many errors although, if you have adjacent smaller regions, some of the objects will be loaded into the adjacent regions. Try at your own risk.

= 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 --displacement <0,256,0> Region01.oar</tt>
<tt>load oar --merge --force-terrain --displacement <256,0,0> Region10.oar</tt>
<tt>load oar --merge --force-terrain --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 --rotation-center <128,128,0> LegacyRegion.oar</tt>

Load Oar 0.9.0+

2015-11-23T18:47:20Z

Jak.daniels: /* Loading part of a 512x512 VarRegion into a standard 256x256 sized region */

{{Quicklinks}}

= 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.

'''Note: If you are using a version of OpenSimulator less than 0.9.0 then please see the original [[Load Oar]] page.'''

== 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. 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>.

<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.

== In Pictures ==
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

Load Oar 0.9.0+

2015-11-23T18:46:44Z

Jak.daniels: /* Merging together four region's worth of contents */

{{Quicklinks}}

= 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.

'''Note: If you are using a version of OpenSimulator less than 0.9.0 then please see the original [[Load Oar]] page.'''

== 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. 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>.

<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.

== In Pictures ==
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

Load Oar 0.9.0+

2015-11-23T18:46:21Z

Jak.daniels: /* Notes On Regions of Different Sizes */

{{Quicklinks}}

= 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.

'''Note: If you are using a version of OpenSimulator less than 0.9.0 then please see the original [[Load Oar]] page.'''

== 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. 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>.

<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.

== In Pictures ==
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

Load Oar 0.9.0+

2015-11-23T18:44:37Z

Jak.daniels: /* Load Oar Console Command */

{{Quicklinks}}

= 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.

'''Note: If you are using a version of OpenSimulator less than 0.9.0 then please see the original [[Load Oar]] page.'''

== 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. 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>.

<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.

== In Pictures ==
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

Load Oar 0.9.0+

2015-11-23T18:42:22Z

Jak.daniels: /* Load Oar Console Command */

= 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.

'''Note: If you are using a version of OpenSimulator less than 0.9.0 then please see the original [[Load Oar]] page.'''

== 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. 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>.

<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.

== In Pictures ==
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

Load Oar

2015-11-23T18:41:09Z

Jak.daniels: /* Load Oar Console Command */

{{Quicklinks}}

= Load Oar Console Command =
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.

'''Note: As of Opensimulator 0.9.0-dev the 'load oar' has changed slightly in order to support more features. Please see the [[Load Oar 0.9.0+]] page.'''

== Parameters ==
The load oar command 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
|-
| --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 <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.
|-
| --displacement
| 0.8
| Specify a displacement that is added to all objects in the OAR file as they are added to the 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.
|-
| --rotation
| 0.8
| The degrees to rotate all the objects loaded from the OAR.
|-
| --rotation-center
| 0.8
| The center around which to rotate objects on load.
|-
| --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.
|}

== 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. In general, loading an OAR from a smaller region into a larger region will do what you expect. Trying to load a larger region into a smaller region will generate many errors although, if you have adjacent smaller regions, some of the objects will be loaded into the adjacent regions. Try at your own risk.

= 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 --displacement <0,256,0> Region01.oar</tt>
<tt>load oar --merge --force-terrain --displacement <256,0,0> Region10.oar</tt>
<tt>load oar --merge --force-terrain --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 --rotation-center <128,128,0> LegacyRegion.oar</tt>

Load Oar 0.9.0+

2015-11-23T18:19:11Z

Jak.daniels: /* Visualising how it works */

= 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. 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>.

<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.

== In Pictures ==
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

Load Oar 0.9.0+

2015-11-23T18:17:33Z

Jak.daniels: /* Visualising how it works */

= 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. 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>.

<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

Load Oar 0.9.0+

2015-11-23T18:16:31Z

Jak.daniels: /* Visualising how it works */

= 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. 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, -106>.

<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

Load Oar 0.9.0+

2015-11-23T18:11:24Z

Jak.daniels: /* Loading part of a VarRegion into a standard sized region */

= 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

Load Oar 0.9.0+

2015-11-23T18:06:51Z

Jak.daniels: /* Parameters */

= 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 VarRegion into a standard 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

Load Oar 0.9.0+

2015-11-23T18:05:13Z

Jak.daniels: /* Visualising how it works */

= 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
|-
| --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 <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.
|-
| --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 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
|-
| --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 <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.
|-
| --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:

<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 VarRegion into a standard 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

Load Oar 0.9.0+

2015-11-23T18:00:58Z

Jak.daniels: /* Visualising how it works */

= 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
|-
| --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 <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.
|-
| --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 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
|-
| --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 <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.
|-
| --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:

<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 VarRegion into a standard 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 following four diagrams attempt to show examples of the workflow 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

Load Oar 0.9.0+

2015-11-23T16:42:34Z

Jak.daniels: /* Load Oar Console Command */

= 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
|-
| --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 <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.
|-
| --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 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
|-
| --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 <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.
|-
| --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:

<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 VarRegion into a standard 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 following four diagrams attempt to show examples of the workflow for various combinations of source and destination region sizes:

Load Oar 0.9.0+

2015-11-23T16:34:04Z

Jak.daniels: Created page with "= 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 fi..."

User:Jak.daniels

2015-11-23T16:11:56Z

Jak.daniels: Created page with "{{Quicklinks}} = Load Oar Console Command = Once you have saved regions in OAR files, the 'load oar' console command will load the OAR file into the current region. There are..."

{{Quicklinks}}

= Load Oar Console Command =
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.

As of version 0.9.0-dev, the parameters and functionality have changed slightly to allow inporting selected data from larger regions into smaller ones. Please see the new Load Oar page [[Load Oar 0.9.0+]] here

== Parameters ==
The load oar command 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
|-
| --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 <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.
|-
| --displacement
| 0.8
| Specify a displacement that is added to all objects in the OAR file as they are added to the 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.
|-
| --rotation
| 0.8
| The degrees to rotate all the objects loaded from the OAR.
|-
| --rotation-center
| 0.8, but depricated in 0.9
| The center around which to rotate objects on load.
|-
| --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
|-
| --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.
|}

== 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. In general, loading an OAR from a smaller region into a larger region will do what you expect. Trying to load a larger region into a smaller region will generate many errors although, if you have adjacent smaller regions, some of the objects will be loaded into the adjacent regions. Try at your own risk.

= 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 --displacement <0,256,0> Region01.oar</tt>
<tt>load oar --merge --force-terrain --displacement <256,0,0> Region10.oar</tt>
<tt>load oar --merge --force-terrain --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 --rotation-center <128,128,0> LegacyRegion.oar</tt>

Varregion/fr

2015-01-10T12:45:40Z

Jak.daniels: correct the spelling of options --force-terrain --force-parcels

{{Languages|Varregion}}

'''Varregion'''
__TOC__

"Varregion" est un dispositif d'OpenSimulator qui permet d'installer des régions d'une taille supérieure à 256x256. La région sera simplement plus grande, elle se comportera comme une région normale avec des frontières plus éloignées.L'implémentation de ce dispositif utilise le protocole de l'extension des grandes régions de [http://aurora-sim.org Aurora] . Aussi, les versions actuelles des viewers [http://firestormviewer.org Firestorm] et [http://singularityviewer.org Singularity] utilisées par Aurora seront également compatibles avec les varregions d'OpenSimulator.Les varregions sont différentes des [[Megaregions]], ancien dispositif d'installation de grandes régions. Les mégarégions ne nécessitent pas de viewer particulier ( avec des fonctions non mises en œuvre par Linden Lab) mais elles reposent sur un certain nombre de hacks fragiles mis en place pour utiliser les viewers d'une manière que Linden Lab n'avait pas prévue. Les mégarégions contiennent également un certain nombre de bogues côté simulateur.Une liste croissante de modifications sont mises en oeuvre par le [[varregion/Protocol|Protocole Varregion]] pour implementer les"varregions".

==Restrictions==
'''Quelques restrictions s'appliquent :'''
*les '''dimensions''' des régions doivent être un multiple de 256 et être inférieures ou égales à 8192.
*la région doit être '''carrée''' (à partir du 04 novembre 2013).
*'''Les régions adjacentes''' doivent avoir la même taille. Par exemple, vous pouvez avoir plusieurs régions de 512x512 l'une à côté de l'autre (et voir dans l'autre région transfrontalière). Il semble y avoir un problème au niveau des viewers. Si des régions de taille différentes sont à portée de vue, des crashes se produisent. Prévoyez d'avoir des régions de même taille dans la même "vue". Rappellez-vous que les coordonnées d'une région sont référencées sur une base de 256 mètres. Ainsi un groupe de quatre régions de 512x512 aurait par exemple pour coordonnées 8000/8000, 8000/8002, 8002/8000 et 8002/8002.
*Vous devez utiliser '''BulletSim''' (depuis le 04 novembre 2013, ODE n'a pas été mis à jour pour les varregions.)
*Vous devez utiliser l'implémentation des cartes de niveaux (heightmap) de BulletSim. Depuis le 28 janvier 2014, BulletSim a été modifié pour forcer le chargement des heightmap des terrains si la taille des régions est supérieure à 256 sur un côté. La configuration peut être forcée en ajoutant à vos fichiers INI :

[BulletSim]
TerrainImplementation = 0

==Configuration==
La taille des régions est indiquées dans le fichier Region.ini :
[MyRegionName]
RegionUUID = 95ec77ec-58c5-4ce2-9ff3-b6d1900d78a2
Location = 1000,1000
SizeX = 1024
SizeY = 1024
InternalAddress = 0.0.0.0
InternalPort = 9200
AllowAlternatePorts = False
ExternalHostName = SYSTEMIP

*Si la taille n'est pas spécifiée, bien entendu, elle sera par défaut définies à 256x256.
*Si les dimensions renseignées ne respectent pas les restrictions, des valeurs acceptables seront calculées et des messages d'alerte et d'erreur seront envoyés dans le log.
*Si vous convertissez une mégarégion, n'oubliez pas de placer dans votre configuration :
CombineContiguousRegions = false
Pour que la fonction '''llRezObject''' fonctionne au-delà de 256 mètres écrivez dans la section [Xengine] de Opensim.ini (pour une région de 512mx512m)
ScriptDistanceLimitFactor = 512.0
*La heightmap est enregistrée dans la base de données sous la forme d'un tableau de 'shorts" (deux octets), aussi, si vous avez une très grande région vous pourriez avoir besoin d'augmenter la taille maximum dans la base de données . Par exemple, une région de 2816x2816 (11x11 régions normales) va utiliser une heightmap de 56 mo. Pour MySQL, vous devrez définir max_allowed_packet à quelque chose comme 64M (fichier /etc/mysql/my.cnf pour Ubuntu).

==Charger un terrain ==
Les commandes de console habituelles fonctionnent pour les varregions. Si vous avez configurer une grande régions , vous pouvez charger des fichiers de heightmap BMP/RAW/PNG avec les dimensions de la région et couvrir l'ensemble du terrain. Par exemple, une région de 1024x1024 sera complètement initialisée après le chargement de "1024.bmp" si "1024.bmp" est un bitmap de 1024x1024.

==Varregions et les fichiers OAR==

Les objets et les terrains sont stockés dans des fichiers OAR comme si c'était une seule région. Cela signifie que si vous avez sauvegardé une région de 1024x1024 dans un fichier OAR, vous pourrez plus tard restaurer les objets et le terrain sur une région de 1024x1024. Si vous chargez le fichier OAR d'une plus petite région dans une région plus grande, l'espace de terrain non spécifiée est par défaut de 256 mètres.

Pour rendre la conversion vers varregions plus facile, la commande 'load oar' a un nouveau paramètre '--displacement "<x,y,z>. Cela déplace tous les objets et le terrain à partir du fichier oar quand vous le chargez dans la nouvelle région.

Par exemple, disons que vous disposez de quatre régions adjacentes de 256x256 (aor00.oar, aor01.oar, aor10.oar, aor11.oar). Vous créez une nouvelle varregion de 512x512 nommée 'grosseregion'. Les commandes suivantes vont placer les objets, les terrains et les parcelles des quatres régions dans la nouvelle varregion :

change region grosseregion
load oar oar00.oar
load oar oar01.oar --displacement "<0,256,0>" --merge --force-terrain --force-parcels
load oar oar10.oar --displacement "<256,0,0>" --merge --force-terrain --force-parcels
load oar oar11.oar --displacement "<256,256,0>" --merge --force-terrain --force-parcels

Notez la présence des nouveaux paramètres "--force-terrain" and "--force-parcels". Le paramètre "--merge" utilisé par lui-même, sert à fusionner les objets des multiples OARs. La fusion supprime aussi le chargement des données du terrain et des informations des parcelles . C'est ce qu'on veut quand on fusionne les objets. Mais si vous chargez des OARs multiples pour créer une nouvelle région plus grande, les informations du terrain et des parcelles devront aussi être chargées. D'où l'utilité des nouveaux paramètres.

==Les problèmes connus==
Cette modification majeure d'OpenSimulator touche un nombre important de domaines. Les chapitres qui suivent présentent les modifications que Justin CC a du faire.

===Données du terrain ===
Un des problèmes majeur a été de passer les données des terrains à la pile de protocoles. L'implémentation existante passait un tableau de floats qui représentaient un tableau de 256x256 hauteurs de terrain. La classe TerrainChannel ne peut pas être passée dans la pile des protocoles (llClienView) parce que TerrainChannel n'est pas défini comme faisant partie de OpenSim.Region.Framework et donc n'est pas visible par le code du protocole.

La solution choisie par JustinCC a été de créer une classe TerrainData dans OpenSim.Framework. TerrainData englobe simplement la structure des données pour le terrain et ajoute des attributs pour définir les dimensions X et Y.

Il ne voulait pas changer la signature de IClientAPI parce que beaucoup de modules externes en dépendent. IClientAPI aurait dû être modifié pour passer TerrainData plutôt qu'un float[]. JustinCC a décidé de ne pas changer IClientAPI, il a fait en sorte que LLClientView ignore le passage du tableau. À la place il l'a fait remonter dans la scène associée pour récupérer l'instance TerrainData.

Il existe une sous-classe de TerrainData: HeightmapTerrainData qui enregistre le terrain sous forme de heightmap compressée. La hauteur de chaque point est un "short" qui correspond à height * compressionFactor où compressionFactor est habituellement égal à "100". Cela crée un enregistrement compact des hauteurs de terrain avec deux décimales de résolution après la virgule.

Le LLLP ("Linden Lab Legacy Protocol") envoie les données de hauteur de terrain dans un "patches" compressé d'une surface 16x16 de hauteur de terrain. Cette partie du protocole est implémentée dans TerrainChannel. JustinCC pense que les optimisations de protocoles sous-jacents ne doivent pas apparaître dans la pile, ainsi il a essayé de cacher les tâches du terrain dans TerrainData. Il veut signifier par là qu''''un jour la création des terrains en meshs sera généralisée'''. Et il ajoute, "n'est-ce pas ?".

===Le terrain dans la base de données ===
Auparavant les heightmaps des terrains étaient enregistrées dans la base de données avec le type BLOB sous la forme d'un tableau de doubles de 256x256. Pour avoir des régions de tailles différentes, ce format a dû changer. Il y existe un champs dans la base de données actuelle qui stocke le temps auquel le terrain a été sauvegardé. Cette information n'est pas utilisée, ainsi ce champs a été choisi pour contenir le champs des blob des hauteurs issues de la refonte du code.

Il y a trois formes de blob de carte de niveaux : héritée, 2D compressée et 2D régulière. La carte de niveau par héritage correspond, bien sûre, à la collections précédentes de 256x256 doubles. La carte 2D régulière contient les dimensions X, Y suffisamment de floats pour les hauteurs de cette région. La carte 2D compressée contient les X et Y et compressionFactor suivie d'assez de "shorts" pour la carte de hauteur.

Le format par héritage est utilisé par défaut pour lire et écrire dans la base de données, si la région a des dimensions de 256x256, elle sera stockée au format hérité. Ceci pour conserver une compatibilité descendante.

Tous les modules de base de données (MySQL, SQLite, MSSQL et PSQL) ont été modifiés pour stocker les terrain de cette façon.

===Détection du passage des frontières===
La majeure partie du code de "passage vers une nouvelle région" est basé sur le contrôle des frontières. Il y a aussi pas mal de code pour calculer si un objet ou un avatar a traversé la limite d'une région et autant pour calculer l'adresse de la prochaine. L'introduction d'une taille de région variable chamboule beaucoup ces calculs. Cela signifie que le code chargé habituellement de faire ces calculs définit l'adresse de la nouvelle région et la localisation d'arrivée en se basant sur une taille constante de 256x256m. Avec les varregions ces hypothèses ne tiennent plus. L'implémentation d'une varregion signifie que le calcul de l'adresse de la région d'origine et de la localisation des frontières va être déplacé vers le service de grille GridService, entité qui connaît réellement la taille de toutes les régions.

La réalisation du calcul de localisation des régions qui est vraiment une opération GridService a conduit JustinCC a extraire complétement le code de vérification des limites de la grille pour le remplacer par deux fonctions : Scene.PositionIsInCurrentRegion(Vector3 pos) et ensuite EntityTransferModule.GetRegionContainingWorldLocation(double X, double Y). L'ancienne fonction teste si un objet / avatar est sorti de la région courante pour ensuite trouver la région de destination.''(Side note: GetRegionContainingWorldLocation should really be a function on IGridService but that exercise is left for future hacking).''

''These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on IGridService, in EntityTransferModule and a bunch of bookkeeping in Scene. This too should be cleaned up.''

==Notes d'implémentation==
Depuis le 27 Janvier 2014 varregion est une caractéristique du 'master' de la branche de référence.
===Travail à faire ===
Ce qui suit sont des notes qui concernent des domaines que JustinCC jugent nécessaires d'être travaillés.
*Consolider le code de calcul des régions voisines (Scene, EntityTransferModule et IGridService ont tous un code 'détecter le voisin').
*Nettoyer / éliminer la création de la liste des frontières et utiliser un code.

(la suite n'a pas été traduite.)

[[Category:French Translations]]

Varregion

2015-01-10T12:38:24Z

Jak.daniels: fix typos --load-parcel should be --load-parcels

{{MainPageQuicklinks}}

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

This is different from the older [[Megaregions]] large region feature which does not require extra viewer support (above that already implemented by Linden Lab) but which relies on a number of fragile hacks to make a viewer work in a way that Linden Lab never supported. Megaregions also contain a number of extant simulator-side bugs.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256 and less than or equal to 8192.
* The dimensions must be square (as of 20131104)
* Adjacent regions must be the same size. For instance, you can have multiple 512x512 regions adjacent (and see into the other region and border cross). There seems to be a viewer problem where, if regions of different size are within view distance, crashes can happen. Consider having regions of only the same size 'in view'. Remember that the region coordinates are specified in 256m region count so a group of four 512x512 regions would be specified at 8000/8000, 8000/8002, 8002/8000, and 8002/8002, for instance.
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. As of 20140128, BulletSim has been modified to force heightmap terrain implementation if region size is greater than 256 on any side. The setting can be forced by adding to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

* Because there is a lot of terrain in a varregion, it can take a while for the terrain to load into the viewer. You should set the following parameter so terrain is only loaded within an avatar's view distance and so the terrain is loaded from the avatar's position outward (rather than the 'lawn mower' pattern from the outside of the region:
<pre>
[Terrain]
SendTerrainUpdatesByViewDistance = true
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[MyRegionName]
RegionUUID = 95ec77ec-58c5-4ce2-9ff3-b6d1900d78a2
Location = 1000,1000
SizeX = 1024
SizeY = 1024
InternalAddress = 0.0.0.0
InternalPort = 9200
AllowAlternatePorts = False
ExternalHostName = SYSTEMIP
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

For llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 512.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
The usual terrain console commands work with varregions. If you have set up a larger region, you can load BMP/RAW/PNG heightmap files of the dimensions of the region and fill the whole region. For instance, a 1024x1024 region terrain would be completely initialized by "terrain load 1024.bmp" if '1024.bmp is a 1024x1024 bitmap.

==Varregions and OAR Files==
The objects and terrain are stored in an OAR file as if it was one region. That is, if you save a 1024x1024 region in an OAR file, you can later restore the objects and terrain into a 1024x1024 sized region. If you load an OAR file from a smaller region into a larger region, the unspecified terrain space will default to 25m.

To make conversion to varregions easier, [[Load_Oar|load oar]] now has a '--displacement "<x,y,z>"' parameter. This displaces all of the objects and the terrain from the oar file when loading them into the new region. For instance, say you have four OAR files from four adjacent 256x256 regions (oar00.oar, oar01.oar, oar10.oar, and oar11.oar). You create a new 512x512 varregion named 'bigregion'. The following commands place the four regions of objects, terrains and parcels
into the new larger region:

<pre>
change region bigregion
load oar oar00.oar
load oar oar01.oar --displacement "<0,256,0>" --merge --force-terrain --force-parcels
load oar oar10.oar --displacement "<256,0,0>" --merge --force-terrain --force-parcels
load oar oar11.oar --displacement "<256,256,0>" --merge --force-terrain --force-parcels
</pre>

Note the new "--force-terrain" and "--force-parcels" parameters. "--merge", used by itself, is for merging together the objects from multiple OARs. Merging also suppresses the loading of terrain and parcel data which is just what you want when merging objects. But, if loading multiple OARs to create a new, larger region, the terrain and parcel information must be loaded. Thus the new parameters.

==Things Known to be Broken==
* There is some problem with teleporting in an out of larger region. It works for some configurations and not others.
* While adjacent regions are usually viewable, sometimes they are not. They appear when you cross over into the region.

==Implementation Discussion==
Since this will be a major change to OpenSimulator that touches a
lot of different parts, subsequent posts, will discuss the changes I'm making.

===TerrainData===
One major problem is passing the terrain data from the region to the
protocol stack. The existing implementation passed an array of floats
that were presumed to be a 256x256 array of region terrain heights.
The
<tt>TerrainChannel</tt>
class is an attempt to hide the terrain implementation
from
<tt>TerrainModule</tt>
.
<tt>TerrainChannel</tt>
can't be passed into the protocol
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

My solution is to create the
<tt>TerrainData</tt>
class in
<tt>OpenSim.Framework.</tt>
<tt>TerrainData</tt>
just wraps the data structure for the terrain and additionally has
the attributes giving X and Y size.

I didn't want to change the signature of IClientAPI since so many external modules
rely on it.
It should be changed to pass <tt>TerrainData</tt> rather than a <tt>float[]</tt>.
I decided to not change IClientAPI but rather have <tt>LLClientView</tt> ignore
the passed array and instead reach back into the associated scene and fetch the
<tt>TerrainData</tt> instance.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
Most of the ‘move to new region’ code is based on checking boundaries. There is much code related to computing if an object or avatar has crossed a region boundary and then computing the address of the next region from same. Introducing variable sized regions messes a lot of this computation up. That is, the code doing the arithmetic usually assumes it knows the address of the next region based on a known region size and them can compute the location of the next region based on that. With varregions those assumptions no longer hold. Varregion implementation means that the computation of region base locations and border locations moves to the GridService who is the entity who really knows the size of all the regions and what is adjacent to what.

The realization that location to region computation is really a GridService operation lead me to totally rip apart the grid boundary checking code and replace it with two functions: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.GetRegionContainingWorldLocation(double X, double Y)</tt>. The former function tests to see if the object/avatar has moved out of the current region and the latter gets the region moved into. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Implementation Notes==

As of January 27, 2014, varregion is a feature of the 'master' repository branch.

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* ITerrainLoader implementations (mostly done)
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
** New overlay types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's
** consider creating structures for world and region coordinates so there can be compile time checking

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Related Software

2013-02-20T16:38:50Z

Jak.daniels: Added link to another optional region module: OpenSimTide

{{Quicklinks}}
{{thirdparty}}
= Introduction =
This is a page which lists software packages that are related to OpenSimulator but are not part of the core project. Opensimulator is not responsible for the content referenced by these links.

== OpenSimulator Viewers ==
See [[Connecting]].

== OpenSimulator Distributions ==
See [[Download#Other_Distributions]].

== OpenSimulator ROBUST replacements ==
These can be divided into projects that provide a completely replacement for the ROBUST services backend or can replace individual services.

=== Complete replacements ===
* [https://github.com/openmetaversefoundation/simiangrid/commits/master SimianGrid] - A ROBUST services replacement which replaces the whole ROBUST stack with an alternative implementation based on PHP. The necessary support for SimianGrid is included in core OpenSimulator.

=== Individual service replacements ===
OpenSimulator services are architected such that an individual service (e.g. the asset service) can be replaced without having to upgrade other services.

* [https://github.com/coyled/sras Simple Ruby Asset Service (SRAS)] - This is a replacement for the ROBUST asset service. It stores assets on disk, does compression and deduplication of identical assets.

== Web Interfaces==
See [[Webinterface]]

== Addon Modules ==
These are either application or region modules which can be added to the OpenSimulator core distribution to provide extra functionality.

* [https://github.com/aduffy70/Chat-Logger Chat-Logger] - An OpenSimulator region module to log chat traffic. Includes visitor alerts (when logging starts, stops, or new visitors enter the region) so the logging is transparent. Developed as a tool for meetings, training sessions, or educational environments.

* [https://github.com/JakDaniels/OpenSimTide OpenSimTide] - An OpenSimulator region module which adds tides to your regions. You can control the tide period and height change via settings in OpenSim.ini and enable tide info to be chatted to the region for use in scripts in boats and waves. Tides only render properly on regions that are not adjacent, i.e. 1x1 islands.

== Other OpenSimulator Forge Projects ==
{{content}}
OpenSimulator now has a [http://forge.opensimulator.org/gf/ forge] for related software.
* [http://forge.opensimulator.org/gf/project/osinstaller OpenSimulator Installers]
* [http://forge.opensimulator.org/gf/project/opensimwi/ OpenSimWi(Redux)]
* [http://forge.opensimulator.org/gf/project/openterrains/ Open Source Terrain Textures]
* [http://forge.opensimulator.org/gf/project/osraw/ Open Source RAW Terrain Textures]
* [http://forge.opensimulator.org/gf/project/ostray/ OSTray]
* [http://forge.opensimulator.org/gf/project/sllauncher/ SL Launcher]
* [http://forge.opensimulator.org/gf/project/openusermanual/ Open User Manual]
'''todo''' list some of the top opensim forge projects.

=== These are old projects that no longer appear to be maintained ===
* [http://forge.opensimulator.org/gf/project/deepservers/ DeepServer (ASP.NET Grid Server)]
* [http://forge.opensimulator.org/gf/project/modrex/ realXtend Modules]
* [http://forge.opensimulator.org/gf/project/ogp/ OGP Patches]

== Other related software ==
These are independent implementations of OpenSimulator services, such as the user server or the inventory server (also known as UGAI).

* [http://www.ics.uci.edu/~lopes/terraingen/ Terraingen] - Tool for producing OpenSimulator terrains from USGS DEM files.
* [[RegionGenerator]] - Generates Region XML Files
* [http://www.secondinventory.com/ Second Inventory] - A Windows based client that can be used to back up and restore objects from Second Life™ as well as from various OpenSimulator based grids. It allows you to back up objects from the Second Life™ main grid, and restore them into OpenSimulator grids. It is still a bit primitive and sometimes can be flaky.
* [http://www.metabolt.net/ METAbolt] - METAbolt is a non-graphical (text based) viewer. It's light weight and cross grid, which means it will work in Second Life™ as well as other grids that are based on OpenSIM. The viewer is Open Source so it's free. Currently METAbolt is only available for Windows platforms.
* [http://3di-opensim.com/en/ 3Di OpenSimulator Enterpise] - Business service based on OpenSimulator.
* [http://3di-rei.org/ 3Di Viewer Rei] - Web Browser based Viewer.
* [http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?sl_proxy%20%28E%29 sl_proxy] - sl_proxy is a Proxy System for Second Life™ and OpenSimulator to beyond firewall.
* [http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?XoopenSim%20(E) XoopenSim] - OpenSimulator WEB Interface for Xoops Cube. This module was made by remodeling [http://forge.opensimulator.org/gf/project/opensimwi/ OpenSimWi(Redux)]. v1.55 supports 0.6.7/0.6.8/0.6.9/0.7.x, and it includes flotsam group function and [http://www.nsl.tuis.ac.jp/svn/opensim/opensim.osprofile/ modified osprofile] function.
* [http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?Modlos%20(E) Modlos] - OpenSimulator WEB Interface for Moodle-1.9. This is a sister program of XoopenSim.
* [http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?OpenSim%2FMoneyServer Money Server (NSL Version)] - This Money Server is modified version of [http://forge.opensimulator.org/gf/project/currency/ DTL Currency Processing] for Linux/Unix.
* [http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?Rinions Rinions] - This is a real-time animation tool for Second Life™/OpenSim. Rinions sends animation data from Kinect to Viewer in real time using shared memory and over the Network.
* [http://www.mobilegridclient.com/] - Mobile Grid Client. A Second Life and OpenSim (Open Simulator) messaging client for your Android powered device (mobile phone, cell phone, tablet...).

== Concepts ==
* [http://www.cs.cmu.edu/~johnny/projects/wii/ 3D Head Tracking Software] - The idea here is that Johnny has written an application that will allow real3d perspective using a WiiMote & a modified set of safety glasses. Johnny includes all of the source and several sample applications to get this moving forward. Would someone like to pick this up and build us a real3D interface for the SL browser? It's not as hard as you think.

* [http://en.wikipedia.org/wiki/Edusim Edusim on Opensim] - Edusim is a [http://en.wikipedia.org/wiki/Cave_Automatic_Virtual_Environment Cave Automatic Virtual Environment] based concept of lesson driven 3D virtual worlds on the ''classroom interactive whiteboard or classroom interactive surface''. Currently Edusim on Opencobalt Cobalt exists but tweaking a client and making Opensim "finger friendly" would seem to be a relatively straight forward task.

= See Also =
* [[:Category:Development|Development]]

[[Category:Users]]
[[Category:Support]]
[[Category:Tech Reference]]
[[Category:Help]]
[[Category:Configuration]]
[[Category:Getting Started]]
[[Category:Development]]