<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://opensimulator.org/skins/common/feed.css?303"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://opensimulator.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Orenh</id>
		<title>OpenSimulator - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="http://opensimulator.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Orenh"/>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Special:Contributions/Orenh"/>
		<updated>2026-04-05T03:28:06Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.19.9</generator>

	<entry>
		<id>http://opensimulator.org/wiki/OsGetAvatarHomeURI</id>
		<title>OsGetAvatarHomeURI</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OsGetAvatarHomeURI"/>
				<updated>2015-11-23T10:26:59Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Created page with &amp;quot;{{osslfunc |threat_level=Low |function_syntax=string osGetAvatarHomeURI(string uuid) |ossl_example=&amp;lt;source lang=&amp;quot;lsl&amp;quot;&amp;gt;  // // Sample Script //    default {     touch_start(int...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{osslfunc&lt;br /&gt;
|threat_level=Low&lt;br /&gt;
|function_syntax=string osGetAvatarHomeURI(string uuid)&lt;br /&gt;
|ossl_example=&amp;lt;source lang=&amp;quot;lsl&amp;quot;&amp;gt; &lt;br /&gt;
//&lt;br /&gt;
// Sample Script&lt;br /&gt;
// &lt;br /&gt;
 &lt;br /&gt;
default&lt;br /&gt;
{&lt;br /&gt;
    touch_start(integer num_detected)&lt;br /&gt;
    {&lt;br /&gt;
        key avatarKey = llDetectedKey(0);&lt;br /&gt;
        string homeUri = osGetAvatarHomeURI(avatarKey);&lt;br /&gt;
        llSay(0, &amp;quot;Your Home URI is: &amp;quot; + homeUri);&lt;br /&gt;
    }&lt;br /&gt;
}&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
|description=Returns an avatar's Home URI.&lt;br /&gt;
|&lt;br /&gt;
}}&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/0.8.2.0_Release</id>
		<title>0.8.2.0 Release</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/0.8.2.0_Release"/>
				<updated>2015-10-21T05:19:50Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Scripting */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Languages|0.8.2.0_Release}}&lt;br /&gt;
=Release Notes=&lt;br /&gt;
== General ==&lt;br /&gt;
Welcome to OpenSimulator 0.8.2.0, an open-source multi-user 3D virtual environment and metaverse server platform. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are upgrading from a previous verson 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.&lt;br /&gt;
&lt;br /&gt;
As this is a wiki page, please feel free to update it with more information about migration or other issues as and when these come to light.&lt;br /&gt;
&lt;br /&gt;
You can download this release of OpenSimulator from http://opensimulator.org/wiki/Download&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
* Arbitrary key:value storage for regions has not yet been implemented for SQLite or MSSQL.  This is necessary for temporary attachments settings to be persisted.  This functionality is considered experimental.&lt;br /&gt;
* Regression in RLV functionality where objects given via the llGiveInventoryFolder() function with a folder name with the format #RLV/~gift are still placed in the #RLV folder but now with the name still as &amp;quot;#RLV/~gift&amp;quot; rather than just &amp;quot;~gift&amp;quot;.  This is being addressed in http://opensimulator.org/mantis/view.php?id=6311.  Any help from viewer developers on this would be much appreciated.&lt;br /&gt;
* No form of prim equivalence is implemented for meshes.&lt;br /&gt;
* Loading scripts from the library section of inventory does not work properly.&lt;br /&gt;
* The non-default Warp3D maptile generator currently leaks memory very badly.  We recommend that you only use this once at the beginning of each simulator session.&lt;br /&gt;
* Experimental PGSQL adaptor has bugs when used with built-in groups and built-in user profiles.&lt;br /&gt;
* For other bugs please see the OpenSimulator Mantis bug tracker.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
OpenSimulator requires:&lt;br /&gt;
&lt;br /&gt;
* .NET Framework 4 when running under Windows.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
== Backwards Compatibility Notices ==&lt;br /&gt;
&lt;br /&gt;
=== Database ===&lt;br /&gt;
&lt;br /&gt;
* Schema changes in asset store, xasset store, fsasset store, region store, AgentPrefs (new table). Migrations included.&lt;br /&gt;
&lt;br /&gt;
== Changes ==&lt;br /&gt;
&lt;br /&gt;
=== General Robust Server ===&lt;br /&gt;
&lt;br /&gt;
=== General Simulator Server ===&lt;br /&gt;
&lt;br /&gt;
=== Archives ===&lt;br /&gt;
&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== Avatars ===&lt;br /&gt;
&lt;br /&gt;
* Fix detach event not being fired until the next time the object is attached. This allows scripts such as AOs to remove animations when detached. The pause added does not affect other avatars or the scene in general and only pauses the avatar performing the detach for an extra 2 milliseconds.&lt;br /&gt;
&lt;br /&gt;
=== Classifieds ===&lt;br /&gt;
&lt;br /&gt;
* Fixed not being charged to create classifieds on money enabled regions&lt;br /&gt;
&lt;br /&gt;
=== Configuration ===&lt;br /&gt;
&lt;br /&gt;
=== Friends ===&lt;br /&gt;
&lt;br /&gt;
=== Groups ===&lt;br /&gt;
&lt;br /&gt;
=== Hypergrid ===&lt;br /&gt;
&lt;br /&gt;
=== Instant Messaging ===&lt;br /&gt;
&lt;br /&gt;
=== Inventory ===&lt;br /&gt;
* Fixed several performance issues regarding initial inventory download by changing the IInventory API. In some cases this has resulted in 10x performance improvement, and much lower CPU spikes during login.&lt;br /&gt;
&lt;br /&gt;
=== Map ===&lt;br /&gt;
&lt;br /&gt;
=== Mesh/Sculpt ===&lt;br /&gt;
&lt;br /&gt;
=== Monitoring ===&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== NPC ===&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== Objects ===&lt;br /&gt;
&lt;br /&gt;
=== Physics ===&lt;br /&gt;
* ODE Now supports variable-sized regions&lt;br /&gt;
&lt;br /&gt;
=== Profiles ===&lt;br /&gt;
&lt;br /&gt;
* Bug fix: Change UserProfiles so that the parcel name is used for a ProfilePick and not the parcel owners name. This change also fixes a bug where if the avatar enters and does not move, creating or editing a ProfilePick would set the parcelId as an empty UUID.&lt;br /&gt;
&lt;br /&gt;
=== Region/Estates/Parcels ===&lt;br /&gt;
&lt;br /&gt;
=== Region Cross/Teleport ===&lt;br /&gt;
&lt;br /&gt;
=== Scripting ===&lt;br /&gt;
&lt;br /&gt;
* Changes to make the script times shown in the &amp;quot;Top Scripts&amp;quot; window more accurate:&lt;br /&gt;
** Measure script execution time precisely, using a sub-millisecond timer. This is needed because some scripts execute very often, but only run for a very short amount of time in each invocation. Previously such scripts were shown as using 0 time.&lt;br /&gt;
** Use a 30-seconds sliding window for measuring script execution. Previously the window was 30 minutes, and even that didn't work correctly.&lt;br /&gt;
** Ignore the time the script spends sleeping. Many LSL functions have a sleep-delay at the end.&lt;br /&gt;
** Include the XEngine overhead in the timings. Previously it was excluded.&lt;br /&gt;
** For more information, see http://opensimulator.org/wiki/Scripts_Performance&lt;br /&gt;
&lt;br /&gt;
* When the user stops a script, have it remain stopped even after a region restart. Previously, after a region restart the script would start Running again.&lt;br /&gt;
&lt;br /&gt;
=== Services ===&lt;br /&gt;
&lt;br /&gt;
=== Sound ===&lt;br /&gt;
&lt;br /&gt;
=== Stats ===&lt;br /&gt;
&lt;br /&gt;
* The simulator now reports the actual physics' frames per second (fps) that is used in OpenSimulator. In normal operation, this number is close to 11. Previously OpenSim reported a multiple of the actual physics fps, so that viewers would get a number similar to that used in Second Life. We no longer do that. We now report the correct physics fps.&lt;br /&gt;
&lt;br /&gt;
* New metrics reported:&lt;br /&gt;
** Logging in Users: number of users attempting to login&lt;br /&gt;
** GeoPrims: count of all geometric (prim) objects in the scene&lt;br /&gt;
** Mesh: count of all mesh objects in the scene&lt;br /&gt;
** XEngine Thread Count: Number of threads in use as reported by XEngine's SmartThreadPool&lt;br /&gt;
** Util Thread Count: Number of threads in use as reported by Util's SmartThreadPool&lt;br /&gt;
** System Thread Count: Number of threads in use as reported by the Microsoft SDK&lt;br /&gt;
** ProcMem: Physical memory in use by the opensim instance in kB. This includes shared (e.g. system libraries) and private data.&lt;br /&gt;
&lt;br /&gt;
=== Terrain ===&lt;br /&gt;
&lt;br /&gt;
=== Voice ===&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== Tests ===&lt;br /&gt;
&lt;br /&gt;
== Acknowledgements ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Category:Release Notes]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/0.8.2.0_Release</id>
		<title>0.8.2.0 Release</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/0.8.2.0_Release"/>
				<updated>2015-10-21T05:19:29Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Scripting */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Languages|0.8.2.0_Release}}&lt;br /&gt;
=Release Notes=&lt;br /&gt;
== General ==&lt;br /&gt;
Welcome to OpenSimulator 0.8.2.0, an open-source multi-user 3D virtual environment and metaverse server platform. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are upgrading from a previous verson 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.&lt;br /&gt;
&lt;br /&gt;
As this is a wiki page, please feel free to update it with more information about migration or other issues as and when these come to light.&lt;br /&gt;
&lt;br /&gt;
You can download this release of OpenSimulator from http://opensimulator.org/wiki/Download&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
* Arbitrary key:value storage for regions has not yet been implemented for SQLite or MSSQL.  This is necessary for temporary attachments settings to be persisted.  This functionality is considered experimental.&lt;br /&gt;
* Regression in RLV functionality where objects given via the llGiveInventoryFolder() function with a folder name with the format #RLV/~gift are still placed in the #RLV folder but now with the name still as &amp;quot;#RLV/~gift&amp;quot; rather than just &amp;quot;~gift&amp;quot;.  This is being addressed in http://opensimulator.org/mantis/view.php?id=6311.  Any help from viewer developers on this would be much appreciated.&lt;br /&gt;
* No form of prim equivalence is implemented for meshes.&lt;br /&gt;
* Loading scripts from the library section of inventory does not work properly.&lt;br /&gt;
* The non-default Warp3D maptile generator currently leaks memory very badly.  We recommend that you only use this once at the beginning of each simulator session.&lt;br /&gt;
* Experimental PGSQL adaptor has bugs when used with built-in groups and built-in user profiles.&lt;br /&gt;
* For other bugs please see the OpenSimulator Mantis bug tracker.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
OpenSimulator requires:&lt;br /&gt;
&lt;br /&gt;
* .NET Framework 4 when running under Windows.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
== Backwards Compatibility Notices ==&lt;br /&gt;
&lt;br /&gt;
=== Database ===&lt;br /&gt;
&lt;br /&gt;
* Schema changes in asset store, xasset store, fsasset store, region store, AgentPrefs (new table). Migrations included.&lt;br /&gt;
&lt;br /&gt;
== Changes ==&lt;br /&gt;
&lt;br /&gt;
=== General Robust Server ===&lt;br /&gt;
&lt;br /&gt;
=== General Simulator Server ===&lt;br /&gt;
&lt;br /&gt;
=== Archives ===&lt;br /&gt;
&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== Avatars ===&lt;br /&gt;
&lt;br /&gt;
* Fix detach event not being fired until the next time the object is attached. This allows scripts such as AOs to remove animations when detached. The pause added does not affect other avatars or the scene in general and only pauses the avatar performing the detach for an extra 2 milliseconds.&lt;br /&gt;
&lt;br /&gt;
=== Classifieds ===&lt;br /&gt;
&lt;br /&gt;
* Fixed not being charged to create classifieds on money enabled regions&lt;br /&gt;
&lt;br /&gt;
=== Configuration ===&lt;br /&gt;
&lt;br /&gt;
=== Friends ===&lt;br /&gt;
&lt;br /&gt;
=== Groups ===&lt;br /&gt;
&lt;br /&gt;
=== Hypergrid ===&lt;br /&gt;
&lt;br /&gt;
=== Instant Messaging ===&lt;br /&gt;
&lt;br /&gt;
=== Inventory ===&lt;br /&gt;
* Fixed several performance issues regarding initial inventory download by changing the IInventory API. In some cases this has resulted in 10x performance improvement, and much lower CPU spikes during login.&lt;br /&gt;
&lt;br /&gt;
=== Map ===&lt;br /&gt;
&lt;br /&gt;
=== Mesh/Sculpt ===&lt;br /&gt;
&lt;br /&gt;
=== Monitoring ===&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== NPC ===&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== Objects ===&lt;br /&gt;
&lt;br /&gt;
=== Physics ===&lt;br /&gt;
* ODE Now supports variable-sized regions&lt;br /&gt;
&lt;br /&gt;
=== Profiles ===&lt;br /&gt;
&lt;br /&gt;
* Bug fix: Change UserProfiles so that the parcel name is used for a ProfilePick and not the parcel owners name. This change also fixes a bug where if the avatar enters and does not move, creating or editing a ProfilePick would set the parcelId as an empty UUID.&lt;br /&gt;
&lt;br /&gt;
=== Region/Estates/Parcels ===&lt;br /&gt;
&lt;br /&gt;
=== Region Cross/Teleport ===&lt;br /&gt;
&lt;br /&gt;
=== Scripting ===&lt;br /&gt;
&lt;br /&gt;
* Changes to make the script times shown in the &amp;quot;Top Scripts&amp;quot; window more accurate:&lt;br /&gt;
** Measure script execution time precisely, using a sub-millisecond timer. This is needed because some scripts execute very often, but only run for a very short amount of time in each invocation. Previously such scripts were shown as using 0 time.&lt;br /&gt;
** Use a 30-seconds sliding window for measuring script execution. Previously the window was 30 minutes, and even that didn't work correctly.&lt;br /&gt;
** Ignore the time the script spends sleeping. Many LSL functions have a sleep-delay at the end.&lt;br /&gt;
** Include the XEngine overhead in the timings. Previously it was excluded.&lt;br /&gt;
** For more information, see http://opensimulator.org/wiki/Scripts_Performance&lt;br /&gt;
&lt;br /&gt;
* When the user stops a script, have it remain stopped even after region restart. Previously, after a region restart the script would start Running again.&lt;br /&gt;
&lt;br /&gt;
=== Services ===&lt;br /&gt;
&lt;br /&gt;
=== Sound ===&lt;br /&gt;
&lt;br /&gt;
=== Stats ===&lt;br /&gt;
&lt;br /&gt;
* The simulator now reports the actual physics' frames per second (fps) that is used in OpenSimulator. In normal operation, this number is close to 11. Previously OpenSim reported a multiple of the actual physics fps, so that viewers would get a number similar to that used in Second Life. We no longer do that. We now report the correct physics fps.&lt;br /&gt;
&lt;br /&gt;
* New metrics reported:&lt;br /&gt;
** Logging in Users: number of users attempting to login&lt;br /&gt;
** GeoPrims: count of all geometric (prim) objects in the scene&lt;br /&gt;
** Mesh: count of all mesh objects in the scene&lt;br /&gt;
** XEngine Thread Count: Number of threads in use as reported by XEngine's SmartThreadPool&lt;br /&gt;
** Util Thread Count: Number of threads in use as reported by Util's SmartThreadPool&lt;br /&gt;
** System Thread Count: Number of threads in use as reported by the Microsoft SDK&lt;br /&gt;
** ProcMem: Physical memory in use by the opensim instance in kB. This includes shared (e.g. system libraries) and private data.&lt;br /&gt;
&lt;br /&gt;
=== Terrain ===&lt;br /&gt;
&lt;br /&gt;
=== Voice ===&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== Tests ===&lt;br /&gt;
&lt;br /&gt;
== Acknowledgements ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Category:Release Notes]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Performance</id>
		<title>Performance</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Performance"/>
				<updated>2015-08-11T10:16:28Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* 3 Kinds of Ticks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
OpenSimulator performance is a very complex issue.  Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.&lt;br /&gt;
&lt;br /&gt;
We can break down performance considerations into &lt;br /&gt;
&lt;br /&gt;
# Network issues (bandwidth and latency between viewer and simulator, between simulators and between simulator and grid service).&lt;br /&gt;
# Simulator issues (e.g. number of scene objects, number of textures, number of scripts).&lt;br /&gt;
# Grid issues (chiefly scaling services such as asset, inventory, etc to serve more simulators and users).&lt;br /&gt;
&lt;br /&gt;
The biggest issues are probably network and simulator issues.  &lt;br /&gt;
&lt;br /&gt;
To run a simulator you must have good bandwidth (to download textures), good latency (so that movements are seen and actions processed in a timely manner) and good quality (so that random packet drops don't result in missed actions or other problems).&lt;br /&gt;
&lt;br /&gt;
You must also be aware of your hardware's capabilities.  The more scene objects, scripts and avatars you have, the more memory and CPU will be used.&lt;br /&gt;
&lt;br /&gt;
Grid issues are less important until you reach larger grid sizes (e.g. over 60 simultaneous users).&lt;br /&gt;
&lt;br /&gt;
= Monitoring Performance =&lt;br /&gt;
&lt;br /&gt;
Gathering data to analyze performance issues is an evolving area.  We can split this into [[client side monitoring]] (e.g. statistics you can see from the statistics window on a viewer program) and server side performance analysis.  Server side performance analysis will involve [[monitoring|OpenSimulator server monitoring]] and general system tools (e.g. top on Linux to monitor which processes are taking up CPU/memory and more general monitoring tools such as Zabbix).&lt;br /&gt;
&lt;br /&gt;
= General Tips =&lt;br /&gt;
&lt;br /&gt;
* Where at all possible, don't assume something is a performance bottleneck, measure it!  You might think your asset database is large, for example, but even large asset database seldom cause real issues.&lt;br /&gt;
* Make as many objects phantom as possible.  Phantom objects do not need to be tested for collisions with avatars and other objects, reducing physics frame time and increasing performance.&lt;br /&gt;
* Make as few objects subject to physics (e.g. falling under gravity, movable by other avatars) as possible.  Physics objects need a lot more collision testing than ordinary non-phantom objects.&lt;br /&gt;
* It can be hard to perform measurement at the moment since not a lot of tools exist.  However, one such is [[pCampbot]] which is bundled with OpenSimulator.  This can instantiate a number of simultaneous libomv clients on a simulator that can take certain actions such as clicking things and bouncing aroud.  Apects of it (e.g. appearance) are currently rather buggy and generate a lot of logging guff.&lt;br /&gt;
* If your avatars are twitching a lot or flying around uncontrollably, this is often a signal of dropped packets caused by network issues.  For important packets, the simulator will retry the send 3 times but drop the packet after that.  On the simulator console, the command &amp;quot;show queues&amp;quot; will indicate how many packets the simulator has to resend and the total number of sends.  If the total resends is greater than 10% then this is a signal of network issues, at least between a particular viewer and the simulator.  The problem may be at the user's end (e.g. a bad router being used over wifi, a badly performing ISP) which are difficult to do anything about!&lt;br /&gt;
&lt;br /&gt;
=== 3 Kinds of Ticks ===&lt;br /&gt;
&lt;br /&gt;
If you measure times in C#, be aware that the word &amp;quot;Tick&amp;quot; is overloaded: there are 3 different values for a Tick, and it's important not to mix them.&lt;br /&gt;
&lt;br /&gt;
# '''Stopwatch''' - varying resolutions, depending on the operating system. Stopwatch.Frequency contains the number of ticks per second. On Windows, this is about 300 ticks per millisecond.&lt;br /&gt;
# '''TimeSpan''' - 10,000 ticks = 1 millisecond&lt;br /&gt;
# '''Environment.TickCount''' - 1 tick = 1 millisecond&lt;br /&gt;
&lt;br /&gt;
It's recommended to use the '''Stopwatch''' class for timing, because it can measure sub-ms times. You can get the Stopwatch's value in ms by calling '''Stopwatch.ElapsedMilliseconds'''.&lt;br /&gt;
&lt;br /&gt;
If you want to add up times, e.g. to get the total time spent executing a script, then accumulate the the sum using Stopwatch Ticks: again, because this is the only high-resolution timer available. If you do this then you will have a 'long' variable that contains the number of ticks. When you want to convert this value into elapsed time, use code such as this:&lt;br /&gt;
&lt;br /&gt;
 long numStopwatchTicks = xxxx;&lt;br /&gt;
 TimeSpan elapsed = TimeSpan.FromMilliseconds((numStopwatchTicks * 1000) / Stopwatch.Frequency);&lt;br /&gt;
&lt;br /&gt;
=== MetricsCollectorTime ===&lt;br /&gt;
&lt;br /&gt;
The class '''MetricsCollectorTime''' may be useful to you. It implements a sliding window that collects performance measurements. For example, its' used to calculate the total execution time over the past 30 seconds for each script. For example, instantiate it as follows:&lt;br /&gt;
&lt;br /&gt;
 MetricsCollectorTime executionTime = new MetricsCollectorTime(30000, 10);&lt;br /&gt;
&lt;br /&gt;
This creates a sliding window that covers 30 seconds (30000 ms), and has 10 &amp;quot;buckets&amp;quot;. The buckets determine the granularity of the window: in this case, it's 30/10 = 3 seconds.&lt;br /&gt;
&lt;br /&gt;
Whenever you get a timing sample, add it to the collector:&lt;br /&gt;
&lt;br /&gt;
 Stopwatch timer = new Stopwatch();&lt;br /&gt;
 // Measure something with 'timer'...&lt;br /&gt;
 collector.AddSample(timer);&lt;br /&gt;
&lt;br /&gt;
Whenever you want to get the total value in the collection window, call:&lt;br /&gt;
&lt;br /&gt;
 int elapsedMS = collector.GetSumTime().TotalMilliseconds;&lt;br /&gt;
&lt;br /&gt;
MetricsCollectorTime is actually a subclass of the generic MetricsCollector class. The generic class can use any data type as the Sample value. It uses a circular buffer for its buckets, so it's highly efficient.&lt;br /&gt;
&lt;br /&gt;
= Viewer Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Performance issues can be tackled on the viewer side as well as on the OpenSimulator side.  This typically involves lowering viewer graphical settings (e.g. reducing viewer-side draw distance).  See http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923 for more information.&lt;br /&gt;
&lt;br /&gt;
= Simulator Performance Topics =&lt;br /&gt;
&lt;br /&gt;
== Hardware Requirements ==&lt;br /&gt;
Unfortunately, this is a very difficult question in light of all the factors mentioned in the introduction.  Apart from network, the most important &lt;br /&gt;
&lt;br /&gt;
===CPU===&lt;br /&gt;
We can say that OpenSimulator does not run well when it only has access to a single CPU core - you should regard a dual-core machine as the minimum.&lt;br /&gt;
&lt;br /&gt;
An extremely approximate rule of thumb is to have one core per regularly used region, with the minimum of two above.  So a 4 region simulator would need 4 cores.  However, this assumes continuous use of those regions - one could probably get away with a higher core to region ratio if those other regions were much less used (or not used simultaneously).&lt;br /&gt;
&lt;br /&gt;
On OpenSimulator 0.7.6, we have also observed that an idle region (one which has very few if no active scripts and no avatars on it or in neighbouring regions) requires approximately 2.5% of a CPU core.  The requirement before OpenSimulator 0.7.6 was much higher.&lt;br /&gt;
&lt;br /&gt;
We can also say, again extremely approximately, that each active avatar requires 8% CPU.  An active avatar is one that is moving around and the chief cause of this load is physics processing with the ODE physics engine plugin.  Other physics engine plugins, such as Bulletsim, may require less CPU.&lt;br /&gt;
&lt;br /&gt;
Continually running scripts (such as scripts on timers) will also generate continuous CPU load on a region.  A few scripts of this type probably won't have much of an impact, but a larger number of scripts will start to consume CPU resources.&lt;br /&gt;
&lt;br /&gt;
Finally, physics objects (those which have their physics checkbox marked in the viewer and so are moved around by gravity and collisions) will also generate physics CPU load on the simulator if they are not at rest.&lt;br /&gt;
&lt;br /&gt;
===Memory===&lt;br /&gt;
As a rule of thumb, a region with lots of avatars, 15000 or more prims and 2000 scripts may require 1G of memory.  So a simulator with 4 such regions may require 4G.  One could use less memory if not all regions will be occupied with avatars simultaneously, or where the are fewer scripts, for instance.&lt;br /&gt;
&lt;br /&gt;
===Disk===&lt;br /&gt;
At the simulator level, storage performance is not a big issue unless one has scripts which need extremely high performance in rezzing and derezzing objects.  Even in this case, 7200 rpm 3.5&amp;quot; desktop drives are generally sufficient - problems only start to arise with lower performing drives, such as those found in laptops.&lt;br /&gt;
&lt;br /&gt;
At the grid level, faster storage may be useful when handling large numbers of asset, inventory or other service requests.&lt;br /&gt;
&lt;br /&gt;
===Network===&lt;br /&gt;
Download and upload bandwidth and latency are important.  The biggest use of upload bandwidth (from the server point of view) is to provide texture data to viewers.  So a home network with poor bandwidth (e.g. 384 kbits up) will result in a poor experience for viewers, at least until they have received all texture data.  The requirement for upload bandwidth peaks when a viewer enters a region for the first time or after clearing their asset cache.  The amount of bandwidth required will vary heavily with the number of textures on the region.  An extremely approximate rule of thumb is to have 500 kbit per simultaneously logged in avatar if you know that all avatars will be downlaoding textures simultaneously.&lt;br /&gt;
&lt;br /&gt;
The biggest use of download bandwidth (from the server point of view) is to receive the continuous UDP movement messages from connected avatars.  However, in comparison to texture download, the bandwidth required is trivial - an approximate rule of thumb is 10K (80 kbit) per avatar.&lt;br /&gt;
&lt;br /&gt;
Latency is critical on both upload and download to the simulator, since any delay will affect avatar movement packets (download to server from viewer) and updates to the viewer about other object/avatar position changes (upload from server to viewer).  It's much harder to give advice here, though pings of greater than 350 milliseconds will start to degrade the user's experience on moving their avatar.&lt;br /&gt;
&lt;br /&gt;
===Examples===&lt;br /&gt;
Below are some examples of hardware people use/have used.  Please feel free to add to the list, or to add any reports to the performance studies and blog posts section.  '''These are examples to help you in your selection, not recommendations.'''&lt;br /&gt;
&lt;br /&gt;
Object Parts ~= # prim&lt;br /&gt;
&lt;br /&gt;
Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.&lt;br /&gt;
&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
!Description&lt;br /&gt;
!Operating System (please add Mono version if appropriate)&lt;br /&gt;
!OpenSimulator version&lt;br /&gt;
!RAM/AVG_USE_%&lt;br /&gt;
!CPU&lt;br /&gt;
!#/type of regions&lt;br /&gt;
!# simultaneous avs&lt;br /&gt;
!#scripts/timers/Sensors&lt;br /&gt;
!Location&lt;br /&gt;
!#objectparts&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Intrepid (8.10)&lt;br /&gt;
|Unknown&lt;br /&gt;
|540MB/?&lt;br /&gt;
|1x quad-core 2.5GHz Xeon (L5420)&lt;br /&gt;
|1 region + 9 voids&lt;br /&gt;
|generally 1-2&lt;br /&gt;
|few&lt;br /&gt;
|Knifejaw Atoll &amp;amp; surrounding on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Jaunty (9.04)&lt;br /&gt;
|Unknown&lt;br /&gt;
|360MB/?&lt;br /&gt;
|2x dual-core 2.0GHz Xeon (5130)&lt;br /&gt;
|1 void&lt;br /&gt;
|generally 1-2 &lt;br /&gt;
|none&lt;br /&gt;
|Knifejaw Road on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from A+&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1 Meg&lt;br /&gt;
|1x single-core 2.8GHz Celeron&lt;br /&gt;
|2regions per server&lt;br /&gt;
|6 at once with no issues&lt;br /&gt;
|Waterfalls, texture anims, window texture switchers, lots of sound loops&lt;br /&gt;
|Pleasure Planet Welcome center &amp;amp; Region Pleasure Planet in OSGrid&lt;br /&gt;
|20000 prims per region&lt;br /&gt;
|-&lt;br /&gt;
|Amazon EC2 &amp;quot;high-CPU medium instance&amp;quot; (Xen VM)&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1.7GB&lt;br /&gt;
|1x dual-core 2.3GHz (Intel E5345)&lt;br /&gt;
|1 region with sailing race course&lt;br /&gt;
|7 avs, 4 in boats&lt;br /&gt;
|scripted start line&lt;br /&gt;
|Castle Rock, OSGrid&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from simhost.com&lt;br /&gt;
|SuSe 11.2 x64&lt;br /&gt;
|Unknown&lt;br /&gt;
|8gb / 50%&lt;br /&gt;
|4x Core2Quad Q9300 2.6ghz&lt;br /&gt;
|1 region (Wright Plaza) uses approx 4gb ram&lt;br /&gt;
|20-25 users&lt;br /&gt;
|Freebie Stores / Meeting Center / Video Theater&lt;br /&gt;
|@osgrid.org Heavy Use Sim&lt;br /&gt;
|17500 prims aprox 1500 scripts&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Windows XP SP3&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|3GB / 15-40% incl. Opensim and MySQL&lt;br /&gt;
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%&lt;br /&gt;
|11 regions&lt;br /&gt;
|1-6 users&lt;br /&gt;
|Many scripted objects (1934 scripts)&lt;br /&gt;
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]&lt;br /&gt;
|38,065 prims&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Ubuntu Lucid 10.04 (32 bit pae)&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|160Mb no users, add 5Mb/user incl Opensim and MySQL&lt;br /&gt;
|I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load&lt;br /&gt;
|4 regions (Diva default config)&lt;br /&gt;
|1-4 users (approx 20Kb/sec bandwidth/user)&lt;br /&gt;
|Few scripted objects (&amp;lt;10)&lt;br /&gt;
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]&lt;br /&gt;
|158 prims&lt;br /&gt;
|-&lt;br /&gt;
|Hosted Dedicated OVH&lt;br /&gt;
|Suse 12.2&lt;br /&gt;
|0.7.0.2 (D2)&lt;br /&gt;
|420Mb total, incl OS, Opensim and MySQL&lt;br /&gt;
|i7 Quad 950 (Bloomfield) 3.07GHz, 8 Core, 24Gb RAM, 0-1% Avg Load&lt;br /&gt;
|16 regions (4x4 mega-region)&lt;br /&gt;
|&amp;lt;6 users&lt;br /&gt;
|vehicle scripted objects (&amp;lt;5)&lt;br /&gt;
|[http://metaversesailing.com:9000/wifi Metaverse Sailing]&lt;br /&gt;
|&amp;lt;1000 prims&lt;br /&gt;
|-&lt;br /&gt;
|VPS&lt;br /&gt;
|Debian Lenny 5 (mono 2.4.2.3)&lt;br /&gt;
|OSgrid 0.7.1 (Dev) cd4d7a7: 2010-10-15&lt;br /&gt;
|655MB average out of 1722MB RAM, incl. MySQL&lt;br /&gt;
|Intel Quadcore 2.5 Ghz (1 core assigned to vps) average use: 40-45% &lt;br /&gt;
|20 regions&lt;br /&gt;
|&amp;lt;4 users&lt;br /&gt;
|about 20 different light scripts, but we're also experimenting with heavier HUD scripts (timers, lots of ll(Get/Set)PrimitiveParams and large lists) and custom IRC relay&lt;br /&gt;
|Phoenix Rising Isles on OsGrid&lt;br /&gt;
|3727 prims&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator is configured to use the SQLite database.  This is very convenient for an out-of-the-box experience since it requires no configuration.  However, it's not designed for heavy usage, so if you build very quickly or have more than a few people on your simulator then you will start to see performance issues.&lt;br /&gt;
&lt;br /&gt;
Therefore, we recommend that you switch to MySQL as soon as possible.  This will provide a much better experience but will take a little bit of work to set up.  &lt;br /&gt;
&lt;br /&gt;
Unfortunately, tools for migrating OpenSimulator SQLite data to MySQL are currently limited.  Migration is also possible by saving OARs/IARs of your data from sqlite and loading them up once you've reconfigured to use MySQL.&lt;br /&gt;
&lt;br /&gt;
There is also a database plugin for MSSQL but this is not well maintained between OpenSimulator releases.&lt;br /&gt;
&lt;br /&gt;
In standalone mode, both services and the simulator itself can use SQLite.  In grid mode, SQLite is only supported for simulator data - the ROBUST instances must use a MySQL (or MSSQL) database.&lt;br /&gt;
&lt;br /&gt;
In general a single MySQL instance for the ROBUST services instance will serve small, medium and even large grids perfectly well - it's a configuration that's widely used for even quite large websites.&lt;br /&gt;
&lt;br /&gt;
== Scripts ==&lt;br /&gt;
&lt;br /&gt;
See [[Scripts Performance]].&lt;br /&gt;
&lt;br /&gt;
== Configuration tweaks ==&lt;br /&gt;
&lt;br /&gt;
There are a couple of OpenSimulator configuration tweaks that you can do to significantly improve script loading performance in certain situations.  These tweaks can be made in your OpenSim.ini config file.  These apply to current OpenSimulator development code (0.7.3-dev) and may also apply to 0.7.2, though certainly not any earlier.&lt;br /&gt;
&lt;br /&gt;
===Set DeleteScriptsOnStartup = false===&lt;br /&gt;
&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 DeleteScriptsOnStartup = false&lt;br /&gt;
&lt;br /&gt;
This means that OpenSimulator will not delete all the existing compiled script DLLs on startup (don't worry, this setting doesn't touch the actual LSL scripts in your region).  This will significantly improve startup performance.  However, if you upgrade OpenSimulator in place (e.g. you regularly update your installation directly from development code) then you may occasionally see problems if code changes and your previously compiled DLLs can't find their old references.&lt;br /&gt;
&lt;br /&gt;
In this case, you can either set DeleteScriptsOnStartup = true for one restart in order to clean out and recompile script DLLs or you can manually delete the relevant bin/ScriptEngines/&amp;lt;region-uuid&amp;gt;/*.dll.* files, which will force OpenSimulator to recompile them.  You could also delete the entire bin/ScriptEngines/&amp;lt;region-uuid&amp;gt; directory but this would lose all persisted script state (which is kept in the &amp;lt;script-item-id&amp;gt;.state files).&lt;br /&gt;
&lt;br /&gt;
===Set AppDomainLoading = false===&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 AppDomainLoading = false&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator loads every script DLL into its own AppDomain.  If this is set to false, then all scripts are loaded into OpenSimulator's default AppDomain instead.&lt;br /&gt;
&lt;br /&gt;
This will significantly improve script startup times and reduce initial per-script memory overhead.&lt;br /&gt;
&lt;br /&gt;
However, setting this to false will also prevent derezzed script DLLs from being removed from memory (only whole AppDomains can be unloaded).  This might cause an OutOfMemory problem over time, as avatars with scripted attachments move in and out of the region.  Whether this is a problem for you will depend on factors such as the avatar population of your grid.&lt;br /&gt;
&lt;br /&gt;
In addition, Windows users have reported script loading problems with AppDomainLoading = false, though I (justincc) haven't been able to replicate this with current OpenSimulator code on my WindowsXP machine.&lt;br /&gt;
&lt;br /&gt;
===Increase MaxPoolThreads in [Startup]===&lt;br /&gt;
&lt;br /&gt;
At the present time, OpenSimulator uses up to three sets of threads for its operations.  &lt;br /&gt;
&lt;br /&gt;
Firstly, the VM threadpool is always used to process incoming network data.  &lt;br /&gt;
&lt;br /&gt;
Secondly, by default an instance of a third-party threadpool package called SmartThreadPool is used for performing short OpenSimulator tasks.  Performance here is critical since many incoming requests from viewers are handled by threads from this threadpool.&lt;br /&gt;
&lt;br /&gt;
Thirdly, XEngine spawns it's own threadpool for script engine tasks.  However, performance here is not critical.&lt;br /&gt;
&lt;br /&gt;
When using SmartThreadPool, the default MaxPoolThreads parameter in OpenSimulator 0.8 and earlier has turned out to really be too low (at 15 threads) for heavy or possibly even moderate numbers of avatars (e.g. 40).  In current development code, the default has been raised from 15 to 300.  So in release code it's also worth doing if you are seeing issues with viewer lag and your CPU usage is not maxed out already.  To set this to 300, you can make the following change in OpenSim.ini.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
MaxPoolThreads = 300&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Although this will allow more threads to be created (hence using more server resources), this is probably what you want anyway if it all possible, since the alternative is to suffer lag in dealing with viewer's incoming UDP data.  The extra threads will only be created if they are needed.&lt;br /&gt;
&lt;br /&gt;
===Change async_call_method in [Startup]===&lt;br /&gt;
&lt;br /&gt;
Alternatively, you could change the general task threadpool entirely.&lt;br /&gt;
&lt;br /&gt;
It has been set as SmartThreadPool by default somewhat for historical reasons - Mono threadpool performance used to be poor.&lt;br /&gt;
&lt;br /&gt;
However, this may be much better in recent versions of Mono (especially 3.x onwards).  In addition, Windows general threadpool performance may be better than SmartThreadPool.&lt;br /&gt;
&lt;br /&gt;
So on these systems, you may want to try experimenting with a setting of &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = UnsafeQueueUserWorkItems&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
on Windows or even Mono.&lt;br /&gt;
&lt;br /&gt;
On Mac OSX, there is a system called [http://en.wikipedia.org/wiki/Grand_Central_Dispatch Grand Central Dispatch] that effectively implements a threadpool below the VM level.  On these systems, there have been reports that simply setting &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = Thread&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
results in better OpenSimulator performance.  However, at least on OSX you may need to increase the number of file handles per process.  Here's a quote on this topic from Gavin Hird.&lt;br /&gt;
&lt;br /&gt;
&amp;quot;I found that on using the async_call_method = thread the system was running out of open files per process as a large number of threads accessed floatsamcache files concurrently. For any *nix you’d have to adjust the “limit -n” parameter.&lt;br /&gt;
&lt;br /&gt;
On OS X the /etc/launchd.conf file needs a line containing “limit maxfiles 2048 65536″ where 2048 in this case is the number of allowed open files per process, and the higher number the open files per system. The file needs to be created if it does not exist.&lt;br /&gt;
Alternatively the file can be created at ~/launchd.conf for the user running OpenSim.exe if you don’t want it as a systemwide setting.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
= Grid Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Scaling a grid is a complex task and only for the very technically inclined.  It is also an area under active investigation.  The advice below will change considerably over time as OpenSimulator and its environment changes and we learn more about perfomrnace issues.&lt;br /&gt;
&lt;br /&gt;
When would you start to meet grid scaling issues?  As an extremely rough and really quite arbitrary and pessimistic rule of thumb, you will probably start to have to think about things when you exceed 50 regions containing a large number of prims or 50 simultaneous users with large inventories.  But this will very a tremendous amount depending on your situation.  If you have thousands of regions with very few prims that much more supportable than 50 regions with 45000 prims each.&lt;br /&gt;
&lt;br /&gt;
You are likely to encounter issues in two areas - database and services.&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
=== Assets ===&lt;br /&gt;
&lt;br /&gt;
==== The problem ====&lt;br /&gt;
&lt;br /&gt;
Due to the architecture of distributed architecture of OpenSimulator, where regions are running on a number of different machines over a network, it's extremely hard to identify assets that are not in use and hence can be deleted.  Equally, the fact that assets are immutable leads to continual growth in the asset database.&lt;br /&gt;
&lt;br /&gt;
In theory, one could identify unused assets if one could identify all references in simulators and in user inventory.  However, this is extremely hard to do where machines are distributed over a network.  If a grid only has a few simulators all running on machines that are controlled by the same entity running a grid, then it becomes a little more tractable but even then would almost certainly involve significant downtime.  For stand-alone grids, or for environments where assets are not passed between grids (ie: giving a texture to a friend on another grid) [http://was.fm Wizardry and Steamworks] provides an experimental script that will do exactly that. It is currently available at the [http://was.fm/opensim:database:asset_cleaner asset cleaner] project page and published under an MIT license.&lt;br /&gt;
&lt;br /&gt;
Asset deletion would be easier for a one simulator grid or a standalone.  However, even code to implement asset deletion on standalones has not yet been implemented and would certainly require significant simulator downtime.&lt;br /&gt;
&lt;br /&gt;
A promising area of research involves improving OpenSimulator's recording of asset access times (e.g. recording access periodically).  Then assets which aren't accessed for a long time (e.g. a year) could be deleted or moved to cold storage (e.g. DVD).  One is left with the problem of not deleting assets permanently cached by simulators but perhaps this could be solved by the simulators occasionally 'pinging' the asset service with notification of what assets they cache.&lt;br /&gt;
&lt;br /&gt;
Another step to reduce asset database size is to eliminate duplicate assets by hashing.  There is [[Deduplicating Asset Service|an experimental development asset service]] for this.  Third party services such as [[https://github.com/coyled/sras SRAS]] also do this.&lt;br /&gt;
&lt;br /&gt;
==== Possible solutions ====&lt;br /&gt;
&lt;br /&gt;
* If you run a grid for yourself or, if you run a grid where you do not give away your content, then the [http://was.fm/opensim:database:asset_cleaner asset cleaner] from [http://was.fm Wizardry and Steamworks] may be a good solution to track down stray assets and delete them from the database automatically. It is based on dumping OARs and IARs, as per the second option in this section, but after dumping them, it automatically performs the search for you and prompts you to delete several supported assets. Current development is going towards automatically exporting OARs and IARs from PHP so that the procedure is made seamless.&lt;br /&gt;
&lt;br /&gt;
* Save every region to an OAR and every user's inventory to an IAR.  We believe this is equivalent to finding all referenced assets and can be done manually.  However, it's very laborious for installations with a large number of users and requires grid downtime.  Tools could be written to improve this, particularly in systematically saving all user inventories to IARs.&lt;br /&gt;
&lt;br /&gt;
* Do nothing.  MySQL can store a very large amount of data before encountering issues - it's used for extremely large websites and other applications after all.  This assumes you have the disk space.&lt;br /&gt;
&lt;br /&gt;
* Use an external asset service such as [[https://github.com/coyled/sras SRAS]].  SRAS, in particular, is a third party asset service that does deduplication, asset compression, and stores assets on disk rather than in a database.  It also has some nice features like preventing assets being served without deleting them.  It's used by OSGrid, for instance.  However, it does work in a different way from the bundled OpenSimulator asset service (e.g. backup of on-disk assets involves some extra steps compared to just backing up a database).  It also requires a migration step that may take a considerable time if you have an existing asset collection.&lt;br /&gt;
&lt;br /&gt;
=== Other databases ===&lt;br /&gt;
&lt;br /&gt;
The space required by assets far outweighs other data storage requirements so only asset data is generally an issue.&lt;br /&gt;
&lt;br /&gt;
== Services ==&lt;br /&gt;
&lt;br /&gt;
=== The problem ===&lt;br /&gt;
&lt;br /&gt;
The other problem is with handling the number of requests to services when the number of simulators and users grow.  The asset service isn't generally a problem since simulators cache all assets used, though it can form a bottleneck on OAR upload.  The biggest issue is generally caused by users, chiefly due to inventory access and perhaps update last user positions in the GridUser service (and database table).&lt;br /&gt;
&lt;br /&gt;
ROBUST uses an embedded [[http://webserver.codeplex.com/ C# HttpServer]].  Performance comparisons to other Webservers (e.g. Apache) have not been carried out (?) but responses appears to be much, much slower.  As it has been discontinued it's also rather unlikely to have it's performance improved.  In future, OpenSimulator may embed a different HTTP server but this is extremely unlikely in the short term.&lt;br /&gt;
&lt;br /&gt;
=== Possible solutions ===&lt;br /&gt;
&lt;br /&gt;
* Split up services.  By default, ROBUST runs every service in one process.  However, because services are separate from each other, you could run some services (e.g. inventory in one ROBUST instance and other services (e.g. asset) in a different instance, even if they both point to the same database.  Because the embedded C# webserver is slow and possibly not very concurrent, this can achieve significant performance improvements even if all ROBUST instances are running on the same machine.  See [[Configuration#Running multiple ROBUST service instances]] for more information on how to do this.&lt;br /&gt;
&lt;br /&gt;
* Instantiate extra ROBUST copies of problem services (e.g. inventory).  Because services are stateless (akin to a webservice), you can load balance requests between multiple instances using a reverse proxy such as nginx.  Again, because the embedded webserver is probably inefficient, you can achieve performance improvements by running multiple copies of services on the same machine.&lt;br /&gt;
&lt;br /&gt;
* Use an external service based on a more efficient HTTP server, e.g. [https://github.com/coyled/sras SRAS] (asset service only) or [http://code.google.com/p/openmetaverse/ SimianGrid].  Please be aware that SimianGrid uses a different set of simulator &amp;lt;-&amp;gt; service protocols than used by ROBUST.  The necessary SimianGrid adaptors are part of the core OpenSimulator distribution.&lt;br /&gt;
&lt;br /&gt;
* Write your own services to run on an external webserver.  This wouldn't be too hard to do in something like PHP, though one would need to work out the currently undocumented wire formats.  If you do this, please do let us know :)&lt;br /&gt;
&lt;br /&gt;
= Performance studies and blog posts =&lt;br /&gt;
&lt;br /&gt;
These provide some interesting data on the performance limitations of OpenSimulator at various points in time.&lt;br /&gt;
&lt;br /&gt;
* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue.  Physical objects and max avatars are limited by single thread performance in OpenSimulator.&lt;br /&gt;
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.&lt;br /&gt;
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSimulator.  Some of these issues are still valid (e.g. ODE issues).&lt;br /&gt;
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.&lt;br /&gt;
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!--&lt;br /&gt;
&lt;br /&gt;
==Performance hints==&lt;br /&gt;
&lt;br /&gt;
Here are some specific things you might be able to do to improve performance&lt;br /&gt;
&lt;br /&gt;
===Home Based systems===&lt;br /&gt;
&lt;br /&gt;
The most obvious performance difference between a home based cable/dsl system and a &amp;quot;commercial&amp;quot; server is the upload bandwidth. A typical home system allows 100Kb/s upload with 12Mb/s download, a &amp;quot;commercial&amp;quot; system typically has a &amp;quot;symmetrical&amp;quot; bandwidth of say 12Mb/s UP AND DOWN! &amp;quot;Commercial&amp;quot; systems can essentially buy unlimited bandwidth as needed, but it does get expensive to buy bandwidth that you don't need!&lt;br /&gt;
&lt;br /&gt;
In practice this limits the number of &amp;quot;external&amp;quot; users on a &amp;quot;home system&amp;quot; to 4 or 5, but LAN users (NPCs/bots etc.) are essentially unlimited.&lt;br /&gt;
&lt;br /&gt;
A reasonable strategy (i.e. MY strategy) is to use the home system for experimentation and then move the entire sim to a &amp;quot;commercial&amp;quot; VPS service if the sim gets popular (and produces enough $$$ to pay the freight!) &lt;br /&gt;
&lt;br /&gt;
===Running Squid on your region server as a reverse proxy to the asset server===&lt;br /&gt;
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/&amp;lt;br&amp;gt;&lt;br /&gt;
2. Create your [[squid.conf]] configuration file.&amp;lt;br&amp;gt;&lt;br /&gt;
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/&amp;lt;br&amp;gt;&lt;br /&gt;
4. Start everything up!&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.&lt;br /&gt;
&lt;br /&gt;
=== GC_NO_EXPLICIT ===&lt;br /&gt;
&lt;br /&gt;
Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.&lt;br /&gt;
&lt;br /&gt;
$mono-svn-root$/mono&lt;br /&gt;
  mono/metadata/boehm-gc.c&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Index: boehm-gc.c&lt;br /&gt;
===================================================================&lt;br /&gt;
--- boehm-gc.c	(revision 105684)&lt;br /&gt;
+++ boehm-gc.c	(working copy)&lt;br /&gt;
@@ -107,6 +107,10 @@&lt;br /&gt;
 void&lt;br /&gt;
 mono_gc_collect (int generation)&lt;br /&gt;
 {&lt;br /&gt;
+	static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv(&amp;quot;GC_NO_EXPLICIT&amp;quot;)) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {&lt;br /&gt;
+		g_print(&amp;quot;\n --------GC_NO_EXPLICIT \n&amp;quot;);&lt;br /&gt;
+		return;&lt;br /&gt;
+		}&lt;br /&gt;
 	MONO_PROBE_GC_BEGIN (generation);&lt;br /&gt;
 	&lt;br /&gt;
 	GC_gcollect ();&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Not only this, but I recompile the mono runtime:&lt;br /&gt;
&amp;lt;pre&amp;gt;--with-large-heap=yes&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:&lt;br /&gt;
&lt;br /&gt;
 export GC_NO_EXPLICIT=1&lt;br /&gt;
and&lt;br /&gt;
 unset GC_NO_EXPLICIT&lt;br /&gt;
&lt;br /&gt;
What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (&amp;gt;3GB), it is possible might keep mono less apt to do stop world complete collections as often.&lt;br /&gt;
&lt;br /&gt;
--&amp;gt;&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Performance</id>
		<title>Performance</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Performance"/>
				<updated>2015-08-11T10:15:47Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* 3 Kinds of Ticks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
OpenSimulator performance is a very complex issue.  Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.&lt;br /&gt;
&lt;br /&gt;
We can break down performance considerations into &lt;br /&gt;
&lt;br /&gt;
# Network issues (bandwidth and latency between viewer and simulator, between simulators and between simulator and grid service).&lt;br /&gt;
# Simulator issues (e.g. number of scene objects, number of textures, number of scripts).&lt;br /&gt;
# Grid issues (chiefly scaling services such as asset, inventory, etc to serve more simulators and users).&lt;br /&gt;
&lt;br /&gt;
The biggest issues are probably network and simulator issues.  &lt;br /&gt;
&lt;br /&gt;
To run a simulator you must have good bandwidth (to download textures), good latency (so that movements are seen and actions processed in a timely manner) and good quality (so that random packet drops don't result in missed actions or other problems).&lt;br /&gt;
&lt;br /&gt;
You must also be aware of your hardware's capabilities.  The more scene objects, scripts and avatars you have, the more memory and CPU will be used.&lt;br /&gt;
&lt;br /&gt;
Grid issues are less important until you reach larger grid sizes (e.g. over 60 simultaneous users).&lt;br /&gt;
&lt;br /&gt;
= Monitoring Performance =&lt;br /&gt;
&lt;br /&gt;
Gathering data to analyze performance issues is an evolving area.  We can split this into [[client side monitoring]] (e.g. statistics you can see from the statistics window on a viewer program) and server side performance analysis.  Server side performance analysis will involve [[monitoring|OpenSimulator server monitoring]] and general system tools (e.g. top on Linux to monitor which processes are taking up CPU/memory and more general monitoring tools such as Zabbix).&lt;br /&gt;
&lt;br /&gt;
= General Tips =&lt;br /&gt;
&lt;br /&gt;
* Where at all possible, don't assume something is a performance bottleneck, measure it!  You might think your asset database is large, for example, but even large asset database seldom cause real issues.&lt;br /&gt;
* Make as many objects phantom as possible.  Phantom objects do not need to be tested for collisions with avatars and other objects, reducing physics frame time and increasing performance.&lt;br /&gt;
* Make as few objects subject to physics (e.g. falling under gravity, movable by other avatars) as possible.  Physics objects need a lot more collision testing than ordinary non-phantom objects.&lt;br /&gt;
* It can be hard to perform measurement at the moment since not a lot of tools exist.  However, one such is [[pCampbot]] which is bundled with OpenSimulator.  This can instantiate a number of simultaneous libomv clients on a simulator that can take certain actions such as clicking things and bouncing aroud.  Apects of it (e.g. appearance) are currently rather buggy and generate a lot of logging guff.&lt;br /&gt;
* If your avatars are twitching a lot or flying around uncontrollably, this is often a signal of dropped packets caused by network issues.  For important packets, the simulator will retry the send 3 times but drop the packet after that.  On the simulator console, the command &amp;quot;show queues&amp;quot; will indicate how many packets the simulator has to resend and the total number of sends.  If the total resends is greater than 10% then this is a signal of network issues, at least between a particular viewer and the simulator.  The problem may be at the user's end (e.g. a bad router being used over wifi, a badly performing ISP) which are difficult to do anything about!&lt;br /&gt;
&lt;br /&gt;
=== 3 Kinds of Ticks ===&lt;br /&gt;
&lt;br /&gt;
If you measure times in C#, be aware that the word &amp;quot;Tick&amp;quot; is overloaded: there are 3 different values for a Tick, and it's important not to mix them.&lt;br /&gt;
&lt;br /&gt;
# '''Stopwatch''' - varying resolutions, depending on the operating system. Stopwatch.Frequency contains the number of ticks per second. On Windows, this is about 300,000 ticks per second.&lt;br /&gt;
# '''TimeSpan''' - 10,000 ticks = 1 millisecond&lt;br /&gt;
# '''Environment.TickCount''' - 1 tick = 1 millisecond&lt;br /&gt;
&lt;br /&gt;
It's recommended to use the '''Stopwatch''' class for timing, because it can measure sub-ms times. You can get the Stopwatch's value in ms by calling '''Stopwatch.ElapsedMilliseconds'''.&lt;br /&gt;
&lt;br /&gt;
If you want to add up times, e.g. to get the total time spent executing a script, then accumulate the the sum using Stopwatch Ticks: again, because this is the only high-resolution timer available. If you do this then you will have a 'long' variable that contains the number of ticks. When you want to convert this value into elapsed time, use code such as this:&lt;br /&gt;
&lt;br /&gt;
 long numStopwatchTicks = xxxx;&lt;br /&gt;
 TimeSpan elapsed = TimeSpan.FromMilliseconds((numStopwatchTicks * 1000) / Stopwatch.Frequency);&lt;br /&gt;
&lt;br /&gt;
=== MetricsCollectorTime ===&lt;br /&gt;
&lt;br /&gt;
The class '''MetricsCollectorTime''' may be useful to you. It implements a sliding window that collects performance measurements. For example, its' used to calculate the total execution time over the past 30 seconds for each script. For example, instantiate it as follows:&lt;br /&gt;
&lt;br /&gt;
 MetricsCollectorTime executionTime = new MetricsCollectorTime(30000, 10);&lt;br /&gt;
&lt;br /&gt;
This creates a sliding window that covers 30 seconds (30000 ms), and has 10 &amp;quot;buckets&amp;quot;. The buckets determine the granularity of the window: in this case, it's 30/10 = 3 seconds.&lt;br /&gt;
&lt;br /&gt;
Whenever you get a timing sample, add it to the collector:&lt;br /&gt;
&lt;br /&gt;
 Stopwatch timer = new Stopwatch();&lt;br /&gt;
 // Measure something with 'timer'...&lt;br /&gt;
 collector.AddSample(timer);&lt;br /&gt;
&lt;br /&gt;
Whenever you want to get the total value in the collection window, call:&lt;br /&gt;
&lt;br /&gt;
 int elapsedMS = collector.GetSumTime().TotalMilliseconds;&lt;br /&gt;
&lt;br /&gt;
MetricsCollectorTime is actually a subclass of the generic MetricsCollector class. The generic class can use any data type as the Sample value. It uses a circular buffer for its buckets, so it's highly efficient.&lt;br /&gt;
&lt;br /&gt;
= Viewer Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Performance issues can be tackled on the viewer side as well as on the OpenSimulator side.  This typically involves lowering viewer graphical settings (e.g. reducing viewer-side draw distance).  See http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923 for more information.&lt;br /&gt;
&lt;br /&gt;
= Simulator Performance Topics =&lt;br /&gt;
&lt;br /&gt;
== Hardware Requirements ==&lt;br /&gt;
Unfortunately, this is a very difficult question in light of all the factors mentioned in the introduction.  Apart from network, the most important &lt;br /&gt;
&lt;br /&gt;
===CPU===&lt;br /&gt;
We can say that OpenSimulator does not run well when it only has access to a single CPU core - you should regard a dual-core machine as the minimum.&lt;br /&gt;
&lt;br /&gt;
An extremely approximate rule of thumb is to have one core per regularly used region, with the minimum of two above.  So a 4 region simulator would need 4 cores.  However, this assumes continuous use of those regions - one could probably get away with a higher core to region ratio if those other regions were much less used (or not used simultaneously).&lt;br /&gt;
&lt;br /&gt;
On OpenSimulator 0.7.6, we have also observed that an idle region (one which has very few if no active scripts and no avatars on it or in neighbouring regions) requires approximately 2.5% of a CPU core.  The requirement before OpenSimulator 0.7.6 was much higher.&lt;br /&gt;
&lt;br /&gt;
We can also say, again extremely approximately, that each active avatar requires 8% CPU.  An active avatar is one that is moving around and the chief cause of this load is physics processing with the ODE physics engine plugin.  Other physics engine plugins, such as Bulletsim, may require less CPU.&lt;br /&gt;
&lt;br /&gt;
Continually running scripts (such as scripts on timers) will also generate continuous CPU load on a region.  A few scripts of this type probably won't have much of an impact, but a larger number of scripts will start to consume CPU resources.&lt;br /&gt;
&lt;br /&gt;
Finally, physics objects (those which have their physics checkbox marked in the viewer and so are moved around by gravity and collisions) will also generate physics CPU load on the simulator if they are not at rest.&lt;br /&gt;
&lt;br /&gt;
===Memory===&lt;br /&gt;
As a rule of thumb, a region with lots of avatars, 15000 or more prims and 2000 scripts may require 1G of memory.  So a simulator with 4 such regions may require 4G.  One could use less memory if not all regions will be occupied with avatars simultaneously, or where the are fewer scripts, for instance.&lt;br /&gt;
&lt;br /&gt;
===Disk===&lt;br /&gt;
At the simulator level, storage performance is not a big issue unless one has scripts which need extremely high performance in rezzing and derezzing objects.  Even in this case, 7200 rpm 3.5&amp;quot; desktop drives are generally sufficient - problems only start to arise with lower performing drives, such as those found in laptops.&lt;br /&gt;
&lt;br /&gt;
At the grid level, faster storage may be useful when handling large numbers of asset, inventory or other service requests.&lt;br /&gt;
&lt;br /&gt;
===Network===&lt;br /&gt;
Download and upload bandwidth and latency are important.  The biggest use of upload bandwidth (from the server point of view) is to provide texture data to viewers.  So a home network with poor bandwidth (e.g. 384 kbits up) will result in a poor experience for viewers, at least until they have received all texture data.  The requirement for upload bandwidth peaks when a viewer enters a region for the first time or after clearing their asset cache.  The amount of bandwidth required will vary heavily with the number of textures on the region.  An extremely approximate rule of thumb is to have 500 kbit per simultaneously logged in avatar if you know that all avatars will be downlaoding textures simultaneously.&lt;br /&gt;
&lt;br /&gt;
The biggest use of download bandwidth (from the server point of view) is to receive the continuous UDP movement messages from connected avatars.  However, in comparison to texture download, the bandwidth required is trivial - an approximate rule of thumb is 10K (80 kbit) per avatar.&lt;br /&gt;
&lt;br /&gt;
Latency is critical on both upload and download to the simulator, since any delay will affect avatar movement packets (download to server from viewer) and updates to the viewer about other object/avatar position changes (upload from server to viewer).  It's much harder to give advice here, though pings of greater than 350 milliseconds will start to degrade the user's experience on moving their avatar.&lt;br /&gt;
&lt;br /&gt;
===Examples===&lt;br /&gt;
Below are some examples of hardware people use/have used.  Please feel free to add to the list, or to add any reports to the performance studies and blog posts section.  '''These are examples to help you in your selection, not recommendations.'''&lt;br /&gt;
&lt;br /&gt;
Object Parts ~= # prim&lt;br /&gt;
&lt;br /&gt;
Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.&lt;br /&gt;
&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
!Description&lt;br /&gt;
!Operating System (please add Mono version if appropriate)&lt;br /&gt;
!OpenSimulator version&lt;br /&gt;
!RAM/AVG_USE_%&lt;br /&gt;
!CPU&lt;br /&gt;
!#/type of regions&lt;br /&gt;
!# simultaneous avs&lt;br /&gt;
!#scripts/timers/Sensors&lt;br /&gt;
!Location&lt;br /&gt;
!#objectparts&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Intrepid (8.10)&lt;br /&gt;
|Unknown&lt;br /&gt;
|540MB/?&lt;br /&gt;
|1x quad-core 2.5GHz Xeon (L5420)&lt;br /&gt;
|1 region + 9 voids&lt;br /&gt;
|generally 1-2&lt;br /&gt;
|few&lt;br /&gt;
|Knifejaw Atoll &amp;amp; surrounding on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Jaunty (9.04)&lt;br /&gt;
|Unknown&lt;br /&gt;
|360MB/?&lt;br /&gt;
|2x dual-core 2.0GHz Xeon (5130)&lt;br /&gt;
|1 void&lt;br /&gt;
|generally 1-2 &lt;br /&gt;
|none&lt;br /&gt;
|Knifejaw Road on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from A+&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1 Meg&lt;br /&gt;
|1x single-core 2.8GHz Celeron&lt;br /&gt;
|2regions per server&lt;br /&gt;
|6 at once with no issues&lt;br /&gt;
|Waterfalls, texture anims, window texture switchers, lots of sound loops&lt;br /&gt;
|Pleasure Planet Welcome center &amp;amp; Region Pleasure Planet in OSGrid&lt;br /&gt;
|20000 prims per region&lt;br /&gt;
|-&lt;br /&gt;
|Amazon EC2 &amp;quot;high-CPU medium instance&amp;quot; (Xen VM)&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1.7GB&lt;br /&gt;
|1x dual-core 2.3GHz (Intel E5345)&lt;br /&gt;
|1 region with sailing race course&lt;br /&gt;
|7 avs, 4 in boats&lt;br /&gt;
|scripted start line&lt;br /&gt;
|Castle Rock, OSGrid&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from simhost.com&lt;br /&gt;
|SuSe 11.2 x64&lt;br /&gt;
|Unknown&lt;br /&gt;
|8gb / 50%&lt;br /&gt;
|4x Core2Quad Q9300 2.6ghz&lt;br /&gt;
|1 region (Wright Plaza) uses approx 4gb ram&lt;br /&gt;
|20-25 users&lt;br /&gt;
|Freebie Stores / Meeting Center / Video Theater&lt;br /&gt;
|@osgrid.org Heavy Use Sim&lt;br /&gt;
|17500 prims aprox 1500 scripts&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Windows XP SP3&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|3GB / 15-40% incl. Opensim and MySQL&lt;br /&gt;
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%&lt;br /&gt;
|11 regions&lt;br /&gt;
|1-6 users&lt;br /&gt;
|Many scripted objects (1934 scripts)&lt;br /&gt;
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]&lt;br /&gt;
|38,065 prims&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Ubuntu Lucid 10.04 (32 bit pae)&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|160Mb no users, add 5Mb/user incl Opensim and MySQL&lt;br /&gt;
|I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load&lt;br /&gt;
|4 regions (Diva default config)&lt;br /&gt;
|1-4 users (approx 20Kb/sec bandwidth/user)&lt;br /&gt;
|Few scripted objects (&amp;lt;10)&lt;br /&gt;
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]&lt;br /&gt;
|158 prims&lt;br /&gt;
|-&lt;br /&gt;
|Hosted Dedicated OVH&lt;br /&gt;
|Suse 12.2&lt;br /&gt;
|0.7.0.2 (D2)&lt;br /&gt;
|420Mb total, incl OS, Opensim and MySQL&lt;br /&gt;
|i7 Quad 950 (Bloomfield) 3.07GHz, 8 Core, 24Gb RAM, 0-1% Avg Load&lt;br /&gt;
|16 regions (4x4 mega-region)&lt;br /&gt;
|&amp;lt;6 users&lt;br /&gt;
|vehicle scripted objects (&amp;lt;5)&lt;br /&gt;
|[http://metaversesailing.com:9000/wifi Metaverse Sailing]&lt;br /&gt;
|&amp;lt;1000 prims&lt;br /&gt;
|-&lt;br /&gt;
|VPS&lt;br /&gt;
|Debian Lenny 5 (mono 2.4.2.3)&lt;br /&gt;
|OSgrid 0.7.1 (Dev) cd4d7a7: 2010-10-15&lt;br /&gt;
|655MB average out of 1722MB RAM, incl. MySQL&lt;br /&gt;
|Intel Quadcore 2.5 Ghz (1 core assigned to vps) average use: 40-45% &lt;br /&gt;
|20 regions&lt;br /&gt;
|&amp;lt;4 users&lt;br /&gt;
|about 20 different light scripts, but we're also experimenting with heavier HUD scripts (timers, lots of ll(Get/Set)PrimitiveParams and large lists) and custom IRC relay&lt;br /&gt;
|Phoenix Rising Isles on OsGrid&lt;br /&gt;
|3727 prims&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator is configured to use the SQLite database.  This is very convenient for an out-of-the-box experience since it requires no configuration.  However, it's not designed for heavy usage, so if you build very quickly or have more than a few people on your simulator then you will start to see performance issues.&lt;br /&gt;
&lt;br /&gt;
Therefore, we recommend that you switch to MySQL as soon as possible.  This will provide a much better experience but will take a little bit of work to set up.  &lt;br /&gt;
&lt;br /&gt;
Unfortunately, tools for migrating OpenSimulator SQLite data to MySQL are currently limited.  Migration is also possible by saving OARs/IARs of your data from sqlite and loading them up once you've reconfigured to use MySQL.&lt;br /&gt;
&lt;br /&gt;
There is also a database plugin for MSSQL but this is not well maintained between OpenSimulator releases.&lt;br /&gt;
&lt;br /&gt;
In standalone mode, both services and the simulator itself can use SQLite.  In grid mode, SQLite is only supported for simulator data - the ROBUST instances must use a MySQL (or MSSQL) database.&lt;br /&gt;
&lt;br /&gt;
In general a single MySQL instance for the ROBUST services instance will serve small, medium and even large grids perfectly well - it's a configuration that's widely used for even quite large websites.&lt;br /&gt;
&lt;br /&gt;
== Scripts ==&lt;br /&gt;
&lt;br /&gt;
See [[Scripts Performance]].&lt;br /&gt;
&lt;br /&gt;
== Configuration tweaks ==&lt;br /&gt;
&lt;br /&gt;
There are a couple of OpenSimulator configuration tweaks that you can do to significantly improve script loading performance in certain situations.  These tweaks can be made in your OpenSim.ini config file.  These apply to current OpenSimulator development code (0.7.3-dev) and may also apply to 0.7.2, though certainly not any earlier.&lt;br /&gt;
&lt;br /&gt;
===Set DeleteScriptsOnStartup = false===&lt;br /&gt;
&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 DeleteScriptsOnStartup = false&lt;br /&gt;
&lt;br /&gt;
This means that OpenSimulator will not delete all the existing compiled script DLLs on startup (don't worry, this setting doesn't touch the actual LSL scripts in your region).  This will significantly improve startup performance.  However, if you upgrade OpenSimulator in place (e.g. you regularly update your installation directly from development code) then you may occasionally see problems if code changes and your previously compiled DLLs can't find their old references.&lt;br /&gt;
&lt;br /&gt;
In this case, you can either set DeleteScriptsOnStartup = true for one restart in order to clean out and recompile script DLLs or you can manually delete the relevant bin/ScriptEngines/&amp;lt;region-uuid&amp;gt;/*.dll.* files, which will force OpenSimulator to recompile them.  You could also delete the entire bin/ScriptEngines/&amp;lt;region-uuid&amp;gt; directory but this would lose all persisted script state (which is kept in the &amp;lt;script-item-id&amp;gt;.state files).&lt;br /&gt;
&lt;br /&gt;
===Set AppDomainLoading = false===&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 AppDomainLoading = false&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator loads every script DLL into its own AppDomain.  If this is set to false, then all scripts are loaded into OpenSimulator's default AppDomain instead.&lt;br /&gt;
&lt;br /&gt;
This will significantly improve script startup times and reduce initial per-script memory overhead.&lt;br /&gt;
&lt;br /&gt;
However, setting this to false will also prevent derezzed script DLLs from being removed from memory (only whole AppDomains can be unloaded).  This might cause an OutOfMemory problem over time, as avatars with scripted attachments move in and out of the region.  Whether this is a problem for you will depend on factors such as the avatar population of your grid.&lt;br /&gt;
&lt;br /&gt;
In addition, Windows users have reported script loading problems with AppDomainLoading = false, though I (justincc) haven't been able to replicate this with current OpenSimulator code on my WindowsXP machine.&lt;br /&gt;
&lt;br /&gt;
===Increase MaxPoolThreads in [Startup]===&lt;br /&gt;
&lt;br /&gt;
At the present time, OpenSimulator uses up to three sets of threads for its operations.  &lt;br /&gt;
&lt;br /&gt;
Firstly, the VM threadpool is always used to process incoming network data.  &lt;br /&gt;
&lt;br /&gt;
Secondly, by default an instance of a third-party threadpool package called SmartThreadPool is used for performing short OpenSimulator tasks.  Performance here is critical since many incoming requests from viewers are handled by threads from this threadpool.&lt;br /&gt;
&lt;br /&gt;
Thirdly, XEngine spawns it's own threadpool for script engine tasks.  However, performance here is not critical.&lt;br /&gt;
&lt;br /&gt;
When using SmartThreadPool, the default MaxPoolThreads parameter in OpenSimulator 0.8 and earlier has turned out to really be too low (at 15 threads) for heavy or possibly even moderate numbers of avatars (e.g. 40).  In current development code, the default has been raised from 15 to 300.  So in release code it's also worth doing if you are seeing issues with viewer lag and your CPU usage is not maxed out already.  To set this to 300, you can make the following change in OpenSim.ini.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
MaxPoolThreads = 300&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Although this will allow more threads to be created (hence using more server resources), this is probably what you want anyway if it all possible, since the alternative is to suffer lag in dealing with viewer's incoming UDP data.  The extra threads will only be created if they are needed.&lt;br /&gt;
&lt;br /&gt;
===Change async_call_method in [Startup]===&lt;br /&gt;
&lt;br /&gt;
Alternatively, you could change the general task threadpool entirely.&lt;br /&gt;
&lt;br /&gt;
It has been set as SmartThreadPool by default somewhat for historical reasons - Mono threadpool performance used to be poor.&lt;br /&gt;
&lt;br /&gt;
However, this may be much better in recent versions of Mono (especially 3.x onwards).  In addition, Windows general threadpool performance may be better than SmartThreadPool.&lt;br /&gt;
&lt;br /&gt;
So on these systems, you may want to try experimenting with a setting of &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = UnsafeQueueUserWorkItems&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
on Windows or even Mono.&lt;br /&gt;
&lt;br /&gt;
On Mac OSX, there is a system called [http://en.wikipedia.org/wiki/Grand_Central_Dispatch Grand Central Dispatch] that effectively implements a threadpool below the VM level.  On these systems, there have been reports that simply setting &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = Thread&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
results in better OpenSimulator performance.  However, at least on OSX you may need to increase the number of file handles per process.  Here's a quote on this topic from Gavin Hird.&lt;br /&gt;
&lt;br /&gt;
&amp;quot;I found that on using the async_call_method = thread the system was running out of open files per process as a large number of threads accessed floatsamcache files concurrently. For any *nix you’d have to adjust the “limit -n” parameter.&lt;br /&gt;
&lt;br /&gt;
On OS X the /etc/launchd.conf file needs a line containing “limit maxfiles 2048 65536″ where 2048 in this case is the number of allowed open files per process, and the higher number the open files per system. The file needs to be created if it does not exist.&lt;br /&gt;
Alternatively the file can be created at ~/launchd.conf for the user running OpenSim.exe if you don’t want it as a systemwide setting.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
= Grid Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Scaling a grid is a complex task and only for the very technically inclined.  It is also an area under active investigation.  The advice below will change considerably over time as OpenSimulator and its environment changes and we learn more about perfomrnace issues.&lt;br /&gt;
&lt;br /&gt;
When would you start to meet grid scaling issues?  As an extremely rough and really quite arbitrary and pessimistic rule of thumb, you will probably start to have to think about things when you exceed 50 regions containing a large number of prims or 50 simultaneous users with large inventories.  But this will very a tremendous amount depending on your situation.  If you have thousands of regions with very few prims that much more supportable than 50 regions with 45000 prims each.&lt;br /&gt;
&lt;br /&gt;
You are likely to encounter issues in two areas - database and services.&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
=== Assets ===&lt;br /&gt;
&lt;br /&gt;
==== The problem ====&lt;br /&gt;
&lt;br /&gt;
Due to the architecture of distributed architecture of OpenSimulator, where regions are running on a number of different machines over a network, it's extremely hard to identify assets that are not in use and hence can be deleted.  Equally, the fact that assets are immutable leads to continual growth in the asset database.&lt;br /&gt;
&lt;br /&gt;
In theory, one could identify unused assets if one could identify all references in simulators and in user inventory.  However, this is extremely hard to do where machines are distributed over a network.  If a grid only has a few simulators all running on machines that are controlled by the same entity running a grid, then it becomes a little more tractable but even then would almost certainly involve significant downtime.  For stand-alone grids, or for environments where assets are not passed between grids (ie: giving a texture to a friend on another grid) [http://was.fm Wizardry and Steamworks] provides an experimental script that will do exactly that. It is currently available at the [http://was.fm/opensim:database:asset_cleaner asset cleaner] project page and published under an MIT license.&lt;br /&gt;
&lt;br /&gt;
Asset deletion would be easier for a one simulator grid or a standalone.  However, even code to implement asset deletion on standalones has not yet been implemented and would certainly require significant simulator downtime.&lt;br /&gt;
&lt;br /&gt;
A promising area of research involves improving OpenSimulator's recording of asset access times (e.g. recording access periodically).  Then assets which aren't accessed for a long time (e.g. a year) could be deleted or moved to cold storage (e.g. DVD).  One is left with the problem of not deleting assets permanently cached by simulators but perhaps this could be solved by the simulators occasionally 'pinging' the asset service with notification of what assets they cache.&lt;br /&gt;
&lt;br /&gt;
Another step to reduce asset database size is to eliminate duplicate assets by hashing.  There is [[Deduplicating Asset Service|an experimental development asset service]] for this.  Third party services such as [[https://github.com/coyled/sras SRAS]] also do this.&lt;br /&gt;
&lt;br /&gt;
==== Possible solutions ====&lt;br /&gt;
&lt;br /&gt;
* If you run a grid for yourself or, if you run a grid where you do not give away your content, then the [http://was.fm/opensim:database:asset_cleaner asset cleaner] from [http://was.fm Wizardry and Steamworks] may be a good solution to track down stray assets and delete them from the database automatically. It is based on dumping OARs and IARs, as per the second option in this section, but after dumping them, it automatically performs the search for you and prompts you to delete several supported assets. Current development is going towards automatically exporting OARs and IARs from PHP so that the procedure is made seamless.&lt;br /&gt;
&lt;br /&gt;
* Save every region to an OAR and every user's inventory to an IAR.  We believe this is equivalent to finding all referenced assets and can be done manually.  However, it's very laborious for installations with a large number of users and requires grid downtime.  Tools could be written to improve this, particularly in systematically saving all user inventories to IARs.&lt;br /&gt;
&lt;br /&gt;
* Do nothing.  MySQL can store a very large amount of data before encountering issues - it's used for extremely large websites and other applications after all.  This assumes you have the disk space.&lt;br /&gt;
&lt;br /&gt;
* Use an external asset service such as [[https://github.com/coyled/sras SRAS]].  SRAS, in particular, is a third party asset service that does deduplication, asset compression, and stores assets on disk rather than in a database.  It also has some nice features like preventing assets being served without deleting them.  It's used by OSGrid, for instance.  However, it does work in a different way from the bundled OpenSimulator asset service (e.g. backup of on-disk assets involves some extra steps compared to just backing up a database).  It also requires a migration step that may take a considerable time if you have an existing asset collection.&lt;br /&gt;
&lt;br /&gt;
=== Other databases ===&lt;br /&gt;
&lt;br /&gt;
The space required by assets far outweighs other data storage requirements so only asset data is generally an issue.&lt;br /&gt;
&lt;br /&gt;
== Services ==&lt;br /&gt;
&lt;br /&gt;
=== The problem ===&lt;br /&gt;
&lt;br /&gt;
The other problem is with handling the number of requests to services when the number of simulators and users grow.  The asset service isn't generally a problem since simulators cache all assets used, though it can form a bottleneck on OAR upload.  The biggest issue is generally caused by users, chiefly due to inventory access and perhaps update last user positions in the GridUser service (and database table).&lt;br /&gt;
&lt;br /&gt;
ROBUST uses an embedded [[http://webserver.codeplex.com/ C# HttpServer]].  Performance comparisons to other Webservers (e.g. Apache) have not been carried out (?) but responses appears to be much, much slower.  As it has been discontinued it's also rather unlikely to have it's performance improved.  In future, OpenSimulator may embed a different HTTP server but this is extremely unlikely in the short term.&lt;br /&gt;
&lt;br /&gt;
=== Possible solutions ===&lt;br /&gt;
&lt;br /&gt;
* Split up services.  By default, ROBUST runs every service in one process.  However, because services are separate from each other, you could run some services (e.g. inventory in one ROBUST instance and other services (e.g. asset) in a different instance, even if they both point to the same database.  Because the embedded C# webserver is slow and possibly not very concurrent, this can achieve significant performance improvements even if all ROBUST instances are running on the same machine.  See [[Configuration#Running multiple ROBUST service instances]] for more information on how to do this.&lt;br /&gt;
&lt;br /&gt;
* Instantiate extra ROBUST copies of problem services (e.g. inventory).  Because services are stateless (akin to a webservice), you can load balance requests between multiple instances using a reverse proxy such as nginx.  Again, because the embedded webserver is probably inefficient, you can achieve performance improvements by running multiple copies of services on the same machine.&lt;br /&gt;
&lt;br /&gt;
* Use an external service based on a more efficient HTTP server, e.g. [https://github.com/coyled/sras SRAS] (asset service only) or [http://code.google.com/p/openmetaverse/ SimianGrid].  Please be aware that SimianGrid uses a different set of simulator &amp;lt;-&amp;gt; service protocols than used by ROBUST.  The necessary SimianGrid adaptors are part of the core OpenSimulator distribution.&lt;br /&gt;
&lt;br /&gt;
* Write your own services to run on an external webserver.  This wouldn't be too hard to do in something like PHP, though one would need to work out the currently undocumented wire formats.  If you do this, please do let us know :)&lt;br /&gt;
&lt;br /&gt;
= Performance studies and blog posts =&lt;br /&gt;
&lt;br /&gt;
These provide some interesting data on the performance limitations of OpenSimulator at various points in time.&lt;br /&gt;
&lt;br /&gt;
* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue.  Physical objects and max avatars are limited by single thread performance in OpenSimulator.&lt;br /&gt;
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.&lt;br /&gt;
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSimulator.  Some of these issues are still valid (e.g. ODE issues).&lt;br /&gt;
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.&lt;br /&gt;
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!--&lt;br /&gt;
&lt;br /&gt;
==Performance hints==&lt;br /&gt;
&lt;br /&gt;
Here are some specific things you might be able to do to improve performance&lt;br /&gt;
&lt;br /&gt;
===Home Based systems===&lt;br /&gt;
&lt;br /&gt;
The most obvious performance difference between a home based cable/dsl system and a &amp;quot;commercial&amp;quot; server is the upload bandwidth. A typical home system allows 100Kb/s upload with 12Mb/s download, a &amp;quot;commercial&amp;quot; system typically has a &amp;quot;symmetrical&amp;quot; bandwidth of say 12Mb/s UP AND DOWN! &amp;quot;Commercial&amp;quot; systems can essentially buy unlimited bandwidth as needed, but it does get expensive to buy bandwidth that you don't need!&lt;br /&gt;
&lt;br /&gt;
In practice this limits the number of &amp;quot;external&amp;quot; users on a &amp;quot;home system&amp;quot; to 4 or 5, but LAN users (NPCs/bots etc.) are essentially unlimited.&lt;br /&gt;
&lt;br /&gt;
A reasonable strategy (i.e. MY strategy) is to use the home system for experimentation and then move the entire sim to a &amp;quot;commercial&amp;quot; VPS service if the sim gets popular (and produces enough $$$ to pay the freight!) &lt;br /&gt;
&lt;br /&gt;
===Running Squid on your region server as a reverse proxy to the asset server===&lt;br /&gt;
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/&amp;lt;br&amp;gt;&lt;br /&gt;
2. Create your [[squid.conf]] configuration file.&amp;lt;br&amp;gt;&lt;br /&gt;
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/&amp;lt;br&amp;gt;&lt;br /&gt;
4. Start everything up!&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.&lt;br /&gt;
&lt;br /&gt;
=== GC_NO_EXPLICIT ===&lt;br /&gt;
&lt;br /&gt;
Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.&lt;br /&gt;
&lt;br /&gt;
$mono-svn-root$/mono&lt;br /&gt;
  mono/metadata/boehm-gc.c&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Index: boehm-gc.c&lt;br /&gt;
===================================================================&lt;br /&gt;
--- boehm-gc.c	(revision 105684)&lt;br /&gt;
+++ boehm-gc.c	(working copy)&lt;br /&gt;
@@ -107,6 +107,10 @@&lt;br /&gt;
 void&lt;br /&gt;
 mono_gc_collect (int generation)&lt;br /&gt;
 {&lt;br /&gt;
+	static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv(&amp;quot;GC_NO_EXPLICIT&amp;quot;)) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {&lt;br /&gt;
+		g_print(&amp;quot;\n --------GC_NO_EXPLICIT \n&amp;quot;);&lt;br /&gt;
+		return;&lt;br /&gt;
+		}&lt;br /&gt;
 	MONO_PROBE_GC_BEGIN (generation);&lt;br /&gt;
 	&lt;br /&gt;
 	GC_gcollect ();&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Not only this, but I recompile the mono runtime:&lt;br /&gt;
&amp;lt;pre&amp;gt;--with-large-heap=yes&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:&lt;br /&gt;
&lt;br /&gt;
 export GC_NO_EXPLICIT=1&lt;br /&gt;
and&lt;br /&gt;
 unset GC_NO_EXPLICIT&lt;br /&gt;
&lt;br /&gt;
What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (&amp;gt;3GB), it is possible might keep mono less apt to do stop world complete collections as often.&lt;br /&gt;
&lt;br /&gt;
--&amp;gt;&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Performance</id>
		<title>Performance</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Performance"/>
				<updated>2015-08-11T10:10:14Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* General Tips */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
OpenSimulator performance is a very complex issue.  Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.&lt;br /&gt;
&lt;br /&gt;
We can break down performance considerations into &lt;br /&gt;
&lt;br /&gt;
# Network issues (bandwidth and latency between viewer and simulator, between simulators and between simulator and grid service).&lt;br /&gt;
# Simulator issues (e.g. number of scene objects, number of textures, number of scripts).&lt;br /&gt;
# Grid issues (chiefly scaling services such as asset, inventory, etc to serve more simulators and users).&lt;br /&gt;
&lt;br /&gt;
The biggest issues are probably network and simulator issues.  &lt;br /&gt;
&lt;br /&gt;
To run a simulator you must have good bandwidth (to download textures), good latency (so that movements are seen and actions processed in a timely manner) and good quality (so that random packet drops don't result in missed actions or other problems).&lt;br /&gt;
&lt;br /&gt;
You must also be aware of your hardware's capabilities.  The more scene objects, scripts and avatars you have, the more memory and CPU will be used.&lt;br /&gt;
&lt;br /&gt;
Grid issues are less important until you reach larger grid sizes (e.g. over 60 simultaneous users).&lt;br /&gt;
&lt;br /&gt;
= Monitoring Performance =&lt;br /&gt;
&lt;br /&gt;
Gathering data to analyze performance issues is an evolving area.  We can split this into [[client side monitoring]] (e.g. statistics you can see from the statistics window on a viewer program) and server side performance analysis.  Server side performance analysis will involve [[monitoring|OpenSimulator server monitoring]] and general system tools (e.g. top on Linux to monitor which processes are taking up CPU/memory and more general monitoring tools such as Zabbix).&lt;br /&gt;
&lt;br /&gt;
= General Tips =&lt;br /&gt;
&lt;br /&gt;
* Where at all possible, don't assume something is a performance bottleneck, measure it!  You might think your asset database is large, for example, but even large asset database seldom cause real issues.&lt;br /&gt;
* Make as many objects phantom as possible.  Phantom objects do not need to be tested for collisions with avatars and other objects, reducing physics frame time and increasing performance.&lt;br /&gt;
* Make as few objects subject to physics (e.g. falling under gravity, movable by other avatars) as possible.  Physics objects need a lot more collision testing than ordinary non-phantom objects.&lt;br /&gt;
* It can be hard to perform measurement at the moment since not a lot of tools exist.  However, one such is [[pCampbot]] which is bundled with OpenSimulator.  This can instantiate a number of simultaneous libomv clients on a simulator that can take certain actions such as clicking things and bouncing aroud.  Apects of it (e.g. appearance) are currently rather buggy and generate a lot of logging guff.&lt;br /&gt;
* If your avatars are twitching a lot or flying around uncontrollably, this is often a signal of dropped packets caused by network issues.  For important packets, the simulator will retry the send 3 times but drop the packet after that.  On the simulator console, the command &amp;quot;show queues&amp;quot; will indicate how many packets the simulator has to resend and the total number of sends.  If the total resends is greater than 10% then this is a signal of network issues, at least between a particular viewer and the simulator.  The problem may be at the user's end (e.g. a bad router being used over wifi, a badly performing ISP) which are difficult to do anything about!&lt;br /&gt;
&lt;br /&gt;
=== 3 Kinds of Ticks ===&lt;br /&gt;
&lt;br /&gt;
If you measure times in C#, be aware that the word &amp;quot;Tick&amp;quot; is overloaded: there are 3 different values for a Tick, and it's important not to mix them.&lt;br /&gt;
&lt;br /&gt;
# '''Stopwatch''' - varying resolutions, depending on the operating system. Stopwatch.Frequency contains the number of ticks per second.&lt;br /&gt;
# '''TimeSpan''' - 10,000 ticks = 1 millisecond&lt;br /&gt;
# '''Environment.TickCount''' - 1 tick = 1 millisecond&lt;br /&gt;
&lt;br /&gt;
It's recommended to use the '''Stopwatch''' class for timing, because it can measure sub-ms times. You can get the Stopwatch's value in ms by calling '''Stopwatch.ElapsedMilliseconds'''.&lt;br /&gt;
&lt;br /&gt;
If you want to add up times, e.g. to get the total time spent executing a script, then accumulate the the sum using Stopwatch Ticks: again, because this is the only high-resolution timer available. If you do this then you will have a 'long' variable that contains the number of ticks. When you want to convert this value into elapsed time, use code such as this:&lt;br /&gt;
&lt;br /&gt;
 long numStopwatchTicks = xxxx;&lt;br /&gt;
 TimeSpan elapsed = TimeSpan.FromMilliseconds((numStopwatchTicks * 1000) / Stopwatch.Frequency);&lt;br /&gt;
&lt;br /&gt;
=== MetricsCollectorTime ===&lt;br /&gt;
&lt;br /&gt;
The class '''MetricsCollectorTime''' may be useful to you. It implements a sliding window that collects performance measurements. For example, its' used to calculate the total execution time over the past 30 seconds for each script. For example, instantiate it as follows:&lt;br /&gt;
&lt;br /&gt;
 MetricsCollectorTime executionTime = new MetricsCollectorTime(30000, 10);&lt;br /&gt;
&lt;br /&gt;
This creates a sliding window that covers 30 seconds (30000 ms), and has 10 &amp;quot;buckets&amp;quot;. The buckets determine the granularity of the window: in this case, it's 30/10 = 3 seconds.&lt;br /&gt;
&lt;br /&gt;
Whenever you get a timing sample, add it to the collector:&lt;br /&gt;
&lt;br /&gt;
 Stopwatch timer = new Stopwatch();&lt;br /&gt;
 // Measure something with 'timer'...&lt;br /&gt;
 collector.AddSample(timer);&lt;br /&gt;
&lt;br /&gt;
Whenever you want to get the total value in the collection window, call:&lt;br /&gt;
&lt;br /&gt;
 int elapsedMS = collector.GetSumTime().TotalMilliseconds;&lt;br /&gt;
&lt;br /&gt;
MetricsCollectorTime is actually a subclass of the generic MetricsCollector class. The generic class can use any data type as the Sample value. It uses a circular buffer for its buckets, so it's highly efficient.&lt;br /&gt;
&lt;br /&gt;
= Viewer Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Performance issues can be tackled on the viewer side as well as on the OpenSimulator side.  This typically involves lowering viewer graphical settings (e.g. reducing viewer-side draw distance).  See http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923 for more information.&lt;br /&gt;
&lt;br /&gt;
= Simulator Performance Topics =&lt;br /&gt;
&lt;br /&gt;
== Hardware Requirements ==&lt;br /&gt;
Unfortunately, this is a very difficult question in light of all the factors mentioned in the introduction.  Apart from network, the most important &lt;br /&gt;
&lt;br /&gt;
===CPU===&lt;br /&gt;
We can say that OpenSimulator does not run well when it only has access to a single CPU core - you should regard a dual-core machine as the minimum.&lt;br /&gt;
&lt;br /&gt;
An extremely approximate rule of thumb is to have one core per regularly used region, with the minimum of two above.  So a 4 region simulator would need 4 cores.  However, this assumes continuous use of those regions - one could probably get away with a higher core to region ratio if those other regions were much less used (or not used simultaneously).&lt;br /&gt;
&lt;br /&gt;
On OpenSimulator 0.7.6, we have also observed that an idle region (one which has very few if no active scripts and no avatars on it or in neighbouring regions) requires approximately 2.5% of a CPU core.  The requirement before OpenSimulator 0.7.6 was much higher.&lt;br /&gt;
&lt;br /&gt;
We can also say, again extremely approximately, that each active avatar requires 8% CPU.  An active avatar is one that is moving around and the chief cause of this load is physics processing with the ODE physics engine plugin.  Other physics engine plugins, such as Bulletsim, may require less CPU.&lt;br /&gt;
&lt;br /&gt;
Continually running scripts (such as scripts on timers) will also generate continuous CPU load on a region.  A few scripts of this type probably won't have much of an impact, but a larger number of scripts will start to consume CPU resources.&lt;br /&gt;
&lt;br /&gt;
Finally, physics objects (those which have their physics checkbox marked in the viewer and so are moved around by gravity and collisions) will also generate physics CPU load on the simulator if they are not at rest.&lt;br /&gt;
&lt;br /&gt;
===Memory===&lt;br /&gt;
As a rule of thumb, a region with lots of avatars, 15000 or more prims and 2000 scripts may require 1G of memory.  So a simulator with 4 such regions may require 4G.  One could use less memory if not all regions will be occupied with avatars simultaneously, or where the are fewer scripts, for instance.&lt;br /&gt;
&lt;br /&gt;
===Disk===&lt;br /&gt;
At the simulator level, storage performance is not a big issue unless one has scripts which need extremely high performance in rezzing and derezzing objects.  Even in this case, 7200 rpm 3.5&amp;quot; desktop drives are generally sufficient - problems only start to arise with lower performing drives, such as those found in laptops.&lt;br /&gt;
&lt;br /&gt;
At the grid level, faster storage may be useful when handling large numbers of asset, inventory or other service requests.&lt;br /&gt;
&lt;br /&gt;
===Network===&lt;br /&gt;
Download and upload bandwidth and latency are important.  The biggest use of upload bandwidth (from the server point of view) is to provide texture data to viewers.  So a home network with poor bandwidth (e.g. 384 kbits up) will result in a poor experience for viewers, at least until they have received all texture data.  The requirement for upload bandwidth peaks when a viewer enters a region for the first time or after clearing their asset cache.  The amount of bandwidth required will vary heavily with the number of textures on the region.  An extremely approximate rule of thumb is to have 500 kbit per simultaneously logged in avatar if you know that all avatars will be downlaoding textures simultaneously.&lt;br /&gt;
&lt;br /&gt;
The biggest use of download bandwidth (from the server point of view) is to receive the continuous UDP movement messages from connected avatars.  However, in comparison to texture download, the bandwidth required is trivial - an approximate rule of thumb is 10K (80 kbit) per avatar.&lt;br /&gt;
&lt;br /&gt;
Latency is critical on both upload and download to the simulator, since any delay will affect avatar movement packets (download to server from viewer) and updates to the viewer about other object/avatar position changes (upload from server to viewer).  It's much harder to give advice here, though pings of greater than 350 milliseconds will start to degrade the user's experience on moving their avatar.&lt;br /&gt;
&lt;br /&gt;
===Examples===&lt;br /&gt;
Below are some examples of hardware people use/have used.  Please feel free to add to the list, or to add any reports to the performance studies and blog posts section.  '''These are examples to help you in your selection, not recommendations.'''&lt;br /&gt;
&lt;br /&gt;
Object Parts ~= # prim&lt;br /&gt;
&lt;br /&gt;
Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.&lt;br /&gt;
&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
!Description&lt;br /&gt;
!Operating System (please add Mono version if appropriate)&lt;br /&gt;
!OpenSimulator version&lt;br /&gt;
!RAM/AVG_USE_%&lt;br /&gt;
!CPU&lt;br /&gt;
!#/type of regions&lt;br /&gt;
!# simultaneous avs&lt;br /&gt;
!#scripts/timers/Sensors&lt;br /&gt;
!Location&lt;br /&gt;
!#objectparts&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Intrepid (8.10)&lt;br /&gt;
|Unknown&lt;br /&gt;
|540MB/?&lt;br /&gt;
|1x quad-core 2.5GHz Xeon (L5420)&lt;br /&gt;
|1 region + 9 voids&lt;br /&gt;
|generally 1-2&lt;br /&gt;
|few&lt;br /&gt;
|Knifejaw Atoll &amp;amp; surrounding on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Jaunty (9.04)&lt;br /&gt;
|Unknown&lt;br /&gt;
|360MB/?&lt;br /&gt;
|2x dual-core 2.0GHz Xeon (5130)&lt;br /&gt;
|1 void&lt;br /&gt;
|generally 1-2 &lt;br /&gt;
|none&lt;br /&gt;
|Knifejaw Road on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from A+&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1 Meg&lt;br /&gt;
|1x single-core 2.8GHz Celeron&lt;br /&gt;
|2regions per server&lt;br /&gt;
|6 at once with no issues&lt;br /&gt;
|Waterfalls, texture anims, window texture switchers, lots of sound loops&lt;br /&gt;
|Pleasure Planet Welcome center &amp;amp; Region Pleasure Planet in OSGrid&lt;br /&gt;
|20000 prims per region&lt;br /&gt;
|-&lt;br /&gt;
|Amazon EC2 &amp;quot;high-CPU medium instance&amp;quot; (Xen VM)&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1.7GB&lt;br /&gt;
|1x dual-core 2.3GHz (Intel E5345)&lt;br /&gt;
|1 region with sailing race course&lt;br /&gt;
|7 avs, 4 in boats&lt;br /&gt;
|scripted start line&lt;br /&gt;
|Castle Rock, OSGrid&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from simhost.com&lt;br /&gt;
|SuSe 11.2 x64&lt;br /&gt;
|Unknown&lt;br /&gt;
|8gb / 50%&lt;br /&gt;
|4x Core2Quad Q9300 2.6ghz&lt;br /&gt;
|1 region (Wright Plaza) uses approx 4gb ram&lt;br /&gt;
|20-25 users&lt;br /&gt;
|Freebie Stores / Meeting Center / Video Theater&lt;br /&gt;
|@osgrid.org Heavy Use Sim&lt;br /&gt;
|17500 prims aprox 1500 scripts&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Windows XP SP3&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|3GB / 15-40% incl. Opensim and MySQL&lt;br /&gt;
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%&lt;br /&gt;
|11 regions&lt;br /&gt;
|1-6 users&lt;br /&gt;
|Many scripted objects (1934 scripts)&lt;br /&gt;
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]&lt;br /&gt;
|38,065 prims&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Ubuntu Lucid 10.04 (32 bit pae)&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|160Mb no users, add 5Mb/user incl Opensim and MySQL&lt;br /&gt;
|I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load&lt;br /&gt;
|4 regions (Diva default config)&lt;br /&gt;
|1-4 users (approx 20Kb/sec bandwidth/user)&lt;br /&gt;
|Few scripted objects (&amp;lt;10)&lt;br /&gt;
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]&lt;br /&gt;
|158 prims&lt;br /&gt;
|-&lt;br /&gt;
|Hosted Dedicated OVH&lt;br /&gt;
|Suse 12.2&lt;br /&gt;
|0.7.0.2 (D2)&lt;br /&gt;
|420Mb total, incl OS, Opensim and MySQL&lt;br /&gt;
|i7 Quad 950 (Bloomfield) 3.07GHz, 8 Core, 24Gb RAM, 0-1% Avg Load&lt;br /&gt;
|16 regions (4x4 mega-region)&lt;br /&gt;
|&amp;lt;6 users&lt;br /&gt;
|vehicle scripted objects (&amp;lt;5)&lt;br /&gt;
|[http://metaversesailing.com:9000/wifi Metaverse Sailing]&lt;br /&gt;
|&amp;lt;1000 prims&lt;br /&gt;
|-&lt;br /&gt;
|VPS&lt;br /&gt;
|Debian Lenny 5 (mono 2.4.2.3)&lt;br /&gt;
|OSgrid 0.7.1 (Dev) cd4d7a7: 2010-10-15&lt;br /&gt;
|655MB average out of 1722MB RAM, incl. MySQL&lt;br /&gt;
|Intel Quadcore 2.5 Ghz (1 core assigned to vps) average use: 40-45% &lt;br /&gt;
|20 regions&lt;br /&gt;
|&amp;lt;4 users&lt;br /&gt;
|about 20 different light scripts, but we're also experimenting with heavier HUD scripts (timers, lots of ll(Get/Set)PrimitiveParams and large lists) and custom IRC relay&lt;br /&gt;
|Phoenix Rising Isles on OsGrid&lt;br /&gt;
|3727 prims&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator is configured to use the SQLite database.  This is very convenient for an out-of-the-box experience since it requires no configuration.  However, it's not designed for heavy usage, so if you build very quickly or have more than a few people on your simulator then you will start to see performance issues.&lt;br /&gt;
&lt;br /&gt;
Therefore, we recommend that you switch to MySQL as soon as possible.  This will provide a much better experience but will take a little bit of work to set up.  &lt;br /&gt;
&lt;br /&gt;
Unfortunately, tools for migrating OpenSimulator SQLite data to MySQL are currently limited.  Migration is also possible by saving OARs/IARs of your data from sqlite and loading them up once you've reconfigured to use MySQL.&lt;br /&gt;
&lt;br /&gt;
There is also a database plugin for MSSQL but this is not well maintained between OpenSimulator releases.&lt;br /&gt;
&lt;br /&gt;
In standalone mode, both services and the simulator itself can use SQLite.  In grid mode, SQLite is only supported for simulator data - the ROBUST instances must use a MySQL (or MSSQL) database.&lt;br /&gt;
&lt;br /&gt;
In general a single MySQL instance for the ROBUST services instance will serve small, medium and even large grids perfectly well - it's a configuration that's widely used for even quite large websites.&lt;br /&gt;
&lt;br /&gt;
== Scripts ==&lt;br /&gt;
&lt;br /&gt;
See [[Scripts Performance]].&lt;br /&gt;
&lt;br /&gt;
== Configuration tweaks ==&lt;br /&gt;
&lt;br /&gt;
There are a couple of OpenSimulator configuration tweaks that you can do to significantly improve script loading performance in certain situations.  These tweaks can be made in your OpenSim.ini config file.  These apply to current OpenSimulator development code (0.7.3-dev) and may also apply to 0.7.2, though certainly not any earlier.&lt;br /&gt;
&lt;br /&gt;
===Set DeleteScriptsOnStartup = false===&lt;br /&gt;
&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 DeleteScriptsOnStartup = false&lt;br /&gt;
&lt;br /&gt;
This means that OpenSimulator will not delete all the existing compiled script DLLs on startup (don't worry, this setting doesn't touch the actual LSL scripts in your region).  This will significantly improve startup performance.  However, if you upgrade OpenSimulator in place (e.g. you regularly update your installation directly from development code) then you may occasionally see problems if code changes and your previously compiled DLLs can't find their old references.&lt;br /&gt;
&lt;br /&gt;
In this case, you can either set DeleteScriptsOnStartup = true for one restart in order to clean out and recompile script DLLs or you can manually delete the relevant bin/ScriptEngines/&amp;lt;region-uuid&amp;gt;/*.dll.* files, which will force OpenSimulator to recompile them.  You could also delete the entire bin/ScriptEngines/&amp;lt;region-uuid&amp;gt; directory but this would lose all persisted script state (which is kept in the &amp;lt;script-item-id&amp;gt;.state files).&lt;br /&gt;
&lt;br /&gt;
===Set AppDomainLoading = false===&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 AppDomainLoading = false&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator loads every script DLL into its own AppDomain.  If this is set to false, then all scripts are loaded into OpenSimulator's default AppDomain instead.&lt;br /&gt;
&lt;br /&gt;
This will significantly improve script startup times and reduce initial per-script memory overhead.&lt;br /&gt;
&lt;br /&gt;
However, setting this to false will also prevent derezzed script DLLs from being removed from memory (only whole AppDomains can be unloaded).  This might cause an OutOfMemory problem over time, as avatars with scripted attachments move in and out of the region.  Whether this is a problem for you will depend on factors such as the avatar population of your grid.&lt;br /&gt;
&lt;br /&gt;
In addition, Windows users have reported script loading problems with AppDomainLoading = false, though I (justincc) haven't been able to replicate this with current OpenSimulator code on my WindowsXP machine.&lt;br /&gt;
&lt;br /&gt;
===Increase MaxPoolThreads in [Startup]===&lt;br /&gt;
&lt;br /&gt;
At the present time, OpenSimulator uses up to three sets of threads for its operations.  &lt;br /&gt;
&lt;br /&gt;
Firstly, the VM threadpool is always used to process incoming network data.  &lt;br /&gt;
&lt;br /&gt;
Secondly, by default an instance of a third-party threadpool package called SmartThreadPool is used for performing short OpenSimulator tasks.  Performance here is critical since many incoming requests from viewers are handled by threads from this threadpool.&lt;br /&gt;
&lt;br /&gt;
Thirdly, XEngine spawns it's own threadpool for script engine tasks.  However, performance here is not critical.&lt;br /&gt;
&lt;br /&gt;
When using SmartThreadPool, the default MaxPoolThreads parameter in OpenSimulator 0.8 and earlier has turned out to really be too low (at 15 threads) for heavy or possibly even moderate numbers of avatars (e.g. 40).  In current development code, the default has been raised from 15 to 300.  So in release code it's also worth doing if you are seeing issues with viewer lag and your CPU usage is not maxed out already.  To set this to 300, you can make the following change in OpenSim.ini.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
MaxPoolThreads = 300&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Although this will allow more threads to be created (hence using more server resources), this is probably what you want anyway if it all possible, since the alternative is to suffer lag in dealing with viewer's incoming UDP data.  The extra threads will only be created if they are needed.&lt;br /&gt;
&lt;br /&gt;
===Change async_call_method in [Startup]===&lt;br /&gt;
&lt;br /&gt;
Alternatively, you could change the general task threadpool entirely.&lt;br /&gt;
&lt;br /&gt;
It has been set as SmartThreadPool by default somewhat for historical reasons - Mono threadpool performance used to be poor.&lt;br /&gt;
&lt;br /&gt;
However, this may be much better in recent versions of Mono (especially 3.x onwards).  In addition, Windows general threadpool performance may be better than SmartThreadPool.&lt;br /&gt;
&lt;br /&gt;
So on these systems, you may want to try experimenting with a setting of &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = UnsafeQueueUserWorkItems&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
on Windows or even Mono.&lt;br /&gt;
&lt;br /&gt;
On Mac OSX, there is a system called [http://en.wikipedia.org/wiki/Grand_Central_Dispatch Grand Central Dispatch] that effectively implements a threadpool below the VM level.  On these systems, there have been reports that simply setting &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = Thread&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
results in better OpenSimulator performance.  However, at least on OSX you may need to increase the number of file handles per process.  Here's a quote on this topic from Gavin Hird.&lt;br /&gt;
&lt;br /&gt;
&amp;quot;I found that on using the async_call_method = thread the system was running out of open files per process as a large number of threads accessed floatsamcache files concurrently. For any *nix you’d have to adjust the “limit -n” parameter.&lt;br /&gt;
&lt;br /&gt;
On OS X the /etc/launchd.conf file needs a line containing “limit maxfiles 2048 65536″ where 2048 in this case is the number of allowed open files per process, and the higher number the open files per system. The file needs to be created if it does not exist.&lt;br /&gt;
Alternatively the file can be created at ~/launchd.conf for the user running OpenSim.exe if you don’t want it as a systemwide setting.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
= Grid Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Scaling a grid is a complex task and only for the very technically inclined.  It is also an area under active investigation.  The advice below will change considerably over time as OpenSimulator and its environment changes and we learn more about perfomrnace issues.&lt;br /&gt;
&lt;br /&gt;
When would you start to meet grid scaling issues?  As an extremely rough and really quite arbitrary and pessimistic rule of thumb, you will probably start to have to think about things when you exceed 50 regions containing a large number of prims or 50 simultaneous users with large inventories.  But this will very a tremendous amount depending on your situation.  If you have thousands of regions with very few prims that much more supportable than 50 regions with 45000 prims each.&lt;br /&gt;
&lt;br /&gt;
You are likely to encounter issues in two areas - database and services.&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
=== Assets ===&lt;br /&gt;
&lt;br /&gt;
==== The problem ====&lt;br /&gt;
&lt;br /&gt;
Due to the architecture of distributed architecture of OpenSimulator, where regions are running on a number of different machines over a network, it's extremely hard to identify assets that are not in use and hence can be deleted.  Equally, the fact that assets are immutable leads to continual growth in the asset database.&lt;br /&gt;
&lt;br /&gt;
In theory, one could identify unused assets if one could identify all references in simulators and in user inventory.  However, this is extremely hard to do where machines are distributed over a network.  If a grid only has a few simulators all running on machines that are controlled by the same entity running a grid, then it becomes a little more tractable but even then would almost certainly involve significant downtime.  For stand-alone grids, or for environments where assets are not passed between grids (ie: giving a texture to a friend on another grid) [http://was.fm Wizardry and Steamworks] provides an experimental script that will do exactly that. It is currently available at the [http://was.fm/opensim:database:asset_cleaner asset cleaner] project page and published under an MIT license.&lt;br /&gt;
&lt;br /&gt;
Asset deletion would be easier for a one simulator grid or a standalone.  However, even code to implement asset deletion on standalones has not yet been implemented and would certainly require significant simulator downtime.&lt;br /&gt;
&lt;br /&gt;
A promising area of research involves improving OpenSimulator's recording of asset access times (e.g. recording access periodically).  Then assets which aren't accessed for a long time (e.g. a year) could be deleted or moved to cold storage (e.g. DVD).  One is left with the problem of not deleting assets permanently cached by simulators but perhaps this could be solved by the simulators occasionally 'pinging' the asset service with notification of what assets they cache.&lt;br /&gt;
&lt;br /&gt;
Another step to reduce asset database size is to eliminate duplicate assets by hashing.  There is [[Deduplicating Asset Service|an experimental development asset service]] for this.  Third party services such as [[https://github.com/coyled/sras SRAS]] also do this.&lt;br /&gt;
&lt;br /&gt;
==== Possible solutions ====&lt;br /&gt;
&lt;br /&gt;
* If you run a grid for yourself or, if you run a grid where you do not give away your content, then the [http://was.fm/opensim:database:asset_cleaner asset cleaner] from [http://was.fm Wizardry and Steamworks] may be a good solution to track down stray assets and delete them from the database automatically. It is based on dumping OARs and IARs, as per the second option in this section, but after dumping them, it automatically performs the search for you and prompts you to delete several supported assets. Current development is going towards automatically exporting OARs and IARs from PHP so that the procedure is made seamless.&lt;br /&gt;
&lt;br /&gt;
* Save every region to an OAR and every user's inventory to an IAR.  We believe this is equivalent to finding all referenced assets and can be done manually.  However, it's very laborious for installations with a large number of users and requires grid downtime.  Tools could be written to improve this, particularly in systematically saving all user inventories to IARs.&lt;br /&gt;
&lt;br /&gt;
* Do nothing.  MySQL can store a very large amount of data before encountering issues - it's used for extremely large websites and other applications after all.  This assumes you have the disk space.&lt;br /&gt;
&lt;br /&gt;
* Use an external asset service such as [[https://github.com/coyled/sras SRAS]].  SRAS, in particular, is a third party asset service that does deduplication, asset compression, and stores assets on disk rather than in a database.  It also has some nice features like preventing assets being served without deleting them.  It's used by OSGrid, for instance.  However, it does work in a different way from the bundled OpenSimulator asset service (e.g. backup of on-disk assets involves some extra steps compared to just backing up a database).  It also requires a migration step that may take a considerable time if you have an existing asset collection.&lt;br /&gt;
&lt;br /&gt;
=== Other databases ===&lt;br /&gt;
&lt;br /&gt;
The space required by assets far outweighs other data storage requirements so only asset data is generally an issue.&lt;br /&gt;
&lt;br /&gt;
== Services ==&lt;br /&gt;
&lt;br /&gt;
=== The problem ===&lt;br /&gt;
&lt;br /&gt;
The other problem is with handling the number of requests to services when the number of simulators and users grow.  The asset service isn't generally a problem since simulators cache all assets used, though it can form a bottleneck on OAR upload.  The biggest issue is generally caused by users, chiefly due to inventory access and perhaps update last user positions in the GridUser service (and database table).&lt;br /&gt;
&lt;br /&gt;
ROBUST uses an embedded [[http://webserver.codeplex.com/ C# HttpServer]].  Performance comparisons to other Webservers (e.g. Apache) have not been carried out (?) but responses appears to be much, much slower.  As it has been discontinued it's also rather unlikely to have it's performance improved.  In future, OpenSimulator may embed a different HTTP server but this is extremely unlikely in the short term.&lt;br /&gt;
&lt;br /&gt;
=== Possible solutions ===&lt;br /&gt;
&lt;br /&gt;
* Split up services.  By default, ROBUST runs every service in one process.  However, because services are separate from each other, you could run some services (e.g. inventory in one ROBUST instance and other services (e.g. asset) in a different instance, even if they both point to the same database.  Because the embedded C# webserver is slow and possibly not very concurrent, this can achieve significant performance improvements even if all ROBUST instances are running on the same machine.  See [[Configuration#Running multiple ROBUST service instances]] for more information on how to do this.&lt;br /&gt;
&lt;br /&gt;
* Instantiate extra ROBUST copies of problem services (e.g. inventory).  Because services are stateless (akin to a webservice), you can load balance requests between multiple instances using a reverse proxy such as nginx.  Again, because the embedded webserver is probably inefficient, you can achieve performance improvements by running multiple copies of services on the same machine.&lt;br /&gt;
&lt;br /&gt;
* Use an external service based on a more efficient HTTP server, e.g. [https://github.com/coyled/sras SRAS] (asset service only) or [http://code.google.com/p/openmetaverse/ SimianGrid].  Please be aware that SimianGrid uses a different set of simulator &amp;lt;-&amp;gt; service protocols than used by ROBUST.  The necessary SimianGrid adaptors are part of the core OpenSimulator distribution.&lt;br /&gt;
&lt;br /&gt;
* Write your own services to run on an external webserver.  This wouldn't be too hard to do in something like PHP, though one would need to work out the currently undocumented wire formats.  If you do this, please do let us know :)&lt;br /&gt;
&lt;br /&gt;
= Performance studies and blog posts =&lt;br /&gt;
&lt;br /&gt;
These provide some interesting data on the performance limitations of OpenSimulator at various points in time.&lt;br /&gt;
&lt;br /&gt;
* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue.  Physical objects and max avatars are limited by single thread performance in OpenSimulator.&lt;br /&gt;
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.&lt;br /&gt;
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSimulator.  Some of these issues are still valid (e.g. ODE issues).&lt;br /&gt;
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.&lt;br /&gt;
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!--&lt;br /&gt;
&lt;br /&gt;
==Performance hints==&lt;br /&gt;
&lt;br /&gt;
Here are some specific things you might be able to do to improve performance&lt;br /&gt;
&lt;br /&gt;
===Home Based systems===&lt;br /&gt;
&lt;br /&gt;
The most obvious performance difference between a home based cable/dsl system and a &amp;quot;commercial&amp;quot; server is the upload bandwidth. A typical home system allows 100Kb/s upload with 12Mb/s download, a &amp;quot;commercial&amp;quot; system typically has a &amp;quot;symmetrical&amp;quot; bandwidth of say 12Mb/s UP AND DOWN! &amp;quot;Commercial&amp;quot; systems can essentially buy unlimited bandwidth as needed, but it does get expensive to buy bandwidth that you don't need!&lt;br /&gt;
&lt;br /&gt;
In practice this limits the number of &amp;quot;external&amp;quot; users on a &amp;quot;home system&amp;quot; to 4 or 5, but LAN users (NPCs/bots etc.) are essentially unlimited.&lt;br /&gt;
&lt;br /&gt;
A reasonable strategy (i.e. MY strategy) is to use the home system for experimentation and then move the entire sim to a &amp;quot;commercial&amp;quot; VPS service if the sim gets popular (and produces enough $$$ to pay the freight!) &lt;br /&gt;
&lt;br /&gt;
===Running Squid on your region server as a reverse proxy to the asset server===&lt;br /&gt;
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/&amp;lt;br&amp;gt;&lt;br /&gt;
2. Create your [[squid.conf]] configuration file.&amp;lt;br&amp;gt;&lt;br /&gt;
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/&amp;lt;br&amp;gt;&lt;br /&gt;
4. Start everything up!&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.&lt;br /&gt;
&lt;br /&gt;
=== GC_NO_EXPLICIT ===&lt;br /&gt;
&lt;br /&gt;
Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.&lt;br /&gt;
&lt;br /&gt;
$mono-svn-root$/mono&lt;br /&gt;
  mono/metadata/boehm-gc.c&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Index: boehm-gc.c&lt;br /&gt;
===================================================================&lt;br /&gt;
--- boehm-gc.c	(revision 105684)&lt;br /&gt;
+++ boehm-gc.c	(working copy)&lt;br /&gt;
@@ -107,6 +107,10 @@&lt;br /&gt;
 void&lt;br /&gt;
 mono_gc_collect (int generation)&lt;br /&gt;
 {&lt;br /&gt;
+	static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv(&amp;quot;GC_NO_EXPLICIT&amp;quot;)) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {&lt;br /&gt;
+		g_print(&amp;quot;\n --------GC_NO_EXPLICIT \n&amp;quot;);&lt;br /&gt;
+		return;&lt;br /&gt;
+		}&lt;br /&gt;
 	MONO_PROBE_GC_BEGIN (generation);&lt;br /&gt;
 	&lt;br /&gt;
 	GC_gcollect ();&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Not only this, but I recompile the mono runtime:&lt;br /&gt;
&amp;lt;pre&amp;gt;--with-large-heap=yes&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:&lt;br /&gt;
&lt;br /&gt;
 export GC_NO_EXPLICIT=1&lt;br /&gt;
and&lt;br /&gt;
 unset GC_NO_EXPLICIT&lt;br /&gt;
&lt;br /&gt;
What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (&amp;gt;3GB), it is possible might keep mono less apt to do stop world complete collections as often.&lt;br /&gt;
&lt;br /&gt;
--&amp;gt;&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Performance</id>
		<title>Performance</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Performance"/>
				<updated>2015-08-11T09:59:23Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* General Tips */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
OpenSimulator performance is a very complex issue.  Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.&lt;br /&gt;
&lt;br /&gt;
We can break down performance considerations into &lt;br /&gt;
&lt;br /&gt;
# Network issues (bandwidth and latency between viewer and simulator, between simulators and between simulator and grid service).&lt;br /&gt;
# Simulator issues (e.g. number of scene objects, number of textures, number of scripts).&lt;br /&gt;
# Grid issues (chiefly scaling services such as asset, inventory, etc to serve more simulators and users).&lt;br /&gt;
&lt;br /&gt;
The biggest issues are probably network and simulator issues.  &lt;br /&gt;
&lt;br /&gt;
To run a simulator you must have good bandwidth (to download textures), good latency (so that movements are seen and actions processed in a timely manner) and good quality (so that random packet drops don't result in missed actions or other problems).&lt;br /&gt;
&lt;br /&gt;
You must also be aware of your hardware's capabilities.  The more scene objects, scripts and avatars you have, the more memory and CPU will be used.&lt;br /&gt;
&lt;br /&gt;
Grid issues are less important until you reach larger grid sizes (e.g. over 60 simultaneous users).&lt;br /&gt;
&lt;br /&gt;
= Monitoring Performance =&lt;br /&gt;
&lt;br /&gt;
Gathering data to analyze performance issues is an evolving area.  We can split this into [[client side monitoring]] (e.g. statistics you can see from the statistics window on a viewer program) and server side performance analysis.  Server side performance analysis will involve [[monitoring|OpenSimulator server monitoring]] and general system tools (e.g. top on Linux to monitor which processes are taking up CPU/memory and more general monitoring tools such as Zabbix).&lt;br /&gt;
&lt;br /&gt;
= General Tips =&lt;br /&gt;
&lt;br /&gt;
* Where at all possible, don't assume something is a performance bottleneck, measure it!  You might think your asset database is large, for example, but even large asset database seldom cause real issues.&lt;br /&gt;
* Make as many objects phantom as possible.  Phantom objects do not need to be tested for collisions with avatars and other objects, reducing physics frame time and increasing performance.&lt;br /&gt;
* Make as few objects subject to physics (e.g. falling under gravity, movable by other avatars) as possible.  Physics objects need a lot more collision testing than ordinary non-phantom objects.&lt;br /&gt;
* It can be hard to perform measurement at the moment since not a lot of tools exist.  However, one such is [[pCampbot]] which is bundled with OpenSimulator.  This can instantiate a number of simultaneous libomv clients on a simulator that can take certain actions such as clicking things and bouncing aroud.  Apects of it (e.g. appearance) are currently rather buggy and generate a lot of logging guff.&lt;br /&gt;
* If your avatars are twitching a lot or flying around uncontrollably, this is often a signal of dropped packets caused by network issues.  For important packets, the simulator will retry the send 3 times but drop the packet after that.  On the simulator console, the command &amp;quot;show queues&amp;quot; will indicate how many packets the simulator has to resend and the total number of sends.  If the total resends is greater than 10% then this is a signal of network issues, at least between a particular viewer and the simulator.  The problem may be at the user's end (e.g. a bad router being used over wifi, a badly performing ISP) which are difficult to do anything about!&lt;br /&gt;
&lt;br /&gt;
=== 3 Kinds of Ticks ===&lt;br /&gt;
&lt;br /&gt;
If you measure times in C#, be aware that the word &amp;quot;Tick&amp;quot; is overloaded: there are 3 different values for a Tick, and it's important not to mix them.&lt;br /&gt;
&lt;br /&gt;
# '''Stopwatch''' - varying resolutions, depending on the operating system. Stopwatch.Frequency contains the number of ticks per second.&lt;br /&gt;
# '''TimeSpan''' - 10,000 ticks = 1 millisecond&lt;br /&gt;
# '''Environment.TickCount''' - 1 tick = 1 millisecond&lt;br /&gt;
&lt;br /&gt;
It's recommended to use the '''Stopwatch''' class for timing, because it can measure sub-ms times. You can get the Stopwatch's value in ms by calling '''Stopwatch.ElapsedMilliseconds'''.&lt;br /&gt;
&lt;br /&gt;
If you want to add up times, e.g. to get the total time spent executing a script, then accumulate the the sum using Stopwatch Ticks: again, because this is the only high-resolution timer available. If you do this then you will have a 'long' variable that contains the number of ticks. When you want to convert this value into elapsed time, use code such as this:&lt;br /&gt;
&lt;br /&gt;
 long numStopwatchTicks = xxxx;&lt;br /&gt;
 TimeSpan elapsed = TimeSpan.FromMilliseconds((numStopwatchTicks * 1000) / Stopwatch.Frequency);&lt;br /&gt;
&lt;br /&gt;
= Viewer Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Performance issues can be tackled on the viewer side as well as on the OpenSimulator side.  This typically involves lowering viewer graphical settings (e.g. reducing viewer-side draw distance).  See http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923 for more information.&lt;br /&gt;
&lt;br /&gt;
= Simulator Performance Topics =&lt;br /&gt;
&lt;br /&gt;
== Hardware Requirements ==&lt;br /&gt;
Unfortunately, this is a very difficult question in light of all the factors mentioned in the introduction.  Apart from network, the most important &lt;br /&gt;
&lt;br /&gt;
===CPU===&lt;br /&gt;
We can say that OpenSimulator does not run well when it only has access to a single CPU core - you should regard a dual-core machine as the minimum.&lt;br /&gt;
&lt;br /&gt;
An extremely approximate rule of thumb is to have one core per regularly used region, with the minimum of two above.  So a 4 region simulator would need 4 cores.  However, this assumes continuous use of those regions - one could probably get away with a higher core to region ratio if those other regions were much less used (or not used simultaneously).&lt;br /&gt;
&lt;br /&gt;
On OpenSimulator 0.7.6, we have also observed that an idle region (one which has very few if no active scripts and no avatars on it or in neighbouring regions) requires approximately 2.5% of a CPU core.  The requirement before OpenSimulator 0.7.6 was much higher.&lt;br /&gt;
&lt;br /&gt;
We can also say, again extremely approximately, that each active avatar requires 8% CPU.  An active avatar is one that is moving around and the chief cause of this load is physics processing with the ODE physics engine plugin.  Other physics engine plugins, such as Bulletsim, may require less CPU.&lt;br /&gt;
&lt;br /&gt;
Continually running scripts (such as scripts on timers) will also generate continuous CPU load on a region.  A few scripts of this type probably won't have much of an impact, but a larger number of scripts will start to consume CPU resources.&lt;br /&gt;
&lt;br /&gt;
Finally, physics objects (those which have their physics checkbox marked in the viewer and so are moved around by gravity and collisions) will also generate physics CPU load on the simulator if they are not at rest.&lt;br /&gt;
&lt;br /&gt;
===Memory===&lt;br /&gt;
As a rule of thumb, a region with lots of avatars, 15000 or more prims and 2000 scripts may require 1G of memory.  So a simulator with 4 such regions may require 4G.  One could use less memory if not all regions will be occupied with avatars simultaneously, or where the are fewer scripts, for instance.&lt;br /&gt;
&lt;br /&gt;
===Disk===&lt;br /&gt;
At the simulator level, storage performance is not a big issue unless one has scripts which need extremely high performance in rezzing and derezzing objects.  Even in this case, 7200 rpm 3.5&amp;quot; desktop drives are generally sufficient - problems only start to arise with lower performing drives, such as those found in laptops.&lt;br /&gt;
&lt;br /&gt;
At the grid level, faster storage may be useful when handling large numbers of asset, inventory or other service requests.&lt;br /&gt;
&lt;br /&gt;
===Network===&lt;br /&gt;
Download and upload bandwidth and latency are important.  The biggest use of upload bandwidth (from the server point of view) is to provide texture data to viewers.  So a home network with poor bandwidth (e.g. 384 kbits up) will result in a poor experience for viewers, at least until they have received all texture data.  The requirement for upload bandwidth peaks when a viewer enters a region for the first time or after clearing their asset cache.  The amount of bandwidth required will vary heavily with the number of textures on the region.  An extremely approximate rule of thumb is to have 500 kbit per simultaneously logged in avatar if you know that all avatars will be downlaoding textures simultaneously.&lt;br /&gt;
&lt;br /&gt;
The biggest use of download bandwidth (from the server point of view) is to receive the continuous UDP movement messages from connected avatars.  However, in comparison to texture download, the bandwidth required is trivial - an approximate rule of thumb is 10K (80 kbit) per avatar.&lt;br /&gt;
&lt;br /&gt;
Latency is critical on both upload and download to the simulator, since any delay will affect avatar movement packets (download to server from viewer) and updates to the viewer about other object/avatar position changes (upload from server to viewer).  It's much harder to give advice here, though pings of greater than 350 milliseconds will start to degrade the user's experience on moving their avatar.&lt;br /&gt;
&lt;br /&gt;
===Examples===&lt;br /&gt;
Below are some examples of hardware people use/have used.  Please feel free to add to the list, or to add any reports to the performance studies and blog posts section.  '''These are examples to help you in your selection, not recommendations.'''&lt;br /&gt;
&lt;br /&gt;
Object Parts ~= # prim&lt;br /&gt;
&lt;br /&gt;
Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.&lt;br /&gt;
&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
!Description&lt;br /&gt;
!Operating System (please add Mono version if appropriate)&lt;br /&gt;
!OpenSimulator version&lt;br /&gt;
!RAM/AVG_USE_%&lt;br /&gt;
!CPU&lt;br /&gt;
!#/type of regions&lt;br /&gt;
!# simultaneous avs&lt;br /&gt;
!#scripts/timers/Sensors&lt;br /&gt;
!Location&lt;br /&gt;
!#objectparts&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Intrepid (8.10)&lt;br /&gt;
|Unknown&lt;br /&gt;
|540MB/?&lt;br /&gt;
|1x quad-core 2.5GHz Xeon (L5420)&lt;br /&gt;
|1 region + 9 voids&lt;br /&gt;
|generally 1-2&lt;br /&gt;
|few&lt;br /&gt;
|Knifejaw Atoll &amp;amp; surrounding on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Jaunty (9.04)&lt;br /&gt;
|Unknown&lt;br /&gt;
|360MB/?&lt;br /&gt;
|2x dual-core 2.0GHz Xeon (5130)&lt;br /&gt;
|1 void&lt;br /&gt;
|generally 1-2 &lt;br /&gt;
|none&lt;br /&gt;
|Knifejaw Road on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from A+&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1 Meg&lt;br /&gt;
|1x single-core 2.8GHz Celeron&lt;br /&gt;
|2regions per server&lt;br /&gt;
|6 at once with no issues&lt;br /&gt;
|Waterfalls, texture anims, window texture switchers, lots of sound loops&lt;br /&gt;
|Pleasure Planet Welcome center &amp;amp; Region Pleasure Planet in OSGrid&lt;br /&gt;
|20000 prims per region&lt;br /&gt;
|-&lt;br /&gt;
|Amazon EC2 &amp;quot;high-CPU medium instance&amp;quot; (Xen VM)&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1.7GB&lt;br /&gt;
|1x dual-core 2.3GHz (Intel E5345)&lt;br /&gt;
|1 region with sailing race course&lt;br /&gt;
|7 avs, 4 in boats&lt;br /&gt;
|scripted start line&lt;br /&gt;
|Castle Rock, OSGrid&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from simhost.com&lt;br /&gt;
|SuSe 11.2 x64&lt;br /&gt;
|Unknown&lt;br /&gt;
|8gb / 50%&lt;br /&gt;
|4x Core2Quad Q9300 2.6ghz&lt;br /&gt;
|1 region (Wright Plaza) uses approx 4gb ram&lt;br /&gt;
|20-25 users&lt;br /&gt;
|Freebie Stores / Meeting Center / Video Theater&lt;br /&gt;
|@osgrid.org Heavy Use Sim&lt;br /&gt;
|17500 prims aprox 1500 scripts&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Windows XP SP3&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|3GB / 15-40% incl. Opensim and MySQL&lt;br /&gt;
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%&lt;br /&gt;
|11 regions&lt;br /&gt;
|1-6 users&lt;br /&gt;
|Many scripted objects (1934 scripts)&lt;br /&gt;
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]&lt;br /&gt;
|38,065 prims&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Ubuntu Lucid 10.04 (32 bit pae)&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|160Mb no users, add 5Mb/user incl Opensim and MySQL&lt;br /&gt;
|I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load&lt;br /&gt;
|4 regions (Diva default config)&lt;br /&gt;
|1-4 users (approx 20Kb/sec bandwidth/user)&lt;br /&gt;
|Few scripted objects (&amp;lt;10)&lt;br /&gt;
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]&lt;br /&gt;
|158 prims&lt;br /&gt;
|-&lt;br /&gt;
|Hosted Dedicated OVH&lt;br /&gt;
|Suse 12.2&lt;br /&gt;
|0.7.0.2 (D2)&lt;br /&gt;
|420Mb total, incl OS, Opensim and MySQL&lt;br /&gt;
|i7 Quad 950 (Bloomfield) 3.07GHz, 8 Core, 24Gb RAM, 0-1% Avg Load&lt;br /&gt;
|16 regions (4x4 mega-region)&lt;br /&gt;
|&amp;lt;6 users&lt;br /&gt;
|vehicle scripted objects (&amp;lt;5)&lt;br /&gt;
|[http://metaversesailing.com:9000/wifi Metaverse Sailing]&lt;br /&gt;
|&amp;lt;1000 prims&lt;br /&gt;
|-&lt;br /&gt;
|VPS&lt;br /&gt;
|Debian Lenny 5 (mono 2.4.2.3)&lt;br /&gt;
|OSgrid 0.7.1 (Dev) cd4d7a7: 2010-10-15&lt;br /&gt;
|655MB average out of 1722MB RAM, incl. MySQL&lt;br /&gt;
|Intel Quadcore 2.5 Ghz (1 core assigned to vps) average use: 40-45% &lt;br /&gt;
|20 regions&lt;br /&gt;
|&amp;lt;4 users&lt;br /&gt;
|about 20 different light scripts, but we're also experimenting with heavier HUD scripts (timers, lots of ll(Get/Set)PrimitiveParams and large lists) and custom IRC relay&lt;br /&gt;
|Phoenix Rising Isles on OsGrid&lt;br /&gt;
|3727 prims&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator is configured to use the SQLite database.  This is very convenient for an out-of-the-box experience since it requires no configuration.  However, it's not designed for heavy usage, so if you build very quickly or have more than a few people on your simulator then you will start to see performance issues.&lt;br /&gt;
&lt;br /&gt;
Therefore, we recommend that you switch to MySQL as soon as possible.  This will provide a much better experience but will take a little bit of work to set up.  &lt;br /&gt;
&lt;br /&gt;
Unfortunately, tools for migrating OpenSimulator SQLite data to MySQL are currently limited.  Migration is also possible by saving OARs/IARs of your data from sqlite and loading them up once you've reconfigured to use MySQL.&lt;br /&gt;
&lt;br /&gt;
There is also a database plugin for MSSQL but this is not well maintained between OpenSimulator releases.&lt;br /&gt;
&lt;br /&gt;
In standalone mode, both services and the simulator itself can use SQLite.  In grid mode, SQLite is only supported for simulator data - the ROBUST instances must use a MySQL (or MSSQL) database.&lt;br /&gt;
&lt;br /&gt;
In general a single MySQL instance for the ROBUST services instance will serve small, medium and even large grids perfectly well - it's a configuration that's widely used for even quite large websites.&lt;br /&gt;
&lt;br /&gt;
== Scripts ==&lt;br /&gt;
&lt;br /&gt;
See [[Scripts Performance]].&lt;br /&gt;
&lt;br /&gt;
== Configuration tweaks ==&lt;br /&gt;
&lt;br /&gt;
There are a couple of OpenSimulator configuration tweaks that you can do to significantly improve script loading performance in certain situations.  These tweaks can be made in your OpenSim.ini config file.  These apply to current OpenSimulator development code (0.7.3-dev) and may also apply to 0.7.2, though certainly not any earlier.&lt;br /&gt;
&lt;br /&gt;
===Set DeleteScriptsOnStartup = false===&lt;br /&gt;
&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 DeleteScriptsOnStartup = false&lt;br /&gt;
&lt;br /&gt;
This means that OpenSimulator will not delete all the existing compiled script DLLs on startup (don't worry, this setting doesn't touch the actual LSL scripts in your region).  This will significantly improve startup performance.  However, if you upgrade OpenSimulator in place (e.g. you regularly update your installation directly from development code) then you may occasionally see problems if code changes and your previously compiled DLLs can't find their old references.&lt;br /&gt;
&lt;br /&gt;
In this case, you can either set DeleteScriptsOnStartup = true for one restart in order to clean out and recompile script DLLs or you can manually delete the relevant bin/ScriptEngines/&amp;lt;region-uuid&amp;gt;/*.dll.* files, which will force OpenSimulator to recompile them.  You could also delete the entire bin/ScriptEngines/&amp;lt;region-uuid&amp;gt; directory but this would lose all persisted script state (which is kept in the &amp;lt;script-item-id&amp;gt;.state files).&lt;br /&gt;
&lt;br /&gt;
===Set AppDomainLoading = false===&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 AppDomainLoading = false&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator loads every script DLL into its own AppDomain.  If this is set to false, then all scripts are loaded into OpenSimulator's default AppDomain instead.&lt;br /&gt;
&lt;br /&gt;
This will significantly improve script startup times and reduce initial per-script memory overhead.&lt;br /&gt;
&lt;br /&gt;
However, setting this to false will also prevent derezzed script DLLs from being removed from memory (only whole AppDomains can be unloaded).  This might cause an OutOfMemory problem over time, as avatars with scripted attachments move in and out of the region.  Whether this is a problem for you will depend on factors such as the avatar population of your grid.&lt;br /&gt;
&lt;br /&gt;
In addition, Windows users have reported script loading problems with AppDomainLoading = false, though I (justincc) haven't been able to replicate this with current OpenSimulator code on my WindowsXP machine.&lt;br /&gt;
&lt;br /&gt;
===Increase MaxPoolThreads in [Startup]===&lt;br /&gt;
&lt;br /&gt;
At the present time, OpenSimulator uses up to three sets of threads for its operations.  &lt;br /&gt;
&lt;br /&gt;
Firstly, the VM threadpool is always used to process incoming network data.  &lt;br /&gt;
&lt;br /&gt;
Secondly, by default an instance of a third-party threadpool package called SmartThreadPool is used for performing short OpenSimulator tasks.  Performance here is critical since many incoming requests from viewers are handled by threads from this threadpool.&lt;br /&gt;
&lt;br /&gt;
Thirdly, XEngine spawns it's own threadpool for script engine tasks.  However, performance here is not critical.&lt;br /&gt;
&lt;br /&gt;
When using SmartThreadPool, the default MaxPoolThreads parameter in OpenSimulator 0.8 and earlier has turned out to really be too low (at 15 threads) for heavy or possibly even moderate numbers of avatars (e.g. 40).  In current development code, the default has been raised from 15 to 300.  So in release code it's also worth doing if you are seeing issues with viewer lag and your CPU usage is not maxed out already.  To set this to 300, you can make the following change in OpenSim.ini.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
MaxPoolThreads = 300&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Although this will allow more threads to be created (hence using more server resources), this is probably what you want anyway if it all possible, since the alternative is to suffer lag in dealing with viewer's incoming UDP data.  The extra threads will only be created if they are needed.&lt;br /&gt;
&lt;br /&gt;
===Change async_call_method in [Startup]===&lt;br /&gt;
&lt;br /&gt;
Alternatively, you could change the general task threadpool entirely.&lt;br /&gt;
&lt;br /&gt;
It has been set as SmartThreadPool by default somewhat for historical reasons - Mono threadpool performance used to be poor.&lt;br /&gt;
&lt;br /&gt;
However, this may be much better in recent versions of Mono (especially 3.x onwards).  In addition, Windows general threadpool performance may be better than SmartThreadPool.&lt;br /&gt;
&lt;br /&gt;
So on these systems, you may want to try experimenting with a setting of &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = UnsafeQueueUserWorkItems&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
on Windows or even Mono.&lt;br /&gt;
&lt;br /&gt;
On Mac OSX, there is a system called [http://en.wikipedia.org/wiki/Grand_Central_Dispatch Grand Central Dispatch] that effectively implements a threadpool below the VM level.  On these systems, there have been reports that simply setting &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = Thread&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
results in better OpenSimulator performance.  However, at least on OSX you may need to increase the number of file handles per process.  Here's a quote on this topic from Gavin Hird.&lt;br /&gt;
&lt;br /&gt;
&amp;quot;I found that on using the async_call_method = thread the system was running out of open files per process as a large number of threads accessed floatsamcache files concurrently. For any *nix you’d have to adjust the “limit -n” parameter.&lt;br /&gt;
&lt;br /&gt;
On OS X the /etc/launchd.conf file needs a line containing “limit maxfiles 2048 65536″ where 2048 in this case is the number of allowed open files per process, and the higher number the open files per system. The file needs to be created if it does not exist.&lt;br /&gt;
Alternatively the file can be created at ~/launchd.conf for the user running OpenSim.exe if you don’t want it as a systemwide setting.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
= Grid Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Scaling a grid is a complex task and only for the very technically inclined.  It is also an area under active investigation.  The advice below will change considerably over time as OpenSimulator and its environment changes and we learn more about perfomrnace issues.&lt;br /&gt;
&lt;br /&gt;
When would you start to meet grid scaling issues?  As an extremely rough and really quite arbitrary and pessimistic rule of thumb, you will probably start to have to think about things when you exceed 50 regions containing a large number of prims or 50 simultaneous users with large inventories.  But this will very a tremendous amount depending on your situation.  If you have thousands of regions with very few prims that much more supportable than 50 regions with 45000 prims each.&lt;br /&gt;
&lt;br /&gt;
You are likely to encounter issues in two areas - database and services.&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
=== Assets ===&lt;br /&gt;
&lt;br /&gt;
==== The problem ====&lt;br /&gt;
&lt;br /&gt;
Due to the architecture of distributed architecture of OpenSimulator, where regions are running on a number of different machines over a network, it's extremely hard to identify assets that are not in use and hence can be deleted.  Equally, the fact that assets are immutable leads to continual growth in the asset database.&lt;br /&gt;
&lt;br /&gt;
In theory, one could identify unused assets if one could identify all references in simulators and in user inventory.  However, this is extremely hard to do where machines are distributed over a network.  If a grid only has a few simulators all running on machines that are controlled by the same entity running a grid, then it becomes a little more tractable but even then would almost certainly involve significant downtime.  For stand-alone grids, or for environments where assets are not passed between grids (ie: giving a texture to a friend on another grid) [http://was.fm Wizardry and Steamworks] provides an experimental script that will do exactly that. It is currently available at the [http://was.fm/opensim:database:asset_cleaner asset cleaner] project page and published under an MIT license.&lt;br /&gt;
&lt;br /&gt;
Asset deletion would be easier for a one simulator grid or a standalone.  However, even code to implement asset deletion on standalones has not yet been implemented and would certainly require significant simulator downtime.&lt;br /&gt;
&lt;br /&gt;
A promising area of research involves improving OpenSimulator's recording of asset access times (e.g. recording access periodically).  Then assets which aren't accessed for a long time (e.g. a year) could be deleted or moved to cold storage (e.g. DVD).  One is left with the problem of not deleting assets permanently cached by simulators but perhaps this could be solved by the simulators occasionally 'pinging' the asset service with notification of what assets they cache.&lt;br /&gt;
&lt;br /&gt;
Another step to reduce asset database size is to eliminate duplicate assets by hashing.  There is [[Deduplicating Asset Service|an experimental development asset service]] for this.  Third party services such as [[https://github.com/coyled/sras SRAS]] also do this.&lt;br /&gt;
&lt;br /&gt;
==== Possible solutions ====&lt;br /&gt;
&lt;br /&gt;
* If you run a grid for yourself or, if you run a grid where you do not give away your content, then the [http://was.fm/opensim:database:asset_cleaner asset cleaner] from [http://was.fm Wizardry and Steamworks] may be a good solution to track down stray assets and delete them from the database automatically. It is based on dumping OARs and IARs, as per the second option in this section, but after dumping them, it automatically performs the search for you and prompts you to delete several supported assets. Current development is going towards automatically exporting OARs and IARs from PHP so that the procedure is made seamless.&lt;br /&gt;
&lt;br /&gt;
* Save every region to an OAR and every user's inventory to an IAR.  We believe this is equivalent to finding all referenced assets and can be done manually.  However, it's very laborious for installations with a large number of users and requires grid downtime.  Tools could be written to improve this, particularly in systematically saving all user inventories to IARs.&lt;br /&gt;
&lt;br /&gt;
* Do nothing.  MySQL can store a very large amount of data before encountering issues - it's used for extremely large websites and other applications after all.  This assumes you have the disk space.&lt;br /&gt;
&lt;br /&gt;
* Use an external asset service such as [[https://github.com/coyled/sras SRAS]].  SRAS, in particular, is a third party asset service that does deduplication, asset compression, and stores assets on disk rather than in a database.  It also has some nice features like preventing assets being served without deleting them.  It's used by OSGrid, for instance.  However, it does work in a different way from the bundled OpenSimulator asset service (e.g. backup of on-disk assets involves some extra steps compared to just backing up a database).  It also requires a migration step that may take a considerable time if you have an existing asset collection.&lt;br /&gt;
&lt;br /&gt;
=== Other databases ===&lt;br /&gt;
&lt;br /&gt;
The space required by assets far outweighs other data storage requirements so only asset data is generally an issue.&lt;br /&gt;
&lt;br /&gt;
== Services ==&lt;br /&gt;
&lt;br /&gt;
=== The problem ===&lt;br /&gt;
&lt;br /&gt;
The other problem is with handling the number of requests to services when the number of simulators and users grow.  The asset service isn't generally a problem since simulators cache all assets used, though it can form a bottleneck on OAR upload.  The biggest issue is generally caused by users, chiefly due to inventory access and perhaps update last user positions in the GridUser service (and database table).&lt;br /&gt;
&lt;br /&gt;
ROBUST uses an embedded [[http://webserver.codeplex.com/ C# HttpServer]].  Performance comparisons to other Webservers (e.g. Apache) have not been carried out (?) but responses appears to be much, much slower.  As it has been discontinued it's also rather unlikely to have it's performance improved.  In future, OpenSimulator may embed a different HTTP server but this is extremely unlikely in the short term.&lt;br /&gt;
&lt;br /&gt;
=== Possible solutions ===&lt;br /&gt;
&lt;br /&gt;
* Split up services.  By default, ROBUST runs every service in one process.  However, because services are separate from each other, you could run some services (e.g. inventory in one ROBUST instance and other services (e.g. asset) in a different instance, even if they both point to the same database.  Because the embedded C# webserver is slow and possibly not very concurrent, this can achieve significant performance improvements even if all ROBUST instances are running on the same machine.  See [[Configuration#Running multiple ROBUST service instances]] for more information on how to do this.&lt;br /&gt;
&lt;br /&gt;
* Instantiate extra ROBUST copies of problem services (e.g. inventory).  Because services are stateless (akin to a webservice), you can load balance requests between multiple instances using a reverse proxy such as nginx.  Again, because the embedded webserver is probably inefficient, you can achieve performance improvements by running multiple copies of services on the same machine.&lt;br /&gt;
&lt;br /&gt;
* Use an external service based on a more efficient HTTP server, e.g. [https://github.com/coyled/sras SRAS] (asset service only) or [http://code.google.com/p/openmetaverse/ SimianGrid].  Please be aware that SimianGrid uses a different set of simulator &amp;lt;-&amp;gt; service protocols than used by ROBUST.  The necessary SimianGrid adaptors are part of the core OpenSimulator distribution.&lt;br /&gt;
&lt;br /&gt;
* Write your own services to run on an external webserver.  This wouldn't be too hard to do in something like PHP, though one would need to work out the currently undocumented wire formats.  If you do this, please do let us know :)&lt;br /&gt;
&lt;br /&gt;
= Performance studies and blog posts =&lt;br /&gt;
&lt;br /&gt;
These provide some interesting data on the performance limitations of OpenSimulator at various points in time.&lt;br /&gt;
&lt;br /&gt;
* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue.  Physical objects and max avatars are limited by single thread performance in OpenSimulator.&lt;br /&gt;
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.&lt;br /&gt;
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSimulator.  Some of these issues are still valid (e.g. ODE issues).&lt;br /&gt;
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.&lt;br /&gt;
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!--&lt;br /&gt;
&lt;br /&gt;
==Performance hints==&lt;br /&gt;
&lt;br /&gt;
Here are some specific things you might be able to do to improve performance&lt;br /&gt;
&lt;br /&gt;
===Home Based systems===&lt;br /&gt;
&lt;br /&gt;
The most obvious performance difference between a home based cable/dsl system and a &amp;quot;commercial&amp;quot; server is the upload bandwidth. A typical home system allows 100Kb/s upload with 12Mb/s download, a &amp;quot;commercial&amp;quot; system typically has a &amp;quot;symmetrical&amp;quot; bandwidth of say 12Mb/s UP AND DOWN! &amp;quot;Commercial&amp;quot; systems can essentially buy unlimited bandwidth as needed, but it does get expensive to buy bandwidth that you don't need!&lt;br /&gt;
&lt;br /&gt;
In practice this limits the number of &amp;quot;external&amp;quot; users on a &amp;quot;home system&amp;quot; to 4 or 5, but LAN users (NPCs/bots etc.) are essentially unlimited.&lt;br /&gt;
&lt;br /&gt;
A reasonable strategy (i.e. MY strategy) is to use the home system for experimentation and then move the entire sim to a &amp;quot;commercial&amp;quot; VPS service if the sim gets popular (and produces enough $$$ to pay the freight!) &lt;br /&gt;
&lt;br /&gt;
===Running Squid on your region server as a reverse proxy to the asset server===&lt;br /&gt;
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/&amp;lt;br&amp;gt;&lt;br /&gt;
2. Create your [[squid.conf]] configuration file.&amp;lt;br&amp;gt;&lt;br /&gt;
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/&amp;lt;br&amp;gt;&lt;br /&gt;
4. Start everything up!&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.&lt;br /&gt;
&lt;br /&gt;
=== GC_NO_EXPLICIT ===&lt;br /&gt;
&lt;br /&gt;
Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.&lt;br /&gt;
&lt;br /&gt;
$mono-svn-root$/mono&lt;br /&gt;
  mono/metadata/boehm-gc.c&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Index: boehm-gc.c&lt;br /&gt;
===================================================================&lt;br /&gt;
--- boehm-gc.c	(revision 105684)&lt;br /&gt;
+++ boehm-gc.c	(working copy)&lt;br /&gt;
@@ -107,6 +107,10 @@&lt;br /&gt;
 void&lt;br /&gt;
 mono_gc_collect (int generation)&lt;br /&gt;
 {&lt;br /&gt;
+	static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv(&amp;quot;GC_NO_EXPLICIT&amp;quot;)) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {&lt;br /&gt;
+		g_print(&amp;quot;\n --------GC_NO_EXPLICIT \n&amp;quot;);&lt;br /&gt;
+		return;&lt;br /&gt;
+		}&lt;br /&gt;
 	MONO_PROBE_GC_BEGIN (generation);&lt;br /&gt;
 	&lt;br /&gt;
 	GC_gcollect ();&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Not only this, but I recompile the mono runtime:&lt;br /&gt;
&amp;lt;pre&amp;gt;--with-large-heap=yes&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:&lt;br /&gt;
&lt;br /&gt;
 export GC_NO_EXPLICIT=1&lt;br /&gt;
and&lt;br /&gt;
 unset GC_NO_EXPLICIT&lt;br /&gt;
&lt;br /&gt;
What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (&amp;gt;3GB), it is possible might keep mono less apt to do stop world complete collections as often.&lt;br /&gt;
&lt;br /&gt;
--&amp;gt;&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Performance</id>
		<title>Performance</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Performance"/>
				<updated>2015-08-11T09:50:34Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Simulator Performance Topics */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
OpenSimulator performance is a very complex issue.  Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.&lt;br /&gt;
&lt;br /&gt;
We can break down performance considerations into &lt;br /&gt;
&lt;br /&gt;
# Network issues (bandwidth and latency between viewer and simulator, between simulators and between simulator and grid service).&lt;br /&gt;
# Simulator issues (e.g. number of scene objects, number of textures, number of scripts).&lt;br /&gt;
# Grid issues (chiefly scaling services such as asset, inventory, etc to serve more simulators and users).&lt;br /&gt;
&lt;br /&gt;
The biggest issues are probably network and simulator issues.  &lt;br /&gt;
&lt;br /&gt;
To run a simulator you must have good bandwidth (to download textures), good latency (so that movements are seen and actions processed in a timely manner) and good quality (so that random packet drops don't result in missed actions or other problems).&lt;br /&gt;
&lt;br /&gt;
You must also be aware of your hardware's capabilities.  The more scene objects, scripts and avatars you have, the more memory and CPU will be used.&lt;br /&gt;
&lt;br /&gt;
Grid issues are less important until you reach larger grid sizes (e.g. over 60 simultaneous users).&lt;br /&gt;
&lt;br /&gt;
= Monitoring Performance =&lt;br /&gt;
&lt;br /&gt;
Gathering data to analyze performance issues is an evolving area.  We can split this into [[client side monitoring]] (e.g. statistics you can see from the statistics window on a viewer program) and server side performance analysis.  Server side performance analysis will involve [[monitoring|OpenSimulator server monitoring]] and general system tools (e.g. top on Linux to monitor which processes are taking up CPU/memory and more general monitoring tools such as Zabbix).&lt;br /&gt;
&lt;br /&gt;
= General Tips =&lt;br /&gt;
&lt;br /&gt;
* Where at all possible, don't assume something is a performance bottleneck, measure it!  You might think your asset database is large, for example, but even large asset database seldom cause real issues.&lt;br /&gt;
* Make as many objects phantom as possible.  Phantom objects do not need to be tested for collisions with avatars and other objects, reducing physics frame time and increasing performance.&lt;br /&gt;
* Make as few objects subject to physics (e.g. falling under gravity, movable by other avatars) as possible.  Physics objects need a lot more collision testing than ordinary non-phantom objects.&lt;br /&gt;
* It can be hard to perform measurement at the moment since not a lot of tools exist.  However, one such is [[pCampbot]] which is bundled with OpenSimulator.  This can instantiate a number of simultaneous libomv clients on a simulator that can take certain actions such as clicking things and bouncing aroud.  Apects of it (e.g. appearance) are currently rather buggy and generate a lot of logging guff.&lt;br /&gt;
* If your avatars are twitching a lot or flying around uncontrollably, this is often a signal of dropped packets caused by network issues.  For important packets, the simulator will retry the send 3 times but drop the packet after that.  On the simulator console, the command &amp;quot;show queues&amp;quot; will indicate how many packets the simulator has to resend and the total number of sends.  If the total resends is greater than 10% then this is a signal of network issues, at least between a particular viewer and the simulator.  The problem may be at the user's end (e.g. a bad router being used over wifi, a badly performing ISP) which are difficult to do anything about!&lt;br /&gt;
&lt;br /&gt;
= Viewer Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Performance issues can be tackled on the viewer side as well as on the OpenSimulator side.  This typically involves lowering viewer graphical settings (e.g. reducing viewer-side draw distance).  See http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923 for more information.&lt;br /&gt;
&lt;br /&gt;
= Simulator Performance Topics =&lt;br /&gt;
&lt;br /&gt;
== Hardware Requirements ==&lt;br /&gt;
Unfortunately, this is a very difficult question in light of all the factors mentioned in the introduction.  Apart from network, the most important &lt;br /&gt;
&lt;br /&gt;
===CPU===&lt;br /&gt;
We can say that OpenSimulator does not run well when it only has access to a single CPU core - you should regard a dual-core machine as the minimum.&lt;br /&gt;
&lt;br /&gt;
An extremely approximate rule of thumb is to have one core per regularly used region, with the minimum of two above.  So a 4 region simulator would need 4 cores.  However, this assumes continuous use of those regions - one could probably get away with a higher core to region ratio if those other regions were much less used (or not used simultaneously).&lt;br /&gt;
&lt;br /&gt;
On OpenSimulator 0.7.6, we have also observed that an idle region (one which has very few if no active scripts and no avatars on it or in neighbouring regions) requires approximately 2.5% of a CPU core.  The requirement before OpenSimulator 0.7.6 was much higher.&lt;br /&gt;
&lt;br /&gt;
We can also say, again extremely approximately, that each active avatar requires 8% CPU.  An active avatar is one that is moving around and the chief cause of this load is physics processing with the ODE physics engine plugin.  Other physics engine plugins, such as Bulletsim, may require less CPU.&lt;br /&gt;
&lt;br /&gt;
Continually running scripts (such as scripts on timers) will also generate continuous CPU load on a region.  A few scripts of this type probably won't have much of an impact, but a larger number of scripts will start to consume CPU resources.&lt;br /&gt;
&lt;br /&gt;
Finally, physics objects (those which have their physics checkbox marked in the viewer and so are moved around by gravity and collisions) will also generate physics CPU load on the simulator if they are not at rest.&lt;br /&gt;
&lt;br /&gt;
===Memory===&lt;br /&gt;
As a rule of thumb, a region with lots of avatars, 15000 or more prims and 2000 scripts may require 1G of memory.  So a simulator with 4 such regions may require 4G.  One could use less memory if not all regions will be occupied with avatars simultaneously, or where the are fewer scripts, for instance.&lt;br /&gt;
&lt;br /&gt;
===Disk===&lt;br /&gt;
At the simulator level, storage performance is not a big issue unless one has scripts which need extremely high performance in rezzing and derezzing objects.  Even in this case, 7200 rpm 3.5&amp;quot; desktop drives are generally sufficient - problems only start to arise with lower performing drives, such as those found in laptops.&lt;br /&gt;
&lt;br /&gt;
At the grid level, faster storage may be useful when handling large numbers of asset, inventory or other service requests.&lt;br /&gt;
&lt;br /&gt;
===Network===&lt;br /&gt;
Download and upload bandwidth and latency are important.  The biggest use of upload bandwidth (from the server point of view) is to provide texture data to viewers.  So a home network with poor bandwidth (e.g. 384 kbits up) will result in a poor experience for viewers, at least until they have received all texture data.  The requirement for upload bandwidth peaks when a viewer enters a region for the first time or after clearing their asset cache.  The amount of bandwidth required will vary heavily with the number of textures on the region.  An extremely approximate rule of thumb is to have 500 kbit per simultaneously logged in avatar if you know that all avatars will be downlaoding textures simultaneously.&lt;br /&gt;
&lt;br /&gt;
The biggest use of download bandwidth (from the server point of view) is to receive the continuous UDP movement messages from connected avatars.  However, in comparison to texture download, the bandwidth required is trivial - an approximate rule of thumb is 10K (80 kbit) per avatar.&lt;br /&gt;
&lt;br /&gt;
Latency is critical on both upload and download to the simulator, since any delay will affect avatar movement packets (download to server from viewer) and updates to the viewer about other object/avatar position changes (upload from server to viewer).  It's much harder to give advice here, though pings of greater than 350 milliseconds will start to degrade the user's experience on moving their avatar.&lt;br /&gt;
&lt;br /&gt;
===Examples===&lt;br /&gt;
Below are some examples of hardware people use/have used.  Please feel free to add to the list, or to add any reports to the performance studies and blog posts section.  '''These are examples to help you in your selection, not recommendations.'''&lt;br /&gt;
&lt;br /&gt;
Object Parts ~= # prim&lt;br /&gt;
&lt;br /&gt;
Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.&lt;br /&gt;
&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
!Description&lt;br /&gt;
!Operating System (please add Mono version if appropriate)&lt;br /&gt;
!OpenSimulator version&lt;br /&gt;
!RAM/AVG_USE_%&lt;br /&gt;
!CPU&lt;br /&gt;
!#/type of regions&lt;br /&gt;
!# simultaneous avs&lt;br /&gt;
!#scripts/timers/Sensors&lt;br /&gt;
!Location&lt;br /&gt;
!#objectparts&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Intrepid (8.10)&lt;br /&gt;
|Unknown&lt;br /&gt;
|540MB/?&lt;br /&gt;
|1x quad-core 2.5GHz Xeon (L5420)&lt;br /&gt;
|1 region + 9 voids&lt;br /&gt;
|generally 1-2&lt;br /&gt;
|few&lt;br /&gt;
|Knifejaw Atoll &amp;amp; surrounding on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|hosted Xen VPS&lt;br /&gt;
|Ubuntu Jaunty (9.04)&lt;br /&gt;
|Unknown&lt;br /&gt;
|360MB/?&lt;br /&gt;
|2x dual-core 2.0GHz Xeon (5130)&lt;br /&gt;
|1 void&lt;br /&gt;
|generally 1-2 &lt;br /&gt;
|none&lt;br /&gt;
|Knifejaw Road on OSGrid&lt;br /&gt;
|?&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from A+&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1 Meg&lt;br /&gt;
|1x single-core 2.8GHz Celeron&lt;br /&gt;
|2regions per server&lt;br /&gt;
|6 at once with no issues&lt;br /&gt;
|Waterfalls, texture anims, window texture switchers, lots of sound loops&lt;br /&gt;
|Pleasure Planet Welcome center &amp;amp; Region Pleasure Planet in OSGrid&lt;br /&gt;
|20000 prims per region&lt;br /&gt;
|-&lt;br /&gt;
|Amazon EC2 &amp;quot;high-CPU medium instance&amp;quot; (Xen VM)&lt;br /&gt;
|Windows Server 2003&lt;br /&gt;
|Unknown&lt;br /&gt;
|1.7GB&lt;br /&gt;
|1x dual-core 2.3GHz (Intel E5345)&lt;br /&gt;
|1 region with sailing race course&lt;br /&gt;
|7 avs, 4 in boats&lt;br /&gt;
|scripted start line&lt;br /&gt;
|Castle Rock, OSGrid&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|Dedicated Server from simhost.com&lt;br /&gt;
|SuSe 11.2 x64&lt;br /&gt;
|Unknown&lt;br /&gt;
|8gb / 50%&lt;br /&gt;
|4x Core2Quad Q9300 2.6ghz&lt;br /&gt;
|1 region (Wright Plaza) uses approx 4gb ram&lt;br /&gt;
|20-25 users&lt;br /&gt;
|Freebie Stores / Meeting Center / Video Theater&lt;br /&gt;
|@osgrid.org Heavy Use Sim&lt;br /&gt;
|17500 prims aprox 1500 scripts&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Windows XP SP3&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|3GB / 15-40% incl. Opensim and MySQL&lt;br /&gt;
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%&lt;br /&gt;
|11 regions&lt;br /&gt;
|1-6 users&lt;br /&gt;
|Many scripted objects (1934 scripts)&lt;br /&gt;
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]&lt;br /&gt;
|38,065 prims&lt;br /&gt;
|-&lt;br /&gt;
|Home machine&lt;br /&gt;
|Ubuntu Lucid 10.04 (32 bit pae)&lt;br /&gt;
|0.7.0.1 (Diva r13558)&lt;br /&gt;
|160Mb no users, add 5Mb/user incl Opensim and MySQL&lt;br /&gt;
|I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load&lt;br /&gt;
|4 regions (Diva default config)&lt;br /&gt;
|1-4 users (approx 20Kb/sec bandwidth/user)&lt;br /&gt;
|Few scripted objects (&amp;lt;10)&lt;br /&gt;
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]&lt;br /&gt;
|158 prims&lt;br /&gt;
|-&lt;br /&gt;
|Hosted Dedicated OVH&lt;br /&gt;
|Suse 12.2&lt;br /&gt;
|0.7.0.2 (D2)&lt;br /&gt;
|420Mb total, incl OS, Opensim and MySQL&lt;br /&gt;
|i7 Quad 950 (Bloomfield) 3.07GHz, 8 Core, 24Gb RAM, 0-1% Avg Load&lt;br /&gt;
|16 regions (4x4 mega-region)&lt;br /&gt;
|&amp;lt;6 users&lt;br /&gt;
|vehicle scripted objects (&amp;lt;5)&lt;br /&gt;
|[http://metaversesailing.com:9000/wifi Metaverse Sailing]&lt;br /&gt;
|&amp;lt;1000 prims&lt;br /&gt;
|-&lt;br /&gt;
|VPS&lt;br /&gt;
|Debian Lenny 5 (mono 2.4.2.3)&lt;br /&gt;
|OSgrid 0.7.1 (Dev) cd4d7a7: 2010-10-15&lt;br /&gt;
|655MB average out of 1722MB RAM, incl. MySQL&lt;br /&gt;
|Intel Quadcore 2.5 Ghz (1 core assigned to vps) average use: 40-45% &lt;br /&gt;
|20 regions&lt;br /&gt;
|&amp;lt;4 users&lt;br /&gt;
|about 20 different light scripts, but we're also experimenting with heavier HUD scripts (timers, lots of ll(Get/Set)PrimitiveParams and large lists) and custom IRC relay&lt;br /&gt;
|Phoenix Rising Isles on OsGrid&lt;br /&gt;
|3727 prims&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator is configured to use the SQLite database.  This is very convenient for an out-of-the-box experience since it requires no configuration.  However, it's not designed for heavy usage, so if you build very quickly or have more than a few people on your simulator then you will start to see performance issues.&lt;br /&gt;
&lt;br /&gt;
Therefore, we recommend that you switch to MySQL as soon as possible.  This will provide a much better experience but will take a little bit of work to set up.  &lt;br /&gt;
&lt;br /&gt;
Unfortunately, tools for migrating OpenSimulator SQLite data to MySQL are currently limited.  Migration is also possible by saving OARs/IARs of your data from sqlite and loading them up once you've reconfigured to use MySQL.&lt;br /&gt;
&lt;br /&gt;
There is also a database plugin for MSSQL but this is not well maintained between OpenSimulator releases.&lt;br /&gt;
&lt;br /&gt;
In standalone mode, both services and the simulator itself can use SQLite.  In grid mode, SQLite is only supported for simulator data - the ROBUST instances must use a MySQL (or MSSQL) database.&lt;br /&gt;
&lt;br /&gt;
In general a single MySQL instance for the ROBUST services instance will serve small, medium and even large grids perfectly well - it's a configuration that's widely used for even quite large websites.&lt;br /&gt;
&lt;br /&gt;
== Scripts ==&lt;br /&gt;
&lt;br /&gt;
See [[Scripts Performance]].&lt;br /&gt;
&lt;br /&gt;
== Configuration tweaks ==&lt;br /&gt;
&lt;br /&gt;
There are a couple of OpenSimulator configuration tweaks that you can do to significantly improve script loading performance in certain situations.  These tweaks can be made in your OpenSim.ini config file.  These apply to current OpenSimulator development code (0.7.3-dev) and may also apply to 0.7.2, though certainly not any earlier.&lt;br /&gt;
&lt;br /&gt;
===Set DeleteScriptsOnStartup = false===&lt;br /&gt;
&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 DeleteScriptsOnStartup = false&lt;br /&gt;
&lt;br /&gt;
This means that OpenSimulator will not delete all the existing compiled script DLLs on startup (don't worry, this setting doesn't touch the actual LSL scripts in your region).  This will significantly improve startup performance.  However, if you upgrade OpenSimulator in place (e.g. you regularly update your installation directly from development code) then you may occasionally see problems if code changes and your previously compiled DLLs can't find their old references.&lt;br /&gt;
&lt;br /&gt;
In this case, you can either set DeleteScriptsOnStartup = true for one restart in order to clean out and recompile script DLLs or you can manually delete the relevant bin/ScriptEngines/&amp;lt;region-uuid&amp;gt;/*.dll.* files, which will force OpenSimulator to recompile them.  You could also delete the entire bin/ScriptEngines/&amp;lt;region-uuid&amp;gt; directory but this would lose all persisted script state (which is kept in the &amp;lt;script-item-id&amp;gt;.state files).&lt;br /&gt;
&lt;br /&gt;
===Set AppDomainLoading = false===&lt;br /&gt;
 [XEngine]&lt;br /&gt;
 AppDomainLoading = false&lt;br /&gt;
&lt;br /&gt;
By default, OpenSimulator loads every script DLL into its own AppDomain.  If this is set to false, then all scripts are loaded into OpenSimulator's default AppDomain instead.&lt;br /&gt;
&lt;br /&gt;
This will significantly improve script startup times and reduce initial per-script memory overhead.&lt;br /&gt;
&lt;br /&gt;
However, setting this to false will also prevent derezzed script DLLs from being removed from memory (only whole AppDomains can be unloaded).  This might cause an OutOfMemory problem over time, as avatars with scripted attachments move in and out of the region.  Whether this is a problem for you will depend on factors such as the avatar population of your grid.&lt;br /&gt;
&lt;br /&gt;
In addition, Windows users have reported script loading problems with AppDomainLoading = false, though I (justincc) haven't been able to replicate this with current OpenSimulator code on my WindowsXP machine.&lt;br /&gt;
&lt;br /&gt;
===Increase MaxPoolThreads in [Startup]===&lt;br /&gt;
&lt;br /&gt;
At the present time, OpenSimulator uses up to three sets of threads for its operations.  &lt;br /&gt;
&lt;br /&gt;
Firstly, the VM threadpool is always used to process incoming network data.  &lt;br /&gt;
&lt;br /&gt;
Secondly, by default an instance of a third-party threadpool package called SmartThreadPool is used for performing short OpenSimulator tasks.  Performance here is critical since many incoming requests from viewers are handled by threads from this threadpool.&lt;br /&gt;
&lt;br /&gt;
Thirdly, XEngine spawns it's own threadpool for script engine tasks.  However, performance here is not critical.&lt;br /&gt;
&lt;br /&gt;
When using SmartThreadPool, the default MaxPoolThreads parameter in OpenSimulator 0.8 and earlier has turned out to really be too low (at 15 threads) for heavy or possibly even moderate numbers of avatars (e.g. 40).  In current development code, the default has been raised from 15 to 300.  So in release code it's also worth doing if you are seeing issues with viewer lag and your CPU usage is not maxed out already.  To set this to 300, you can make the following change in OpenSim.ini.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
MaxPoolThreads = 300&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Although this will allow more threads to be created (hence using more server resources), this is probably what you want anyway if it all possible, since the alternative is to suffer lag in dealing with viewer's incoming UDP data.  The extra threads will only be created if they are needed.&lt;br /&gt;
&lt;br /&gt;
===Change async_call_method in [Startup]===&lt;br /&gt;
&lt;br /&gt;
Alternatively, you could change the general task threadpool entirely.&lt;br /&gt;
&lt;br /&gt;
It has been set as SmartThreadPool by default somewhat for historical reasons - Mono threadpool performance used to be poor.&lt;br /&gt;
&lt;br /&gt;
However, this may be much better in recent versions of Mono (especially 3.x onwards).  In addition, Windows general threadpool performance may be better than SmartThreadPool.&lt;br /&gt;
&lt;br /&gt;
So on these systems, you may want to try experimenting with a setting of &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = UnsafeQueueUserWorkItems&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
on Windows or even Mono.&lt;br /&gt;
&lt;br /&gt;
On Mac OSX, there is a system called [http://en.wikipedia.org/wiki/Grand_Central_Dispatch Grand Central Dispatch] that effectively implements a threadpool below the VM level.  On these systems, there have been reports that simply setting &lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang='ini'&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
async_call_method = Thread&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
results in better OpenSimulator performance.  However, at least on OSX you may need to increase the number of file handles per process.  Here's a quote on this topic from Gavin Hird.&lt;br /&gt;
&lt;br /&gt;
&amp;quot;I found that on using the async_call_method = thread the system was running out of open files per process as a large number of threads accessed floatsamcache files concurrently. For any *nix you’d have to adjust the “limit -n” parameter.&lt;br /&gt;
&lt;br /&gt;
On OS X the /etc/launchd.conf file needs a line containing “limit maxfiles 2048 65536″ where 2048 in this case is the number of allowed open files per process, and the higher number the open files per system. The file needs to be created if it does not exist.&lt;br /&gt;
Alternatively the file can be created at ~/launchd.conf for the user running OpenSim.exe if you don’t want it as a systemwide setting.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
= Grid Performance Topics =&lt;br /&gt;
&lt;br /&gt;
Scaling a grid is a complex task and only for the very technically inclined.  It is also an area under active investigation.  The advice below will change considerably over time as OpenSimulator and its environment changes and we learn more about perfomrnace issues.&lt;br /&gt;
&lt;br /&gt;
When would you start to meet grid scaling issues?  As an extremely rough and really quite arbitrary and pessimistic rule of thumb, you will probably start to have to think about things when you exceed 50 regions containing a large number of prims or 50 simultaneous users with large inventories.  But this will very a tremendous amount depending on your situation.  If you have thousands of regions with very few prims that much more supportable than 50 regions with 45000 prims each.&lt;br /&gt;
&lt;br /&gt;
You are likely to encounter issues in two areas - database and services.&lt;br /&gt;
&lt;br /&gt;
== Database ==&lt;br /&gt;
&lt;br /&gt;
=== Assets ===&lt;br /&gt;
&lt;br /&gt;
==== The problem ====&lt;br /&gt;
&lt;br /&gt;
Due to the architecture of distributed architecture of OpenSimulator, where regions are running on a number of different machines over a network, it's extremely hard to identify assets that are not in use and hence can be deleted.  Equally, the fact that assets are immutable leads to continual growth in the asset database.&lt;br /&gt;
&lt;br /&gt;
In theory, one could identify unused assets if one could identify all references in simulators and in user inventory.  However, this is extremely hard to do where machines are distributed over a network.  If a grid only has a few simulators all running on machines that are controlled by the same entity running a grid, then it becomes a little more tractable but even then would almost certainly involve significant downtime.  For stand-alone grids, or for environments where assets are not passed between grids (ie: giving a texture to a friend on another grid) [http://was.fm Wizardry and Steamworks] provides an experimental script that will do exactly that. It is currently available at the [http://was.fm/opensim:database:asset_cleaner asset cleaner] project page and published under an MIT license.&lt;br /&gt;
&lt;br /&gt;
Asset deletion would be easier for a one simulator grid or a standalone.  However, even code to implement asset deletion on standalones has not yet been implemented and would certainly require significant simulator downtime.&lt;br /&gt;
&lt;br /&gt;
A promising area of research involves improving OpenSimulator's recording of asset access times (e.g. recording access periodically).  Then assets which aren't accessed for a long time (e.g. a year) could be deleted or moved to cold storage (e.g. DVD).  One is left with the problem of not deleting assets permanently cached by simulators but perhaps this could be solved by the simulators occasionally 'pinging' the asset service with notification of what assets they cache.&lt;br /&gt;
&lt;br /&gt;
Another step to reduce asset database size is to eliminate duplicate assets by hashing.  There is [[Deduplicating Asset Service|an experimental development asset service]] for this.  Third party services such as [[https://github.com/coyled/sras SRAS]] also do this.&lt;br /&gt;
&lt;br /&gt;
==== Possible solutions ====&lt;br /&gt;
&lt;br /&gt;
* If you run a grid for yourself or, if you run a grid where you do not give away your content, then the [http://was.fm/opensim:database:asset_cleaner asset cleaner] from [http://was.fm Wizardry and Steamworks] may be a good solution to track down stray assets and delete them from the database automatically. It is based on dumping OARs and IARs, as per the second option in this section, but after dumping them, it automatically performs the search for you and prompts you to delete several supported assets. Current development is going towards automatically exporting OARs and IARs from PHP so that the procedure is made seamless.&lt;br /&gt;
&lt;br /&gt;
* Save every region to an OAR and every user's inventory to an IAR.  We believe this is equivalent to finding all referenced assets and can be done manually.  However, it's very laborious for installations with a large number of users and requires grid downtime.  Tools could be written to improve this, particularly in systematically saving all user inventories to IARs.&lt;br /&gt;
&lt;br /&gt;
* Do nothing.  MySQL can store a very large amount of data before encountering issues - it's used for extremely large websites and other applications after all.  This assumes you have the disk space.&lt;br /&gt;
&lt;br /&gt;
* Use an external asset service such as [[https://github.com/coyled/sras SRAS]].  SRAS, in particular, is a third party asset service that does deduplication, asset compression, and stores assets on disk rather than in a database.  It also has some nice features like preventing assets being served without deleting them.  It's used by OSGrid, for instance.  However, it does work in a different way from the bundled OpenSimulator asset service (e.g. backup of on-disk assets involves some extra steps compared to just backing up a database).  It also requires a migration step that may take a considerable time if you have an existing asset collection.&lt;br /&gt;
&lt;br /&gt;
=== Other databases ===&lt;br /&gt;
&lt;br /&gt;
The space required by assets far outweighs other data storage requirements so only asset data is generally an issue.&lt;br /&gt;
&lt;br /&gt;
== Services ==&lt;br /&gt;
&lt;br /&gt;
=== The problem ===&lt;br /&gt;
&lt;br /&gt;
The other problem is with handling the number of requests to services when the number of simulators and users grow.  The asset service isn't generally a problem since simulators cache all assets used, though it can form a bottleneck on OAR upload.  The biggest issue is generally caused by users, chiefly due to inventory access and perhaps update last user positions in the GridUser service (and database table).&lt;br /&gt;
&lt;br /&gt;
ROBUST uses an embedded [[http://webserver.codeplex.com/ C# HttpServer]].  Performance comparisons to other Webservers (e.g. Apache) have not been carried out (?) but responses appears to be much, much slower.  As it has been discontinued it's also rather unlikely to have it's performance improved.  In future, OpenSimulator may embed a different HTTP server but this is extremely unlikely in the short term.&lt;br /&gt;
&lt;br /&gt;
=== Possible solutions ===&lt;br /&gt;
&lt;br /&gt;
* Split up services.  By default, ROBUST runs every service in one process.  However, because services are separate from each other, you could run some services (e.g. inventory in one ROBUST instance and other services (e.g. asset) in a different instance, even if they both point to the same database.  Because the embedded C# webserver is slow and possibly not very concurrent, this can achieve significant performance improvements even if all ROBUST instances are running on the same machine.  See [[Configuration#Running multiple ROBUST service instances]] for more information on how to do this.&lt;br /&gt;
&lt;br /&gt;
* Instantiate extra ROBUST copies of problem services (e.g. inventory).  Because services are stateless (akin to a webservice), you can load balance requests between multiple instances using a reverse proxy such as nginx.  Again, because the embedded webserver is probably inefficient, you can achieve performance improvements by running multiple copies of services on the same machine.&lt;br /&gt;
&lt;br /&gt;
* Use an external service based on a more efficient HTTP server, e.g. [https://github.com/coyled/sras SRAS] (asset service only) or [http://code.google.com/p/openmetaverse/ SimianGrid].  Please be aware that SimianGrid uses a different set of simulator &amp;lt;-&amp;gt; service protocols than used by ROBUST.  The necessary SimianGrid adaptors are part of the core OpenSimulator distribution.&lt;br /&gt;
&lt;br /&gt;
* Write your own services to run on an external webserver.  This wouldn't be too hard to do in something like PHP, though one would need to work out the currently undocumented wire formats.  If you do this, please do let us know :)&lt;br /&gt;
&lt;br /&gt;
= Performance studies and blog posts =&lt;br /&gt;
&lt;br /&gt;
These provide some interesting data on the performance limitations of OpenSimulator at various points in time.&lt;br /&gt;
&lt;br /&gt;
* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue.  Physical objects and max avatars are limited by single thread performance in OpenSimulator.&lt;br /&gt;
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.&lt;br /&gt;
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSimulator.  Some of these issues are still valid (e.g. ODE issues).&lt;br /&gt;
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.&lt;br /&gt;
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]&lt;br /&gt;
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!--&lt;br /&gt;
&lt;br /&gt;
==Performance hints==&lt;br /&gt;
&lt;br /&gt;
Here are some specific things you might be able to do to improve performance&lt;br /&gt;
&lt;br /&gt;
===Home Based systems===&lt;br /&gt;
&lt;br /&gt;
The most obvious performance difference between a home based cable/dsl system and a &amp;quot;commercial&amp;quot; server is the upload bandwidth. A typical home system allows 100Kb/s upload with 12Mb/s download, a &amp;quot;commercial&amp;quot; system typically has a &amp;quot;symmetrical&amp;quot; bandwidth of say 12Mb/s UP AND DOWN! &amp;quot;Commercial&amp;quot; systems can essentially buy unlimited bandwidth as needed, but it does get expensive to buy bandwidth that you don't need!&lt;br /&gt;
&lt;br /&gt;
In practice this limits the number of &amp;quot;external&amp;quot; users on a &amp;quot;home system&amp;quot; to 4 or 5, but LAN users (NPCs/bots etc.) are essentially unlimited.&lt;br /&gt;
&lt;br /&gt;
A reasonable strategy (i.e. MY strategy) is to use the home system for experimentation and then move the entire sim to a &amp;quot;commercial&amp;quot; VPS service if the sim gets popular (and produces enough $$$ to pay the freight!) &lt;br /&gt;
&lt;br /&gt;
===Running Squid on your region server as a reverse proxy to the asset server===&lt;br /&gt;
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/&amp;lt;br&amp;gt;&lt;br /&gt;
2. Create your [[squid.conf]] configuration file.&amp;lt;br&amp;gt;&lt;br /&gt;
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/&amp;lt;br&amp;gt;&lt;br /&gt;
4. Start everything up!&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.&lt;br /&gt;
&lt;br /&gt;
=== GC_NO_EXPLICIT ===&lt;br /&gt;
&lt;br /&gt;
Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.&lt;br /&gt;
&lt;br /&gt;
$mono-svn-root$/mono&lt;br /&gt;
  mono/metadata/boehm-gc.c&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Index: boehm-gc.c&lt;br /&gt;
===================================================================&lt;br /&gt;
--- boehm-gc.c	(revision 105684)&lt;br /&gt;
+++ boehm-gc.c	(working copy)&lt;br /&gt;
@@ -107,6 +107,10 @@&lt;br /&gt;
 void&lt;br /&gt;
 mono_gc_collect (int generation)&lt;br /&gt;
 {&lt;br /&gt;
+	static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv(&amp;quot;GC_NO_EXPLICIT&amp;quot;)) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {&lt;br /&gt;
+		g_print(&amp;quot;\n --------GC_NO_EXPLICIT \n&amp;quot;);&lt;br /&gt;
+		return;&lt;br /&gt;
+		}&lt;br /&gt;
 	MONO_PROBE_GC_BEGIN (generation);&lt;br /&gt;
 	&lt;br /&gt;
 	GC_gcollect ();&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Not only this, but I recompile the mono runtime:&lt;br /&gt;
&amp;lt;pre&amp;gt;--with-large-heap=yes&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:&lt;br /&gt;
&lt;br /&gt;
 export GC_NO_EXPLICIT=1&lt;br /&gt;
and&lt;br /&gt;
 unset GC_NO_EXPLICIT&lt;br /&gt;
&lt;br /&gt;
What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (&amp;gt;3GB), it is possible might keep mono less apt to do stop world complete collections as often.&lt;br /&gt;
&lt;br /&gt;
--&amp;gt;&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Scripts_Performance</id>
		<title>Scripts Performance</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Scripts_Performance"/>
				<updated>2015-08-11T09:48:19Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Created page with &amp;quot;== Measuring Scripts Performance ==  === For Users ===  Users can check their scripts' performance in two places in the viewer: # The '''Statistics''' panel - the &amp;quot;Script Time...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Measuring Scripts Performance ==&lt;br /&gt;
&lt;br /&gt;
=== For Users ===&lt;br /&gt;
&lt;br /&gt;
Users can check their scripts' performance in two places in the viewer:&lt;br /&gt;
# The '''Statistics''' panel - the &amp;quot;Script Time&amp;quot; field shows the total execution time for all the scripts in the region in the last frame&lt;br /&gt;
# The '''Top Scripts''' window - shows the total execution time in the last 30 seconds of the slowest scripts in the region&lt;br /&gt;
&lt;br /&gt;
=== For Developers ===&lt;br /&gt;
&lt;br /&gt;
Both of these statistics are calculated by measuring the execution time of each Script Instance.&lt;br /&gt;
* '''ScriptInstance.executionTimer''' is a Stopwatch that's used whenever the script is being processed in the scripting engine.&lt;br /&gt;
* This timer is automatically stopped when the script is sleeping, and restarted afterwards. See '''OSSL_Api.ScriptSleep()''' and '''LSL_Api.Sleep()'''. That's done because scripts don't use any CPU power while they're sleeping.&lt;br /&gt;
* Each Scene adds up all of its scripts' execution times each frame. See '''Scene.m_scriptExecutionTime'''. This is what's shown in the &amp;quot;Statistics&amp;quot; panel.&lt;br /&gt;
* Each ScriptInstance uses a sliding window to keep track of its execution time in the last 30 seconds. See '''ScriptInstance.ExecutionTime''', which is an instance of the '''MetricsCollectorTime''' class. This is what's shown in the &amp;quot;Top Scripts&amp;quot; window.&lt;br /&gt;
&lt;br /&gt;
=== Notes ===&lt;br /&gt;
&lt;br /&gt;
We use the Stopwatch class to calculate the script execution times. This is a high-resolution timer, which is important because many script executions take less than 1ms, so a lower-resolution timer would think that the script didn't take any time at all.&lt;br /&gt;
&lt;br /&gt;
The script time is &amp;quot;gross time&amp;quot;, i.e. including the time the scripting engine used before and after the actual script execution. That's because this time should be attributed to the script's execution time, as it takes CPU power. For example, a script that fires thousands of events per second causes the scripting engine to do a lot of setup and teardown work that isn't part of the script's actual work, but it does slow down the simulator.&lt;br /&gt;
&lt;br /&gt;
When a script is Stopped, we don't reset its ExecutionTime. This is done to allow the user to see runaway scripts, i.e. scripts that have executed for so long that they were forcibly aborted. When a script is forcibly aborted, it's Stopped. If we had reset the ExecutionTime when scripts are stopped then paradoxically, runaway script wouldn't have shown up in the &amp;quot;Top Scripts&amp;quot; dialog, even though they're the top CPU hogs among all the scripts.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;Top Scripts&amp;quot; window shows the script's execution time in the last 30 seconds. This value needs to be short, so that when users modify a script to make it faster they can get quick feedback.&lt;br /&gt;
&lt;br /&gt;
=== Possible Future Improvements ===&lt;br /&gt;
&lt;br /&gt;
Currently, when scripts are sleeping this is done by making the script thread sleep. Although this doesn't use the CPU, it does lock up one of the limited number of script threads. A better implementation would be to release the thread during sleeps. However, since we already use quite a lot of threads, this doesn't seem like a high priority.&lt;br /&gt;
&lt;br /&gt;
It would be nice if we could measure a script's memory usage: both total memory used, and memory thrashing which leads to garbage-collection time. E.g., a script that does a lot of work with lists is probably constantly creating and discarding lists, which is inefficient.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Developer_Documentation</id>
		<title>Developer Documentation</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Developer_Documentation"/>
				<updated>2015-08-11T09:16:20Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Scripting */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
== Source Code Repository Access ==&lt;br /&gt;
&lt;br /&gt;
OpenSimulator uses git as its source code repository. Checkout &lt;br /&gt;
&lt;br /&gt;
 git clone git://opensimulator.org/git/opensim&lt;br /&gt;
&lt;br /&gt;
See [[Source Code Repository]] for more details. &lt;br /&gt;
&lt;br /&gt;
See [[Using Git]]&amp;amp;nbsp;for more Details on installing and using GIT&amp;amp;nbsp;with OpenSimulator.org&lt;br /&gt;
&lt;br /&gt;
You can also browse the source code for OpenSimulator [http://opensimulator.org/viewgit/?a=shortlog&amp;amp;p=opensim using a web browser].&lt;br /&gt;
&lt;br /&gt;
We have [http://www.ohloh.net/projects/4753?p=OpenSimulator Ohloh page], which takes various statistics of the OpenSimulator code base.&lt;br /&gt;
&lt;br /&gt;
This is also an [[opensim-libs git repository]] which contains the source code to some of the 3rd party libraries built and included in OpenSimulator.&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
=== Submitting Patches ===&lt;br /&gt;
Please review [[Submitting code to OpenSim]]&lt;br /&gt;
&lt;br /&gt;
=== Feature Proposals ===&lt;br /&gt;
Larger changes may require feature proposals depending on whether they introduce or significantly change existing functionality.  Please use your judgement to determine whether this is required.&lt;br /&gt;
&lt;br /&gt;
For more details please see the [[Feature Proposals]] page.&lt;br /&gt;
&lt;br /&gt;
== Developer Documentation ==&lt;br /&gt;
Please be aware that some of this documentation may be out of date. If this appears to be the case then please ask for more information on the mailing lists or IRC channels (details are on the [[Main Page]]). If you can't find what you want here you might want to try looking in the [[User Documentation]].&lt;br /&gt;
&lt;br /&gt;
==== General ====&lt;br /&gt;
* [[Development Team]] — OpenSimulator is brought to you by...&lt;br /&gt;
* [[Organization]] - Guidelines and standards about core developers and how one becomes a member.&lt;br /&gt;
* [[Release Cycle]] — How to create an OpenSimulator release.&lt;br /&gt;
* [[Automated Release Building]]&lt;br /&gt;
* [[On revisions, tags and branches]]&lt;br /&gt;
* [[Hacking OpenSim for fun and profit]] — A starters guide for programming OpenSimulator.&lt;br /&gt;
* [[Coding standards]] — Coding conventions for developers.&lt;br /&gt;
* [[Codebase overview]] - Very broad overview of the codebase.&lt;br /&gt;
* [[Branches]] — An overview of the repository branches and what they are for.&lt;br /&gt;
* [[Monodevelop]] — How to use the [[monodevelop]] IDE for editing C# solutions.&lt;br /&gt;
* [[Debugging]] - Information about debugging OpenSimulator.&lt;br /&gt;
* [[Performance]] — Information about performance in OpenSimulator, including studies on where the bottlenecks are.&lt;br /&gt;
* [[Glossary]] - A glossary of terms used in OpenSimulator.&lt;br /&gt;
&lt;br /&gt;
==== Development ====&lt;br /&gt;
* [http://opensimulator.org/mantis Mantis Bug Tracking] — Mantis is the issue tracking tool of OpenSimulator.&lt;br /&gt;
* [http://jenkins.opensimulator.org/ Continuous Integration] — OpenSimulator's Jenkins installation builds the source base after each commit and runs the regression tests.&lt;br /&gt;
* [http://forge.opensimulator.org/gf/ OpenSimulator GForge] — Project hosting for OpenSimulator related projects.&lt;br /&gt;
&lt;br /&gt;
==== Testing ====&lt;br /&gt;
* [[Testing]] - General testing information.&lt;br /&gt;
* [[Automated Testing]] - Writing Automated tests for OpenSimulator.&lt;br /&gt;
* [[Prim Linking Testing]] - Test cases for in world link/unlinking of prims.&lt;br /&gt;
* [[pCampBot]] - A facility for stress-testing a simulator.&lt;br /&gt;
&lt;br /&gt;
==== Architecture ====&lt;br /&gt;
* [[OpenSim:Introduction_and_Definitions | OpenSim: Introduction and Definitions]] — A work in progress describing the high level components of OpenSimulator&lt;br /&gt;
* [[:Category:Tech Reference|Technical Reference]] — A technical description of the simulator operation.&lt;br /&gt;
* [[Grid Architecture Diagram]]&lt;br /&gt;
* [[Plugins]] — The types of plugins used in OpenSimulator.&lt;br /&gt;
* [[IRegionModule|Region module basics]] - The basics of how to create a region module, and where example code can be found in the OpenSimulator source tree.&lt;br /&gt;
* [[Hypergrid Implementation]] - details on the internal implementation of the Hypergrid system in OpenSimulator.  For more general details also see the [[Hypergrid]] page.&lt;br /&gt;
&lt;br /&gt;
==== Services ====&lt;br /&gt;
* [[Connectors]] — A description of OpenSimulator's connector architecture, used for linking region code with services (asset, inventory, etc.) in both local (standalone) and distributed (grid) configurations.&lt;br /&gt;
* [[Services]] - A description of the grid and simulator services used by OpenSimulator.&lt;br /&gt;
&lt;br /&gt;
==== Communication ====&lt;br /&gt;
* [[LLUDP ClientStack]] - Information on the LLUDP client stack used by OpenSimulator to send and receive UDP packets from viewers implementing the Linden Labs virtual environment protocol.&lt;br /&gt;
* [[Communication Protocols]] - Introduction to the various communication protocols used by OpenSimulator.  This includes viewer to OpenSimulator TCP and UDP protocols (e.g. login, agent update message exchange, asset fetch, etc.), inter-region protocols and grid service protocols.  It also details methods by which arbitary UDP and TCP messages can be sent back and forth between clients/modified viewers and OpenSimulator region modules.&lt;br /&gt;
* [[Agent Domain / Service]] - Details about the GridForge hosted Agent Domain/Service code (legacy doc since this LL inspired work has long been abandoned).&lt;br /&gt;
&lt;br /&gt;
==== Database ====&lt;br /&gt;
* [[Database Documentation]] — Information on the database schemas used in OpenSimulator&lt;br /&gt;
* [[MonoSqlite]] — How the database model currently works.&lt;br /&gt;
* [[LSL:PrimitiveParams]] — Notes on converting SL Edit GUI values and LSL PrimitiveParams to OpenSimulator PrimitiveBaseShape fields&lt;br /&gt;
&lt;br /&gt;
==== Formats ====&lt;br /&gt;
* [[OpenSim Archives]] - Opensim Region Archive (OAR) file format.&lt;br /&gt;
* [[Inventory Archives]] - OpenSimulator Inventory Archive (IAR) file format&lt;br /&gt;
* [[Asset Formats]] - OpenSimulator asset formats. This includes serialized object formats and appearance formats.&lt;br /&gt;
&lt;br /&gt;
==== Integration ====&lt;br /&gt;
* [[AuthIntegration]] - How to integrate external authentication systems (such as web frontends) with OpenSimulator's authentication system.&lt;br /&gt;
* [[ClothingManipulation]] - How to set clothing on avatars using external ROBUST service calls.&lt;br /&gt;
* [[UserManipulation]] - How to create users in OpenSimulator via external calls through ROBUST (only available when running in grid configuration).&lt;br /&gt;
* [[RemoteAdmin]] - How to use the remote admin plug-in.  Some functions (e.g. user creation) are only available when running in standalone configuration.&lt;br /&gt;
* [[RegionIntegration]] - Integrating a region and the things within it (scene objects, etc.) with external sources of data and webpages.&lt;br /&gt;
* [[RestConsole]] - Description how to use the REST remote console &lt;br /&gt;
* [[REST]] - Information about the REST interface to assets, inventory, etc.&lt;br /&gt;
* [[Webinterface]] - Integrating the external face of OpenSimulator with the web.&lt;br /&gt;
* [[Services]] - Contains general information on the default OpenSimulator services (asset, inventory, etc.) and more detailed information of HTTP interfaces for some services.&lt;br /&gt;
* [[Known Web Interfaces within OpenSim]] - The set of CAPS, XMLRPC, or REST entry points in the project.&lt;br /&gt;
&lt;br /&gt;
==== Inventory ====&lt;br /&gt;
* [[User Inventory Architecture]] - A general page that aims to detail the user inventory mechanisms in OpenSimulator.&lt;br /&gt;
&lt;br /&gt;
==== Map ====&lt;br /&gt;
* [[Map]] - Mapping overview&lt;br /&gt;
* [[Warp3DImageModule]] — This is an improved map image module.&lt;br /&gt;
&lt;br /&gt;
==== Permissions ====&lt;br /&gt;
* [[Permissions (Server)]] — Permissions system as implemented on the region server.&lt;br /&gt;
* [[OpenSim: Permissions]] — Notes on how object permissions are handled on the client.&lt;br /&gt;
&lt;br /&gt;
==== Physics ====&lt;br /&gt;
* [[PhysicsEngines]] — Options for physics engines in OpenSimulator.&lt;br /&gt;
* [[Physics Engine Interface]] — what methods and such exist in a Physics module&lt;br /&gt;
&lt;br /&gt;
==== Regions/Scenes ====&lt;br /&gt;
* [[Overview of How Regions Work]]&lt;br /&gt;
* [[OpenSim: Permissions]] — Notes on object permissions &amp;amp; definition of the ObjectFlags variable.&lt;br /&gt;
* [[OpenSim Load Balancing and Region Splitting]] - Instructions for using load balancing and region splitting features.&lt;br /&gt;
&lt;br /&gt;
==== Scripting ====&lt;br /&gt;
* [[Scripting Documentation]] — How to use scripts and what limitations apply.&lt;br /&gt;
* [[LSL Status]] — A list of LSL-functions that are available in OpenSimulator.&lt;br /&gt;
* [[OSSL]] — Some information about the OpenSimulator Scripting Language, and how to implement an OSSL function&lt;br /&gt;
* [[OSSL Script Library/ModSendCommand]] - A mechanism for in-world scripts to use a generic modSendCommand() and the link_message event to communicate with region modules.&lt;br /&gt;
* [[OSSL_Script_Library/ModInvoke]] - A mechanism for region modules to make new functions available to in-world scripts without patching the OpenSimulator runtime.&lt;br /&gt;
* [[ScriptEngines]] — Information about script engines (chiefly XEngine).&lt;br /&gt;
* [[Scripts Performance]] - Factors that affect script performance, and how to measure them&lt;br /&gt;
&lt;br /&gt;
==== Search ====&lt;br /&gt;
* [[OpenSim.Region.DataSnapshot]] - Shiny new data gathering/search system&lt;br /&gt;
* [[ImageService]] - Shiny new region module for serving search-related images&lt;br /&gt;
&lt;br /&gt;
==== Sound ====&lt;br /&gt;
* [[Sound Protocol]] - Technical information about the sound protocols (e.g. UDP messages between viewer and server).&lt;br /&gt;
&lt;br /&gt;
==== Statistics ====&lt;br /&gt;
* [[Stats Manager]] - Information about the main statistics monitor used in OpenSimulator and how to add/remove extra stats from modules.&lt;br /&gt;
* [[Web Statistics Module]] - The web statistics module documentation and counter wish list.&lt;br /&gt;
&lt;br /&gt;
==== Threading ====&lt;br /&gt;
* [[Threading]] — Information on the way that threads are used in OpenSimulator.&lt;br /&gt;
&lt;br /&gt;
==== Users ====&lt;br /&gt;
* [[Appearance Troubleshooting]] - Also contains useful information about avatar behave and the relevant message exchanges between the viewer and the simulator.&lt;br /&gt;
* [[Attachment Protocols]] - Information on the attachment protocols used by viewers and OpenSimulator.&lt;br /&gt;
* [[Name Binding]] - Some information on how OpenSimulator (and Second Life) binds user UUIDs to names (e.g. 25bf6e60-91c0-4d28-8349-ba254cd4388e -&amp;gt; Jane Doe).&lt;br /&gt;
* [[Userlevel]] — Explanation of permissions granted via &amp;quot;God Mode&amp;quot;/Admin Status.&lt;br /&gt;
&lt;br /&gt;
== Discussing Documentation ==&lt;br /&gt;
A good first point of contact is the [[IRC|#opensim-dev IRC]] channel. The OpenSimulator developers also hold [[office hours]] once a week in-world on Tuesdays at &amp;quot;Wright Plaza&amp;quot; on http://osgrid.org. There is a &amp;quot;Test Hour&amp;quot; on Saturdays, also generally on &amp;quot;Wright Plaza&amp;quot;. Both these weekly events are held at 1900UTC in summer time and 2000UTC in winter.&lt;br /&gt;
&lt;br /&gt;
There is also a [[Mailing Lists|development mailing list]] when development discussion takes place.&lt;br /&gt;
&lt;br /&gt;
== Recent Git Commits ==&lt;br /&gt;
&amp;lt;rss&amp;gt;http://opensimulator.org/viewgit?a=rss-log&amp;amp;p=opensim|max=5|title=none&amp;lt;/rss&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Submitting_code_to_OpenSim</id>
		<title>Submitting code to OpenSim</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Submitting_code_to_OpenSim"/>
				<updated>2015-07-26T06:36:15Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
{{Quicklinks}}&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Overview ==&lt;br /&gt;
&lt;br /&gt;
'''Before you begin, please review our [[Contributions Policy]]'''.&lt;br /&gt;
&lt;br /&gt;
Not all patches will make it into OpenSimulator.  To keep a lid on code complexity, OpenSimulator is not trying to be a 'batteries included' project.  Things that can't be considered core functionality are better implements as an external region module.  If extra hooks/events are needed to make these work then patches for those are very welcome.&lt;br /&gt;
&lt;br /&gt;
Please review the [[Coding standards]] and stick to them in your patch. The only exception should be if the surrounding code does not conform to these guidelines, in which cases its okay to be consistent with the code already in the file.  If a patch does not follow the guidelines we will ask for it to be changed.&lt;br /&gt;
&lt;br /&gt;
Please put only one logical change in a patch at a time. Patches that contain more than one logical change tend to be larger, more complex and hence take more time to be applied. At worse, developers will tend not to look at them because it's hard to disentangle all the possible effects.&lt;br /&gt;
&lt;br /&gt;
== Test ==&lt;br /&gt;
&lt;br /&gt;
Please run the automated tests (via &amp;quot;nant test&amp;quot; on the command line) before submitting your patch. Patches that add new tests (either to test accompanying patch code or to test existing code) are very welcome.&lt;br /&gt;
&lt;br /&gt;
== Create a Patch File ==&lt;br /&gt;
&lt;br /&gt;
Code is submitted to OpenSimulator via patches attached to entries in our [http://opensimulator.org/mantis/my_view_page.php Mantis bug tracker]. One way to generate these is by using the Git command line.&lt;br /&gt;
&lt;br /&gt;
 git format-patch &amp;lt;commit hash&amp;gt;^!&lt;br /&gt;
&lt;br /&gt;
This will package up all your git commit changes into a nice easily applicable file.&lt;br /&gt;
&lt;br /&gt;
Alternatively, if you have a specific commit, or range of commits, that you want to include in the patch, then run this command:&lt;br /&gt;
&lt;br /&gt;
 git format-patch -&amp;lt;num&amp;gt; &amp;lt;newest commit hash&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, if your commit hash is a30f224, and you want the patch to include only this one commit, then you would use this command:&lt;br /&gt;
&lt;br /&gt;
 git format-patch -1 a30f224&lt;br /&gt;
&lt;br /&gt;
If your patch includes several sequential commits then &amp;lt;num&amp;gt; would be the number of commits, and the commit hash would be the newest commit.&lt;br /&gt;
&lt;br /&gt;
== Submit the Patch ==&lt;br /&gt;
&lt;br /&gt;
Submit the patch by attaching it to an entry in Mantis.&lt;br /&gt;
* If you're creating a new entry then the title line should start with [PATCH].&lt;br /&gt;
* Once you've submitted your patch please move the Mantis entry into the '''Patch Included''' state to let us know there's a patch waiting to be reviewed.  It might take a bit longer to see a mantis entry with a patch if it's not in this state (and in unfortunate rare cases it may be missed altogether for a period).&lt;br /&gt;
&lt;br /&gt;
Once you've put it on a Mantis, you may want to hop on the IRC channels and mention it someone there (though at the moment we're pretty good at getting round to these, since e-mails about newly opened mantis entries are sent to developers automatically).&lt;br /&gt;
&lt;br /&gt;
General turnaround time for patch review is a week. though, it could be up to two weeks depending on the situation.  If you want to chat about a patch (or remind people that it exists after a week has gone by), please feel free to pop into #opensim-dev on IRC or send an e-mail to the opensim-dev ailing list.&lt;br /&gt;
&lt;br /&gt;
When a patch is reviewed, it will either be applied (in which case, thanks very much!) or the Mantis entry will be changed to the &amp;quot;Patch feedback&amp;quot; state with comments from developers/interested parties.  If you revise the patch in light of the discussion, please then change the state back to &amp;quot;Patch Included&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Helping Out ==&lt;br /&gt;
&lt;br /&gt;
If you're looking for an initial piece of code to do, the bugs in Mantis are a very good starting point. You may want to see if there's anybody on IRC to discuss the difficulty of a particular bug (they do vary, sometimes in unexpected ways).&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/LLUDP_ClientStack</id>
		<title>LLUDP ClientStack</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/LLUDP_ClientStack"/>
				<updated>2014-07-22T05:55:48Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Useful console commands */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction=&lt;br /&gt;
&lt;br /&gt;
These are draft notes on OpenSimulator's implementation of the LLUDP ClientStack, a chunk of code which is used to send and receive packets from viewers (clients) implementing the Linden Labs virtual environment protocol.&lt;br /&gt;
&lt;br /&gt;
As such, this stack handles &lt;br /&gt;
&lt;br /&gt;
* Setup of an inbound UDP handling stack for each region.&lt;br /&gt;
* Handling of inbound UDP messages from a connected viewer.&lt;br /&gt;
* Distribution of recieved UDP messages to appropriate handling code (e.g. selection handling code if a prim is selected).&lt;br /&gt;
* Sending of outbound UDP messages to a connected viewer.&lt;br /&gt;
* Throttling of outbound messages.&lt;br /&gt;
* Sending and receive of ack messages, both inline within other messages and as standalone messages.&lt;br /&gt;
* Resending of messages that are marked as reliable but for which receipt has not been acknowledged by the viewer.&lt;br /&gt;
* Throttling of outgoing UDP messages.&lt;br /&gt;
* Pooling of clientstack structures (e.g. classes representing messages) in order to improve efficiency and reduce memory usage.&lt;br /&gt;
&lt;br /&gt;
=Useful console commands=&lt;br /&gt;
&lt;br /&gt;
These are console commands which are useful in debugging or investigating the LLUDP protocol.&lt;br /&gt;
&lt;br /&gt;
* debug lludp packet [--default | --all] &amp;lt;level&amp;gt; [&amp;lt;avatar-first-name&amp;gt; &amp;lt;avatar-last-name&amp;gt;] - Turn on packet debugging.  In OpenSimulator 0.7.5 and previous this command was &amp;quot;debug packet&amp;quot;. &amp;quot;--default&amp;quot; applies the new logging level to all avatar that login after that point. &amp;quot;--all&amp;quot; applies it to all existing avatars as well.&lt;br /&gt;
* debug lludp pool &amp;lt;on|off&amp;gt; - Turn object pooling within the lludp component on or off.&lt;br /&gt;
* debug lludp start &amp;lt;in|out|all&amp;gt; - Control LLUDP packet processing.&lt;br /&gt;
* debug lludp status - Return status of LLUDP packet processing.&lt;br /&gt;
* debug lludp stop &amp;lt;in|out|all&amp;gt; - Stop LLUDP packet processing.&lt;br /&gt;
&lt;br /&gt;
=Mechanisms=&lt;br /&gt;
&lt;br /&gt;
TODO: Need to fill out more as required.&lt;br /&gt;
&lt;br /&gt;
==Inbound UDP==&lt;br /&gt;
===Part 1===&lt;br /&gt;
* Inbound UDP messages are received on a region's listening UDP port (currently in OpenSimUDPBase).  These are IOCP threads from the runtime as processing is done asynchronously.&lt;br /&gt;
* On receive, the thread kicks off another asychrnous receive (which may be handled by a different IOCP thread).&lt;br /&gt;
* Each received packet is sanity checked for length and basic malformations.&lt;br /&gt;
* Data is inserted into a packet structure drawn from a pool.&lt;br /&gt;
* If packet &lt;br /&gt;
** Is UseCircuitCode (used to set up circuits with viewers) then this is handled on a separate thread.&lt;br /&gt;
** Is CompleteAgentMovement (used to complete the insertion of an avatar into a region) then this is handled on a separate thread.&lt;br /&gt;
** Has appended acks to a normal packet or is PacketAck then these are processed.&lt;br /&gt;
** Is reliable then a pending ack is queued for acknowledgement to the client.&lt;br /&gt;
** Is AgentUpdate and is not significant (same as last packet, where these are received about 10 times a second) then it is discarded.&lt;br /&gt;
** StartPingCheck then this is handled.&lt;br /&gt;
* All other packets are placed into a queue (packetInbox) for further processing.&lt;br /&gt;
* The thread is released (synchronous fetch not currently operational).&lt;br /&gt;
&lt;br /&gt;
===Part 2===&lt;br /&gt;
* A continuously running thread fetches the next packet at the front of the packetInbox queue.&lt;br /&gt;
* It enters the LLClientView structure, logging details of the packet for debug purposes if required.&lt;br /&gt;
* The packet is processed either synchronously (on this same thread) or asynchronously by queueing it as a work item to a threadpool (SmartThreadPool by default).&lt;br /&gt;
** Some packets are handled synchronously due to issues if they are processed out of order (e.g. multi-face texture changes not occuring properly).  Others may be synchronous by default where they could actually be handled asynchronously.&lt;br /&gt;
* The long running thread loops.&lt;br /&gt;
&lt;br /&gt;
=Other references=&lt;br /&gt;
&lt;br /&gt;
* [[Sim Throttles]] contains very old information on the implementation of throttles.  This has likely changed considerably but could still be useful.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/0.8_Release</id>
		<title>0.8 Release</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/0.8_Release"/>
				<updated>2014-05-08T04:19:00Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Mesh/Sculpt */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Release Notes=&lt;br /&gt;
== General ==&lt;br /&gt;
&lt;br /&gt;
'''THESE ARE DRAFT RELEASE NOTES.  OPENSIMULATOR IS NOT YET RELEASED, ONLY RELEASE CANDIDATES ARE AVAILABLE.'''&lt;br /&gt;
&lt;br /&gt;
Welcome to OpenSimulator 0.8, an open-source multi-user 3D virtual environment and metaverse server platform. &lt;br /&gt;
&lt;br /&gt;
As ever, OpenSimulator is a highly complex piece of software.  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.&lt;br /&gt;
&lt;br /&gt;
If you are upgrading from a previous verson 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.&lt;br /&gt;
&lt;br /&gt;
As this is a wiki page, please feel free to update it with more information about migration or other issues as and when these come to light.&lt;br /&gt;
&lt;br /&gt;
You can download this release of OpenSimulator from http://opensimulator.org/wiki/Download&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
* Arbitrary key:value storage for regions has not yet been implemented for SQLite or MSSQL.  This is necessary for temporary attachments settings to be persisted.  This functionality is considered experimental.&lt;br /&gt;
* Regression in RLV functionality where objects given via the llGiveInventoryFolder() function with a folder name with the format #RLV/~gift are still placed in the #RLV folder but now with the name still as &amp;quot;#RLV/~gift&amp;quot; rather than just &amp;quot;~gift&amp;quot;.  This is being addressed in http://opensimulator.org/mantis/view.php?id=6311.  Any help from viewer developers on this would be much appreciated.&lt;br /&gt;
* No form of prim equivalence is implemented for meshes.&lt;br /&gt;
* Loading scripts from the library section of inventory does not work properly.&lt;br /&gt;
* The non-default Warp3D maptile generator currently leaks memory very badly.  We recommend that you only use this once at the beginning of each simulator session.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
OpenSimulator requires:&lt;br /&gt;
&lt;br /&gt;
* .NET Framework 4 when running under Windows.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
== Backwards Compatibility Notices ==&lt;br /&gt;
* This release includes database migrations but these should be backward compatible with OpenSimulator 0.7.6/0.7.6.1 (i.e. one could rollback to the previous version of OpenSimulator if necessary without also rolling back the database).  However, this is not a guarantee - please always backup your data before migrating from earlier OpenSimulator versions.&lt;br /&gt;
&lt;br /&gt;
== Changes with possible compatibility issues ==&lt;br /&gt;
&lt;br /&gt;
=== General Server ===&lt;br /&gt;
OpenSimulator now requires .NET 4.  For more details please see above.&lt;br /&gt;
&lt;br /&gt;
=== Physics ===&lt;br /&gt;
As of this release, the default physics engine plugin becomes BulletSim rather than OpenDynamicsEngine.  The BulletSim plugin is significantly better than the OpenDynamicsEngine one, both in terms of performance and in turns of support for physical objects and vehicles.&lt;br /&gt;
&lt;br /&gt;
However, physics engines are very complex beasts and the behaviour between BulletSim and OpenDynamicsEngine will be somewhat different.  If you want to use OpenDynamicsEngine instead, then please make sure this is selected in the physics paramter of the [Startup] section of your OpenSim.ini.&lt;br /&gt;
&lt;br /&gt;
Please note that the OpenDynamicEngines plugin will not support varregions (see below) in this release.&lt;br /&gt;
&lt;br /&gt;
=== Hypergrid ===&lt;br /&gt;
&lt;br /&gt;
In this release, Hypergrid teleports can now be made over 16383 regions in X or Y directions rather than the previous maximum of 4095.  All the most recent third-party viewer releases (Kokua, Firestorm, Singularity) will accomodate this.  However, older releases of those viewers will crash if such a teleport is attempted.  If you still want to retrict teleport distance from your OpenSimulator installation, then please set max_distance in the [EntityTransfer] section of OpenSim.ini.&lt;br /&gt;
&lt;br /&gt;
== Other Changes ==&lt;br /&gt;
&lt;br /&gt;
=== General Server ===&lt;br /&gt;
* Unofficial support for PostgreSQL added to the persistence layer.&lt;br /&gt;
&lt;br /&gt;
=== General Simulator ===&lt;br /&gt;
* OpenSimulator now supports [[Varregion|Varregions]].  This is the ability to create square regions that are larger in size than the standard 256x256 (e.g. 512x512).  These are an alternative to megaregions but require a fairly recent third-party viewer to use - other viewers may crash or experience unknown effects when teleporting to these regions.  Currently, on the BulletSim physics plugin supports varregions.  OARs have support for varregions.  Please see the linked wiki page for more details and setup instructions.&lt;br /&gt;
&lt;br /&gt;
=== Configuration ===&lt;br /&gt;
* Config files found with the the -inidirectory OpenSimulator startup option will now consistenly supersede the settings in other config files.&lt;br /&gt;
&lt;br /&gt;
=== Services ===&lt;br /&gt;
* Added asset exists service call to allow Hypergrid code to determine whether an asset needs to be sent.  Aims to improve Hypergrid efficiency.&lt;br /&gt;
&lt;br /&gt;
=== Hypergrid ===&lt;br /&gt;
* Hypergrid users are now allowed into regions where a group they belong to has permission to enter.&lt;br /&gt;
* Much reduced issues where avatars are reported as &amp;quot;Unknown User&amp;quot; when travelling.&lt;br /&gt;
* Material assets are now sent when objects are moved over the Hypergrid.&lt;br /&gt;
* Assets marked local are no longer erroneously sent to a destination OpenSimulator installation.&lt;br /&gt;
* Error checking improved when creating Hypergid links to reject invalid strings and use the proper default port of 80.&lt;br /&gt;
* Setting of the avatar name improved when a user moves from a foreign grid back to their home grid.&lt;br /&gt;
&lt;br /&gt;
=== Objects ===&lt;br /&gt;
* Scene objects which have their temporary flag unset and then reset are now persisted.&lt;br /&gt;
* Linking two persisted scene linksets then deleting the new linkset will now properly delete all the objects.&lt;br /&gt;
* Support added for particle ribbon, glow and blend.&lt;br /&gt;
* &amp;quot;rotate scene&amp;quot; console command added to rotate the position of all the objects in the scene around a given point.  Does not rotate trees or terrain.&lt;br /&gt;
* &amp;quot;scale scene&amp;quot; console command added to rescale the size of all the objects in the scene.&lt;br /&gt;
* &amp;quot;translate scene&amp;quot; console command added to move all the objects in the scene.&lt;br /&gt;
* The name and description of a coalesced object set in inventory is now applied only to the first object rezzed rather than all of them.&lt;br /&gt;
* The permissions of a coalesced object set in inventory are now the lowest common denominator of all the contained objects.&lt;br /&gt;
* Changing a material on one face of a prim now only changes that face rather than the default material.&lt;br /&gt;
* Keyframe motion no longer stops on a scene object if a user takes a copy into inventory.&lt;br /&gt;
* Keyframe motion fixed in megaregions.&lt;br /&gt;
* Keyframe movement will now work with speeds lower than 0.05 m/s.&lt;br /&gt;
* Changing ownership of an object in god mode will now change the permissions of contained items as well as the object itself.&lt;br /&gt;
* If an object fails to cross regions it is no longer deleted from the source region.&lt;br /&gt;
&lt;br /&gt;
=== Mesh/Sculpt ===&lt;br /&gt;
* Sculpt/mesh assets in attachments are no longer wrongly persisted when a user teleports.  This significantly improves the efficiency and speed of such teleports.&lt;br /&gt;
&lt;br /&gt;
=== Avatars ===&lt;br /&gt;
* Attachment point and positioning is preserved when an object preivously attached is rezzed into the scene.&lt;br /&gt;
* Fixed positioning of an attachment when the root prim is moved separately from the others.&lt;br /&gt;
* Mouselook now moves to the right location when sitting on the child prim of a linkset.&lt;br /&gt;
* The viewer camera no longer judders if an avatar sits on the child prim of a linkset and that linkset moves.&lt;br /&gt;
* Avatar positioning on sit targets should now be identical to that seen on the LL grid.&lt;br /&gt;
* If a sitting avatar is moved by less than 5 cm, updates are now still sent out to other viewers.&lt;br /&gt;
* Avatar stand positions are now directly in front of the avatar's sit position.&lt;br /&gt;
* If the avatar is held in place in the viewer (typically by holding down the space bar) then a stopped avatar will not fly or change position until it is released (they can still rotate).  If the avatar is already moving then their movement will be reduced to half speed.  If the avatar is flying then they will stop in place.&lt;br /&gt;
* The mouselook camera no longer shifts position when the avatar looks up or down.&lt;br /&gt;
* Sitting avatars can now cross between regions.&lt;br /&gt;
* Added missing viewer appearance parameters.&lt;br /&gt;
* Added XBakes system for temporarily saving baked textures so that viewers are not always asked to regenerate and reupload.  This is not the same as server-side baking since baking is still performed by the viewer.  Should be considered experimental.&lt;br /&gt;
&lt;br /&gt;
=== Teleport ===&lt;br /&gt;
* Users can now enter a region if a telehub is present but has no spawnpoints.&lt;br /&gt;
* Improved error messages on teleport failure.&lt;br /&gt;
&lt;br /&gt;
=== Physics ===&lt;br /&gt;
* Maximum default physical prim size increased from 10 meters to 64 meters.&lt;br /&gt;
* The efficiency of the BulletSim plugin was increased.&lt;br /&gt;
* In the BulletSim plugin, avatar physics shape is now a rectangle rather than a capsule.  This should improve avatar movement and allow height to be better calculated.&lt;br /&gt;
* Fixed general collision issues after an object's phantom flag is unset.&lt;br /&gt;
&lt;br /&gt;
=== Sound ===&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== Voice ===&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== Region/Estates/Parcels ===&lt;br /&gt;
* Added console command “estate set owner” to change an estate's owner.&lt;br /&gt;
* Added console command “estate set name” to change an estate's name.&lt;br /&gt;
* Force owner, abadon, request and reclaim updates to a parcel are now persisted.&lt;br /&gt;
* The “Allow Scripts from Group” parcel flag no longer requires the parcel to be deeded to a group, only that it has a group set &lt;br /&gt;
* A user that belongs to a parcel’s group can no longer still rez objects after the “Create Objects by Group” flag is unset &lt;br /&gt;
* Traffic statistics are now persisted if changed by a region module.&lt;br /&gt;
* Added feature to limit the maximum number of prims that a user can have on each parcel of a region.  This is enforced by setting MaxPrimsPerUser in the region config file (e.g. Regions.ini).  Default is no limit.&lt;br /&gt;
* An object rezzed by a user can no longer be duplicated on that same parcel after the parcel permissions have been changed to disallow rezzing.&lt;br /&gt;
* Objects on a parcel can now  be included in the sale of that parcel as long as a) all those objects are owned by the parcel owner b) none of the objects are group owned c) all objects are transferrable.&lt;br /&gt;
* Fixed an issue where the “Show in Search” flag on a parcel sometimes reset spontaneously.&lt;br /&gt;
* Fixed issue where changing the maturity in the viewer preferences would not work.&lt;br /&gt;
&lt;br /&gt;
=== Map ===&lt;br /&gt;
* &amp;quot;generate map&amp;quot; console command added for manual generation of a maptile.&lt;br /&gt;
* Eliminated memory leaks when the default maptile generator is used.  Unfortunately, the Warp3D one still leaks very badly (see above).&lt;br /&gt;
* Static maptiles can now be loaded from a file.&lt;br /&gt;
* Facility added to allow maptile deletion.&lt;br /&gt;
&lt;br /&gt;
=== Instant Messaging ===&lt;br /&gt;
* The sender of an offline IM is now stored.&lt;br /&gt;
&lt;br /&gt;
=== Friends/Profiles ===&lt;br /&gt;
* Fixed an issue where users sometimes didn't get notified of friends online status when logging in.&lt;br /&gt;
* Fixed editing notes for profiles.&lt;br /&gt;
* Fixed issue were some profile settings were not being persisted.&lt;br /&gt;
* Fixed issue with creating user picks where a snapshot had not been set in a parcel.&lt;br /&gt;
&lt;br /&gt;
=== Archiving ===&lt;br /&gt;
* --displacement option added to the &amp;quot;load oar&amp;quot; console command.  This is useful when loading smaller OARs into a varregion.&lt;br /&gt;
* --force-terrain and --force-parcel options added to the “load oar” command.  These override the normal --merge behaviour of not loading terrain or parcel to facilitate loading of smaller OARs into varregions.&lt;br /&gt;
* --rotation and --rotationcenter options added to the “load oar” command.  These apply a rotation around a given center before any specified displacement.&lt;br /&gt;
* --no-objects option added to the &amp;quot;load oar&amp;quot; command to allow loading of all parts of a region except its objects.&lt;br /&gt;
* Material assets are now saved into OARs when necessary.&lt;br /&gt;
* Objects in restored OARs that are owned by groups not present on the grid now have their group ownership cleared.&lt;br /&gt;
&lt;br /&gt;
=== NPC ===&lt;br /&gt;
* NPCs now correctly display multiple attachments on a single attach point.&lt;br /&gt;
&lt;br /&gt;
=== Inventory ===&lt;br /&gt;
* No significant changes in this release.&lt;br /&gt;
&lt;br /&gt;
=== Groups ===&lt;br /&gt;
* Hidden groups no longer show in searches.&lt;br /&gt;
&lt;br /&gt;
=== Monitoring ===&lt;br /&gt;
* HTTP logging improved.&lt;br /&gt;
* Threadpool logging improved.&lt;br /&gt;
&lt;br /&gt;
=== Test ===&lt;br /&gt;
* A set of pCampbots generated in quick succession will now no longer perform identical 'random' actions.&lt;br /&gt;
&lt;br /&gt;
=== Scripting ===&lt;br /&gt;
* Timer and HTTP events are no longer wrong discarded when a script changes state.&lt;br /&gt;
* Many LSL events will now generate syntax errors at compile time if given the wrong number of parameters.   This has not yet been applied to all events.&lt;br /&gt;
* Errors in Windlight funtions fixed that could occur if the script's owner was not present in the region.&lt;br /&gt;
* Moving avatars in llSetLinkPrimitiveParams using PRIM_ROTATION, PRIM_ROT_LOCAL, PRIM_POSITION and PRIM_POS_LOCAL is now supported.&lt;br /&gt;
* llBreakAllLinks() will now only work if PERMISSION_CHANGE_LINKS has been granted.&lt;br /&gt;
* llParticleSystem() and llLinkParticleSystem() will now generate maximum size particles if a particle size greater than maximum is given rather than no particles.&lt;br /&gt;
* Added ATTACH_AVATAR_CENTER and ATTACH_NECK LSL constants.&lt;br /&gt;
* Added osGetRegionSize() OSSL function that will return the current region size.&lt;br /&gt;
* osForceCreateLink(), osForceBreakLink() and osForceBreakAllLinks() OSSL functions implemented.  These are identical to llCreateLink(), llBreakLink() and llBreakAllLinks() except that they don't require granted permissions.&lt;br /&gt;
* Scripts in attachments are now implicitly granted the PERMISSION_TRACK_CAMERA permission.&lt;br /&gt;
&lt;br /&gt;
== Acknowledgements ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Category:Release Notes]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Name_Binding</id>
		<title>Name Binding</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Name_Binding"/>
				<updated>2014-04-09T14:22:56Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Background Information=&lt;br /&gt;
A Second Life/OpenSimulator needs to resolve user UUIDs to names (e.g. 25bf6e60-91c0-4d28-8349-ba254cd4388e -&amp;gt; Jane Doe).  It does this by issuing a UUIDNameRequest UDP message, to which the simulator responds with a UUIDNameReply UDP message containing the binding.&lt;br /&gt;
&lt;br /&gt;
The viewer uses this binding to display names in some contexts, such as local chat and friends lists.  For unknown reasons (possibly code evolution), it does not use this mechanism for displaying names in avatar name bubbles.  Therefore, it's possible for these to be correct whilst local chat names may be wrong.&lt;br /&gt;
&lt;br /&gt;
Once a viewer has received a binding. it stores this in a local cache and never requests it again.&lt;br /&gt;
&lt;br /&gt;
On the server side, these bindings are stored in an in-memory dictionary.  This dictionary is built up by a combination of an initial scan of objects in the region on simulator startup, by later addition of entries into the dictionary, such as when a previously unknown Hypergrid avatar enters a region and on demand when a UUID is actually requested by inspection of user account and grid user data.&lt;br /&gt;
&lt;br /&gt;
Name binding in OpenSimulator is fairly complex due to the requirement to bind the names of users visiting via the [Hypergrid] as well as the more straightforward binding of local users to UUIDs.&lt;br /&gt;
&lt;br /&gt;
If a user binding could not be found, the viewer may receive a binding to &amp;quot;Unknown user&amp;quot; in various forms.&lt;br /&gt;
&lt;br /&gt;
=Server commands=&lt;br /&gt;
In OpenSimulator 0.7.5 onwards, there is a simulator console command called &amp;quot;show names&amp;quot;.  This will show all the current in-memory bindings.&lt;br /&gt;
&lt;br /&gt;
In current OpenSimulator dev code (post 0.7.5), there is also a command called &amp;quot;show name &amp;lt;uuid&amp;gt;&amp;quot; which will show a binding for a given uuid.&lt;br /&gt;
&lt;br /&gt;
=Message exchange=&lt;br /&gt;
In Linden Lab viewer 3.3.4, for an object in a region where the creator of the object is not present and the viewer does not have the creator's UUID bound to a name in cache, as UUIDNameRequest may only be issued when the user requests the properties of an object.&lt;br /&gt;
&lt;br /&gt;
A UUIDNameRequest will always be sent to the simulator occupied by the avatar even if it requests the properties of an object on a neighbouring simulator.&lt;br /&gt;
&lt;br /&gt;
Even if the viewer does not receive a UUIDNameReply for this request after 10 minutes, it will not retry if the object is subsequently selected.&lt;br /&gt;
&lt;br /&gt;
If an avatar without a bound name enters the same region as the viewer and chats, the viewer will issue a UUIDNameRequest even if an outstanding one for object properties for the same UUID is not satisfied.&lt;br /&gt;
&lt;br /&gt;
If the viewer does not receive a reply for this UUIDNameRequest, it will display the user name correctly (presumably from other sources) in the temporary on-screen chat box but will not display any name in the persistent chat box if that is open instead.&lt;br /&gt;
&lt;br /&gt;
=Name Shown Above the Avatar=&lt;br /&gt;
&lt;br /&gt;
In the viewers, the avatar name and title (if any) are shown floating above the avatar. The name that is shown there is sent to the viewer in '''ObjectUpdate''' packets for the ScenePresence. This is a completely separate mechanism from the mechanisms described above.&lt;br /&gt;
&lt;br /&gt;
Viewers have a bug (as of April 2014): if the avatar name changes (as sent in ObjectUpdate packets) then they don't always show the update. They only do so if some other things have changed: the Group Title, Away state, Busy state, etc.&lt;br /&gt;
&lt;br /&gt;
This bug is noticeable when teleporting between grids using the Hypergrid, because the avatar's name in their home grid (&amp;quot;First Last&amp;quot;) is different from their name in other grids (&amp;quot;First.Last @grid.example.com&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
OpenSim 0.8.0 has a workaround for this bug: when an avatar arrives from a different grid, the simulator temporarily changes the group title (to &amp;quot;(Loading)&amp;quot;), and then returns it to its former value. This causes the viewer to show the new avatar name, too.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/AssetService</id>
		<title>AssetService</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/AssetService"/>
				<updated>2014-04-03T11:41:06Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction=&lt;br /&gt;
&lt;br /&gt;
The OpenSimulator asset service stores asset data (textures, serialized objects, scripts, etc.) and provides this on request.&lt;br /&gt;
&lt;br /&gt;
=API=&lt;br /&gt;
&lt;br /&gt;
==GET /assets==&lt;br /&gt;
&lt;br /&gt;
Uri format is&lt;br /&gt;
&lt;br /&gt;
 /assets/&amp;lt;asset-uuid&amp;gt;&lt;br /&gt;
&lt;br /&gt;
e.g.&lt;br /&gt;
&lt;br /&gt;
 /assets/e0eb480b-e405-491d-8ed1-6d0ababe822c&lt;br /&gt;
&lt;br /&gt;
There is no content in the request body.&lt;br /&gt;
&lt;br /&gt;
If the asset was not found, you will receive a 404 status code response with an empty body.&lt;br /&gt;
&lt;br /&gt;
If the asset was found then asset data will be returned.  Sample return data is&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-8&amp;quot;?&amp;gt;&lt;br /&gt;
&amp;lt;AssetBase&amp;gt;&lt;br /&gt;
  &amp;lt;Data&amp;gt;/0//UQAvAAAAAAEAAAABAAAAAAAAAAAAAA...&amp;lt;/Data&amp;gt;&lt;br /&gt;
  &amp;lt;FullID&amp;gt;&lt;br /&gt;
    &amp;lt;Guid&amp;gt;f87f97ff-a493-4fb6-b263-1c8a0f1efc12&amp;lt;/Guid&amp;gt;&lt;br /&gt;
  &amp;lt;/FullID&amp;gt;&lt;br /&gt;
  &amp;lt;ID&amp;gt;f87f97ff-a493-4fb6-b263-1c8a0f1efc12&amp;lt;/ID&amp;gt;&lt;br /&gt;
  &amp;lt;Name&amp;gt;test texture&amp;lt;/Name&amp;gt;&lt;br /&gt;
  &amp;lt;Description&amp;gt;test one&amp;lt;/Description&amp;gt;&lt;br /&gt;
  &amp;lt;Type&amp;gt;0&amp;lt;/Type&amp;gt;&lt;br /&gt;
  &amp;lt;Local&amp;gt;false&amp;lt;/Local&amp;gt;&lt;br /&gt;
  &amp;lt;Temporary&amp;gt;false&amp;lt;/Temporary&amp;gt;&lt;br /&gt;
  &amp;lt;CreatorID&amp;gt;bbbbbbbb-bf88-45ac-aace-35bd76426c81&amp;lt;/CreatorID&amp;gt;&lt;br /&gt;
  &amp;lt;Flags&amp;gt;Normal&amp;lt;/Flags&amp;gt;&lt;br /&gt;
&amp;lt;/AssetBase&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
where&lt;br /&gt;
&lt;br /&gt;
* '''Data''' - Base64 encoding of the asset data.  No maximum length.&lt;br /&gt;
* '''FullID''' - UUID of the asset.  This is identical to ID for historical reasons.&lt;br /&gt;
* '''ID''' UUID of the asset.  This is identical to ID for historical reasons.&lt;br /&gt;
* '''Name''' -  the name of the asset in the database.  This is not actively used since assets are referred to by their inventory names.  Can be useful for debugging purposes.  Maximum size is 64 characters.&lt;br /&gt;
* '''Description''' - Description of asset.  This is not actively used but can be useful in debugging.  Maximum size is 64 characters.&lt;br /&gt;
* '''Type''' - Type of asset.  An integer that comes from [https://github.com/openmetaversefoundation/libopenmetaverse/blob/master/OpenMetaverseTypes/Enums.cs OpenMetaverse.AssetType].&lt;br /&gt;
* '''Local''' - true or false.  In other contexts signals whether asset is local to that simulator only.  In the context of the asset service this should always be false.&lt;br /&gt;
* '''Temporary''' - true or false.  Signals whether the asset should be treated as temporary (and so can be removed on simulator restart) or permanent (which is the usual case).&lt;br /&gt;
* '''CreatorID''' - The ID of the entity that created the asset.  Often a UUID but not mandatory.  This is not actively used but can be useful in debugging.&lt;br /&gt;
* '''Flags''' - Multiple flags must be comma separated (e.g. &amp;lt;Flags&amp;gt;Maptile,Collectable&amp;lt;/Flags&amp;gt;).  Each flag can have leading or trailing whitespace (e.g. &amp;lt;Flags&amp;gt;Maptile,Collectable&amp;lt;/Flags&amp;gt;).  Possible flags are&lt;br /&gt;
** Normal - Normal non-maptile immustable asset.&lt;br /&gt;
** Maptile - Maptile asset.&lt;br /&gt;
** Rewritable - Content can be rewritten&lt;br /&gt;
** Collectable - Asset can be removed after some time (this is poorly defined and may not currently be used).&lt;br /&gt;
&lt;br /&gt;
One should not rely on this element order.  One should also be prepared to ignore or otherwise deal with extra elements.&lt;br /&gt;
&lt;br /&gt;
===Sample scripts===&lt;br /&gt;
&amp;lt;source lang=&amp;quot;python&amp;quot;&amp;gt;&lt;br /&gt;
#!/usr/bin/python&lt;br /&gt;
&lt;br /&gt;
import httplib&lt;br /&gt;
&lt;br /&gt;
conn = httplib.HTTPConnection(&amp;quot;localhost&amp;quot;, 8003);&lt;br /&gt;
conn.request(&amp;quot;GET&amp;quot;, &amp;quot;/assets/f87f97ff-a493-4fb6-b263-1c8a0f1efc11&amp;quot;)&lt;br /&gt;
response = conn.getresponse()&lt;br /&gt;
print &amp;quot;Status:&amp;quot; + str(response.status)&lt;br /&gt;
print response.read();&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==POST /assets==&lt;br /&gt;
&lt;br /&gt;
Uri format is&lt;br /&gt;
&lt;br /&gt;
 /assets&lt;br /&gt;
&lt;br /&gt;
e.g.&lt;br /&gt;
&lt;br /&gt;
Sample request body&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-8&amp;quot;?&amp;gt;&lt;br /&gt;
&amp;lt;AssetBase&amp;gt;&lt;br /&gt;
  &amp;lt;Data&amp;gt;/0//UQAvAAAAAAEAAAABAAAAAAAAAAAAAA...&amp;lt;/Data&amp;gt;&lt;br /&gt;
  &amp;lt;FullID&amp;gt;&lt;br /&gt;
    &amp;lt;Guid&amp;gt;f87f97ff-a493-4fb6-b263-1c8a0f1efc12&amp;lt;/Guid&amp;gt;&lt;br /&gt;
  &amp;lt;/FullID&amp;gt;&lt;br /&gt;
  &amp;lt;ID&amp;gt;f87f97ff-a493-4fb6-b263-1c8a0f1efc12&amp;lt;/ID&amp;gt;&lt;br /&gt;
  &amp;lt;Name&amp;gt;test texture&amp;lt;/Name&amp;gt;&lt;br /&gt;
  &amp;lt;Description&amp;gt;test one&amp;lt;/Description&amp;gt;&lt;br /&gt;
  &amp;lt;Type&amp;gt;0&amp;lt;/Type&amp;gt;&lt;br /&gt;
&amp;lt;/AssetBase&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
where&lt;br /&gt;
&lt;br /&gt;
* '''Data''' - Base64 encoding of the asset data.  No maximum length.&lt;br /&gt;
* '''FullID''' - UUID of the asset.  This is identical to ID for historical reasons.&lt;br /&gt;
* '''ID''' UUID of the asset.  This is identical to ID for historical reasons.&lt;br /&gt;
* '''Name''' -  the name of the asset in the database.  This is not actively used since assets are referred to by their inventory names.  Can be useful for debugging purposes.  Maximum size is 64 characters.&lt;br /&gt;
* '''Description''' - Description of asset.  This is not actively used but can be useful in debugging.  Maximum size is 64 characters.&lt;br /&gt;
* '''Type''' - Type of asset.  An integer that comes from [https://github.com/openmetaversefoundation/libopenmetaverse/blob/master/OpenMetaverseTypes/Enums.cs OpenMetaverse.AssetType].&lt;br /&gt;
* '''Local''' - true or false.  Optional, defaults to false.  In other contexts signals whether asset is local to that simulator only.  In the context of the asset service this should always be false.&lt;br /&gt;
* '''Temporary''' - true or false.  Options, defaults to false.  Signals whether the asset should be treated as temporary (and so can be removed on simulator restart) or permanent (which is the usual case).&lt;br /&gt;
* '''CreatorID''' - The ID of the entity that created the asset.  Optional, the default is blank.  Often a UUID but not mandatory.  This is not actively used but can be useful in debugging.&lt;br /&gt;
* '''Flags''' - Multiple flags must be comma separated (e.g. &amp;lt;Flags&amp;gt;Maptile,Collectable&amp;lt;/Flags&amp;gt;).  Each flag can have leading or trailing whitespace (e.g. &amp;lt;Flags&amp;gt;Maptile,Collectable&amp;lt;/Flags&amp;gt;).  Optional, the default is Normal.  Possible flags are&lt;br /&gt;
** Normal - Normal non-maptile immustable asset.&lt;br /&gt;
** Maptile - Maptile asset.&lt;br /&gt;
** Rewritable - Content can be rewritten&lt;br /&gt;
** Collectable - Asset can be removed after some time (this is poorly defined and may not currently be used).&lt;br /&gt;
&lt;br /&gt;
The order of elements is not important.&lt;br /&gt;
&lt;br /&gt;
If the request is well-formed XML, then data in the form.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-8&amp;quot;?&amp;gt;&lt;br /&gt;
&amp;lt;string&amp;gt;f87f97ff-a493-4fb6-b263-1c8a0f1efc12&amp;lt;/string&amp;gt;&lt;br /&gt;
&lt;br /&gt;
is always returned where string contains the UUID of the asset posted.&lt;br /&gt;
&lt;br /&gt;
From OpenSimulator 0.7.5 onwards, an HTTP status code of 400 (Bad Request) will be returned if the XML is not well-formed.  In OpenSimulator 0.7.4 and previously, the simulator would simply drop the request and not respond.&lt;br /&gt;
&lt;br /&gt;
=== Sample scripts===&lt;br /&gt;
====Python====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang=&amp;quot;python&amp;quot;&amp;gt;&lt;br /&gt;
#!/usr/bin/python&lt;br /&gt;
&lt;br /&gt;
import base64&lt;br /&gt;
import httplib&lt;br /&gt;
import sys &lt;br /&gt;
import xml.dom.minidom as md&lt;br /&gt;
from xml.etree.cElementTree import Element, ElementTree, tostring&lt;br /&gt;
&lt;br /&gt;
idString = &amp;quot;f87f97ff-a493-4fb6-b263-1c8a0f1efc12&amp;quot;&lt;br /&gt;
&lt;br /&gt;
assetBaseElement = Element(&amp;quot;AssetBase&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
dataElement = Element(&amp;quot;Data&amp;quot;)&lt;br /&gt;
dataElement.text = base64.b64encode(&amp;quot;Dummy data&amp;quot;)&lt;br /&gt;
assetBaseElement.append(dataElement)&lt;br /&gt;
&lt;br /&gt;
fullIdElement = Element(&amp;quot;FullID&amp;quot;)&lt;br /&gt;
guidElement = Element(&amp;quot;Guid&amp;quot;)&lt;br /&gt;
guidElement.text = idString&lt;br /&gt;
fullIdElement.append(guidElement)&lt;br /&gt;
assetBaseElement.append(fullIdElement)&lt;br /&gt;
&lt;br /&gt;
idElement = Element(&amp;quot;ID&amp;quot;)&lt;br /&gt;
idElement.text = idString&lt;br /&gt;
assetBaseElement.append(idElement)&lt;br /&gt;
&lt;br /&gt;
nameElement = Element(&amp;quot;Name&amp;quot;)&lt;br /&gt;
nameElement.text = &amp;quot;test texture&amp;quot;&lt;br /&gt;
assetBaseElement.append(nameElement)&lt;br /&gt;
&lt;br /&gt;
descriptionElement = Element(&amp;quot;Description&amp;quot;)&lt;br /&gt;
descriptionElement.text = &amp;quot;test one&amp;quot;&lt;br /&gt;
assetBaseElement.append(descriptionElement)&lt;br /&gt;
&lt;br /&gt;
typeElement = Element(&amp;quot;Type&amp;quot;)&lt;br /&gt;
typeElement.text = &amp;quot;0&amp;quot; &lt;br /&gt;
assetBaseElement.append(typeElement)&lt;br /&gt;
&lt;br /&gt;
doc = ElementTree(assetBaseElement)&lt;br /&gt;
rawXml = tostring(assetBaseElement)&lt;br /&gt;
&lt;br /&gt;
mdDoc = md.parseString(rawXml)&lt;br /&gt;
print mdDoc.toprettyxml()&lt;br /&gt;
&lt;br /&gt;
conn = httplib.HTTPConnection(&amp;quot;localhost&amp;quot;, 8003);&lt;br /&gt;
conn.request(&amp;quot;POST&amp;quot;, &amp;quot;/assets&amp;quot;, rawXml)&lt;br /&gt;
response = conn.getresponse()&lt;br /&gt;
print response.read();&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==DELETE /assets==&lt;br /&gt;
&lt;br /&gt;
'''TODO'''&lt;br /&gt;
&lt;br /&gt;
==POST /get_assets_exist==&lt;br /&gt;
&lt;br /&gt;
Returns whether assets exist in the assets database.&lt;br /&gt;
&lt;br /&gt;
====Request====&lt;br /&gt;
&lt;br /&gt;
The Uri doesn't have any parameters in the path.&lt;br /&gt;
&lt;br /&gt;
The request body contains a list of Asset UUID's.&lt;br /&gt;
&lt;br /&gt;
Sample request body:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-8&amp;quot;?&amp;gt;&lt;br /&gt;
&amp;lt;ArrayOfString xmlns:xsd=&amp;quot;http://www.w3.org/2001/XMLSchema&amp;quot; xmlns:xsi=&amp;quot;http://www.w3.org/2001/XMLSchema-instance&amp;quot;&amp;gt;&lt;br /&gt;
    &amp;lt;string&amp;gt;cdad34d4-2227-4356-b4a1-7f6a91836d2d&amp;lt;/string&amp;gt;&lt;br /&gt;
    &amp;lt;string&amp;gt;89556747-24cb-43ed-920b-47caed15465f&amp;lt;/string&amp;gt;&lt;br /&gt;
&amp;lt;/ArrayOfString&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Response====&lt;br /&gt;
&lt;br /&gt;
For each asset, returns whether it exists or not (true/false).&lt;br /&gt;
&lt;br /&gt;
Sample response:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-8&amp;quot;?&amp;gt;&lt;br /&gt;
&amp;lt;ArrayOfBoolean xmlns:xsd=&amp;quot;http://www.w3.org/2001/XMLSchema&amp;quot; xmlns:xsi=&amp;quot;http://www.w3.org/2001/XMLSchema-instance&amp;quot;&amp;gt;&lt;br /&gt;
    &amp;lt;boolean&amp;gt;true&amp;lt;/boolean&amp;gt;&lt;br /&gt;
    &amp;lt;boolean&amp;gt;false&amp;lt;/boolean&amp;gt;&lt;br /&gt;
&amp;lt;/ArrayOfBoolean&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notes====&lt;br /&gt;
&lt;br /&gt;
Added in OpenSimulator 0.8.0. Older versions will return an error code because they don't support this request. That response is equivalent to returning 'false' for all the assets.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Debugging</id>
		<title>Debugging</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Debugging"/>
				<updated>2014-03-25T08:35:50Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* HTTP Activity in Simulator and Robust */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=General=&lt;br /&gt;
&lt;br /&gt;
In general, OpenSimulator is a difficult system to debug due to its high concurrency, complexity and the lack of good tools for Mono on the Linux/Mac side.  We won't go through general information about using debuggers here, you can find it elsewhere on the net.  However, one thing to note is that the debugger must be capable of ignoring the SelfDeleteException - this is currently used by the XEngine script engine to kill scripts aborted via the llDie() LSL command.&lt;br /&gt;
&lt;br /&gt;
=Internal tools=&lt;br /&gt;
&lt;br /&gt;
There are also logging statements through the OpenSimulator code, some of which are commented out.  Generally these can be uncommented to provide extra useful information, though you may have to resort to adding new log statements.&lt;br /&gt;
&lt;br /&gt;
There are also some internal methods that might be useful.&lt;br /&gt;
&lt;br /&gt;
* Util.PrintCallStack() - This will print the call stack at the time the method is executed before continuing execution.  Unfortunately, due to Mono limitations can only work on the current thread.&lt;br /&gt;
&lt;br /&gt;
=Specific areas=&lt;br /&gt;
However, there are a few things we say about debugging specific OpenSimulator issues.  This section will be expanded as time goes on.&lt;br /&gt;
&lt;br /&gt;
== Initial connection ==&lt;br /&gt;
This trips people up a lot because of the complex interplay between different server processes in grid mode and between simulator and viewer, with viewers on both the local LAN and over the Internet.  Problems here are generally due to configuration rather than OpenSimulator code issues.  See [[Troubleshooting]] for more details.&lt;br /&gt;
&lt;br /&gt;
== Problems after connection established ==&lt;br /&gt;
Here are some commands that can help you get more information is you have problems when a connection has already been established (e.g. avatars stopping in place), etc.  You can get more help on any of these commands by typing &amp;quot;help &amp;lt;command-name&amp;gt;&amp;quot; on the simulator console.&lt;br /&gt;
&lt;br /&gt;
* debug packet &amp;lt;0-256&amp;gt; [&amp;lt;first-name&amp;gt;] [&amp;lt;last-name&amp;gt;] - this command logs various incoming and outgoing packets depending on the packet level (0-256).  This can help determine whether there is any packet flow between simulator and client at all.&lt;br /&gt;
&lt;br /&gt;
* show queues [&amp;lt;full&amp;gt;] - this command shows packet in, out and resent statistics for particular clients, as well as the packets being queued.  Monitoring the in and outbound packet numbers will show if packets are getting through between simulator and viewer.  If resent is climbing rapidly then its likely you have connection issues since the simulator is having to resend lots of packets that aren't being acknowledged by the viewer.  If the Q numbers increase without going down then clients may have extremely small bandwidth limits or the outgoing network connection from the simulator may be overwhelmed.&lt;br /&gt;
&lt;br /&gt;
* show users - show users active on the simulator&lt;br /&gt;
&lt;br /&gt;
* show connections - show information about individual client connections, including their IP address and whether they are active (in OpenSimulator 0.7.4 dev code only).&lt;br /&gt;
&lt;br /&gt;
== Threadpool Activity ==&lt;br /&gt;
&lt;br /&gt;
A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. You can [[General-Purpose Threadpool|enable logging that shows activity in this threadpool]].&lt;br /&gt;
&lt;br /&gt;
== HTTP Activity ==&lt;br /&gt;
&lt;br /&gt;
Use this console command to enable logging of HTTP requests and responses in OpenSim or Robust:&lt;br /&gt;
&lt;br /&gt;
 debug http in|out|all [&amp;lt;level&amp;gt;]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
If in or all and&lt;br /&gt;
  level &amp;lt;= 0 then no extra logging is done.&lt;br /&gt;
  level &amp;gt;= 1 then short warnings are logged when receiving bad input data.&lt;br /&gt;
  level &amp;gt;= 2 then long warnings are logged when receiving bad input data.&lt;br /&gt;
  level &amp;gt;= 3 then short notices about all incoming non-poll HTTP requests are logged.&lt;br /&gt;
  level &amp;gt;= 4 then the time taken to fulfill the request is logged.&lt;br /&gt;
  level &amp;gt;= 5 then a sample from the beginning of the data is logged.&lt;br /&gt;
  level &amp;gt;= 6 then the entire data is logged.&lt;br /&gt;
  no level is specified then the current level is returned.&lt;br /&gt;
&lt;br /&gt;
If out or all and&lt;br /&gt;
  level &amp;gt;= 3 then short notices about all outgoing requests going through WebUtil are logged.&lt;br /&gt;
  level &amp;gt;= 4 then the time taken to fulfill the request is logged.&lt;br /&gt;
  level &amp;gt;= 5 then a sample from the beginning of the data is logged.&lt;br /&gt;
  level &amp;gt;= 6 then the entire data is logged.&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In particular, to get a good idea of the communications flow turn on debug level 5 on both the simulator and Robust to see short snippets from each request and response. This will also show HTTP requests between the viewer and the Simulator.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Debugging</id>
		<title>Debugging</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Debugging"/>
				<updated>2014-03-25T08:35:26Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* HTTP Messages Between Simulator and Robust */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=General=&lt;br /&gt;
&lt;br /&gt;
In general, OpenSimulator is a difficult system to debug due to its high concurrency, complexity and the lack of good tools for Mono on the Linux/Mac side.  We won't go through general information about using debuggers here, you can find it elsewhere on the net.  However, one thing to note is that the debugger must be capable of ignoring the SelfDeleteException - this is currently used by the XEngine script engine to kill scripts aborted via the llDie() LSL command.&lt;br /&gt;
&lt;br /&gt;
=Internal tools=&lt;br /&gt;
&lt;br /&gt;
There are also logging statements through the OpenSimulator code, some of which are commented out.  Generally these can be uncommented to provide extra useful information, though you may have to resort to adding new log statements.&lt;br /&gt;
&lt;br /&gt;
There are also some internal methods that might be useful.&lt;br /&gt;
&lt;br /&gt;
* Util.PrintCallStack() - This will print the call stack at the time the method is executed before continuing execution.  Unfortunately, due to Mono limitations can only work on the current thread.&lt;br /&gt;
&lt;br /&gt;
=Specific areas=&lt;br /&gt;
However, there are a few things we say about debugging specific OpenSimulator issues.  This section will be expanded as time goes on.&lt;br /&gt;
&lt;br /&gt;
== Initial connection ==&lt;br /&gt;
This trips people up a lot because of the complex interplay between different server processes in grid mode and between simulator and viewer, with viewers on both the local LAN and over the Internet.  Problems here are generally due to configuration rather than OpenSimulator code issues.  See [[Troubleshooting]] for more details.&lt;br /&gt;
&lt;br /&gt;
== Problems after connection established ==&lt;br /&gt;
Here are some commands that can help you get more information is you have problems when a connection has already been established (e.g. avatars stopping in place), etc.  You can get more help on any of these commands by typing &amp;quot;help &amp;lt;command-name&amp;gt;&amp;quot; on the simulator console.&lt;br /&gt;
&lt;br /&gt;
* debug packet &amp;lt;0-256&amp;gt; [&amp;lt;first-name&amp;gt;] [&amp;lt;last-name&amp;gt;] - this command logs various incoming and outgoing packets depending on the packet level (0-256).  This can help determine whether there is any packet flow between simulator and client at all.&lt;br /&gt;
&lt;br /&gt;
* show queues [&amp;lt;full&amp;gt;] - this command shows packet in, out and resent statistics for particular clients, as well as the packets being queued.  Monitoring the in and outbound packet numbers will show if packets are getting through between simulator and viewer.  If resent is climbing rapidly then its likely you have connection issues since the simulator is having to resend lots of packets that aren't being acknowledged by the viewer.  If the Q numbers increase without going down then clients may have extremely small bandwidth limits or the outgoing network connection from the simulator may be overwhelmed.&lt;br /&gt;
&lt;br /&gt;
* show users - show users active on the simulator&lt;br /&gt;
&lt;br /&gt;
* show connections - show information about individual client connections, including their IP address and whether they are active (in OpenSimulator 0.7.4 dev code only).&lt;br /&gt;
&lt;br /&gt;
== Threadpool Activity ==&lt;br /&gt;
&lt;br /&gt;
A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. You can [[General-Purpose Threadpool|enable logging that shows activity in this threadpool]].&lt;br /&gt;
&lt;br /&gt;
== HTTP Activity in Simulator and Robust ==&lt;br /&gt;
&lt;br /&gt;
Use this console command to enable logging of HTTP requests and responses in Simulators and Robust:&lt;br /&gt;
&lt;br /&gt;
 debug http in|out|all [&amp;lt;level&amp;gt;]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
If in or all and&lt;br /&gt;
  level &amp;lt;= 0 then no extra logging is done.&lt;br /&gt;
  level &amp;gt;= 1 then short warnings are logged when receiving bad input data.&lt;br /&gt;
  level &amp;gt;= 2 then long warnings are logged when receiving bad input data.&lt;br /&gt;
  level &amp;gt;= 3 then short notices about all incoming non-poll HTTP requests are logged.&lt;br /&gt;
  level &amp;gt;= 4 then the time taken to fulfill the request is logged.&lt;br /&gt;
  level &amp;gt;= 5 then a sample from the beginning of the data is logged.&lt;br /&gt;
  level &amp;gt;= 6 then the entire data is logged.&lt;br /&gt;
  no level is specified then the current level is returned.&lt;br /&gt;
&lt;br /&gt;
If out or all and&lt;br /&gt;
  level &amp;gt;= 3 then short notices about all outgoing requests going through WebUtil are logged.&lt;br /&gt;
  level &amp;gt;= 4 then the time taken to fulfill the request is logged.&lt;br /&gt;
  level &amp;gt;= 5 then a sample from the beginning of the data is logged.&lt;br /&gt;
  level &amp;gt;= 6 then the entire data is logged.&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In particular, to get a good idea of the communications flow turn on debug level 5 on both the simulator and Robust to see short snippets from each request and response. This will also show HTTP requests between the viewer and the Simulator.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Server_Commands</id>
		<title>Server Commands</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Server_Commands"/>
				<updated>2014-03-25T08:26:41Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Debug */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= What are server commands? =&lt;br /&gt;
&lt;br /&gt;
Server commands are those you can type on the console to make the server do various things.&lt;br /&gt;
&lt;br /&gt;
Commands can be divided up into those that apply to the simulator (simulator commands) and those that apply to grid services (service commands).&lt;br /&gt;
&lt;br /&gt;
On a standalone system, both simulator and service commands will be available on the single standalone system console.&lt;br /&gt;
&lt;br /&gt;
On a grid architecture, the simulator commands will be available on the simulators, whilst the service commands will be available on the ROBUST console.&lt;br /&gt;
&lt;br /&gt;
'''Disclaimer''': some commands may not work as expected, some may not work at all, and there is a chance that you may even lose all your settings/contents. This summary quickly goes out of date - the best place to find commands is by typing &amp;quot;help&amp;quot; on the region console.&lt;br /&gt;
&lt;br /&gt;
Except where noted, this list should be accurate for OpenSimulator 0.7.1 onwards.&lt;br /&gt;
&lt;br /&gt;
= Commands =&lt;br /&gt;
&lt;br /&gt;
== General Server Commands ==&lt;br /&gt;
&lt;br /&gt;
These commands are available in both simulator and robust consoles.&lt;br /&gt;
&lt;br /&gt;
=== General ===&lt;br /&gt;
&lt;br /&gt;
* command-script [scriptfile] - Runs a command script containing console commands.&lt;br /&gt;
* quit - shutdown the server.&lt;br /&gt;
* show info - show server information (version and startup path).  Before OpenSimulator 0.7.5 this is only available on the simulator console.&lt;br /&gt;
* show uptime - show server startup time and uptime.  Before OpenSimulator 0.7.5 this is only available on the simulator console.&lt;br /&gt;
* show version - show server version.  Before OpenSimulator 0.7.5 this is only available on the simulator console.&lt;br /&gt;
* shutdown - synonym for quit&lt;br /&gt;
* get log level - In OpenSimulator 0.7.5 and later, print the current console logging level.  In OpenSimulator 0.7.4 and earlier please use the &amp;quot;set log level&amp;quot; command instead without a level parameter.&lt;br /&gt;
* set log level [level] - change the console logging level only. For example, off or debug. See [[Logging]] for more information.  In OpenSimulator 0.7.4 and earlier, if called without the level argument prints the current level.  In OpenSimulator 0.7.5 and later please use the &amp;quot;get log level&amp;quot; command instead.  Only available on ROBUST console from OpenSimulator 0.7.5.&lt;br /&gt;
&lt;br /&gt;
=== Debug ===&lt;br /&gt;
&lt;br /&gt;
* debug http [&amp;lt;level&amp;gt;] - Turn on/off extra logging for HTTP request debugging.  Only available on robust console from commit 94517c8 (dev code post 0.7.3.1).  In current development code (for OpenSimulator 0.7.5) this is debug http in|out|all [&amp;lt;level&amp;gt;] since outbound HTTP messages can also now be logged (this was only possible for inbound before). For more information on this command, see [[Debugging]].&lt;br /&gt;
&lt;br /&gt;
* debug threadpool level &amp;lt;level&amp;gt; - Turn on/off logging of activity in the main threadpool. For more information, see [[General-Purpose Threadpool]].&lt;br /&gt;
&lt;br /&gt;
== Simulator Commands ==&lt;br /&gt;
&lt;br /&gt;
=== General ===&lt;br /&gt;
&lt;br /&gt;
* change region &amp;lt;region name&amp;gt; - subsequent commands apply only to the specified region. If region name is &amp;quot;root&amp;quot; then all regions are selected&lt;br /&gt;
* create region [name] [filename] - Create a new region &lt;br /&gt;
* debug packet &amp;lt;level&amp;gt; - Turn on packet debugging, where OpenSimulator prints out summaries of incoming and outgoing packets for viewers, depending on the level set&lt;br /&gt;
* debug scene - Turn on scene debugging&lt;br /&gt;
* delete-region &amp;lt;name&amp;gt; - Delete a region from disk&lt;br /&gt;
* emergency-monitoring - turn emergency debugging monitoring mode on or off.&lt;br /&gt;
* help [&amp;lt;command&amp;gt;] - Get general command list or more detailed help on a specific command or set of commands&lt;br /&gt;
* link-mapping - Set a local grid co-ordinate to link to a remote hypergrid &lt;br /&gt;
* link-region - Link a HyperGrid region. Not sure how this differs from link-mapping&lt;br /&gt;
* modules list - List modules&lt;br /&gt;
* modules load &amp;lt;name&amp;gt; - Load a module&lt;br /&gt;
* modules unload &amp;lt;name&amp;gt; - Unload a module&lt;br /&gt;
* monitor report - Returns a variety of statistics about the current region and/or simulator&lt;br /&gt;
* region restart abort [&amp;lt;message&amp;gt;] - Abort a scheduled region restart, with an optional message&lt;br /&gt;
* region restart bluebox &amp;lt;message&amp;gt; &amp;lt;delta seconds&amp;gt;+ - Schedule a region restart. If one delta is given then the region is restarted in delta seconds time. A time to restart is sent to users in the region as a dismissable bluebox notice. If multiple deltas are given then a notice is sent when we reach each delta.&lt;br /&gt;
* region restart notice &amp;lt;message&amp;gt; &amp;lt;delta seconds&amp;gt;+ - Schedule a region restart. Same as above except showing a transient notice instead of a dismissable bluebox.&lt;br /&gt;
* reload estate - reload estate data&lt;br /&gt;
* remove-region - remove a region from the simulator&lt;br /&gt;
* restart - Restarts all sims in this instance&lt;br /&gt;
* set region flags &amp;lt;Region name&amp;gt; &amp;lt;flags&amp;gt; - Set database flags for region&lt;br /&gt;
* set terrain heights &amp;lt;corner&amp;gt; &amp;lt;min&amp;gt; &amp;lt;max&amp;gt; [&amp;lt;x&amp;gt;] [&amp;lt;y&amp;gt;] - Sets the terrain texture heights on corner #&amp;lt;corner&amp;gt; to &amp;lt;min&amp;gt;/&amp;lt;max&amp;gt;, if &amp;lt;x&amp;gt; or &amp;lt;y&amp;gt; are specified, it will only set it on regions with a matching coordinate. Specify -1 in &amp;lt;x&amp;gt; or &amp;lt;y&amp;gt; to wildcard that coordinate. Corner # SW = 0, NW = 1, SE = 2, NE = 3.&lt;br /&gt;
* set terrain texture &amp;lt;number&amp;gt; &amp;lt;uuid&amp;gt; [&amp;lt;x&amp;gt;] [&amp;lt;y&amp;gt;] - Sets the terrain &amp;lt;number&amp;gt; to &amp;lt;uuid&amp;gt;, if &amp;lt;x&amp;gt; or &amp;lt;y&amp;gt; are specified, it will only set it on regions with a matching coordinate. Specify -1 in &amp;lt;x&amp;gt; or &amp;lt;y&amp;gt; to wildcard that coordinate.&lt;br /&gt;
* show caps - show all registered capabilities URLs&lt;br /&gt;
:NOTE: In OpenSimulator 0.7.1, &amp;quot;show capabilities&amp;quot; is shown as a result for help command, but actually only &amp;quot;show caps&amp;quot; will be accepted. ([http://opensimulator.org/mantis/view.php?id=5467 #5467])&lt;br /&gt;
* show circuits - Show agent circuit data&lt;br /&gt;
* show connections - show connections data&lt;br /&gt;
* show http-handlers - show all registered http handlers&lt;br /&gt;
* show hyperlinks - list hg regions&lt;br /&gt;
* show modules - show module data&lt;br /&gt;
* show neighbours - Shows the local regions' neighbours&lt;br /&gt;
* show pending-objects - show number of objects in the pending queues of all viewers&lt;br /&gt;
* show pqueues [full] - show priority queue data for each client. Without the 'full' option, only root agents are shown. With the 'full' option child agents are also shown.&lt;br /&gt;
* show queues - Show queue data for agent connections.&lt;br /&gt;
* show ratings - Show rating data&lt;br /&gt;
* show region [region name] - Show region data (Region Name, Region UUID, Location, URI, Owner ID, Flags)&lt;br /&gt;
* show regions - Show regions data (Region Names, XLocation YLocation coordinates, Region Ports, Estate Names)&lt;br /&gt;
* show threads - shows the persistent threads registered with the system. Does not include threadpool threads. &lt;br /&gt;
* show throttles [full] - Show throttle data for each client connection, and the maximum allowed for each connection by the server. Without the 'full' option, only root agents are shown. With the 'full' option child agents are also shown.&lt;br /&gt;
* unlink-region &amp;lt;local name&amp;gt; - unlink a hypergrid region&lt;br /&gt;
&lt;br /&gt;
=== Appearance Commands ===&lt;br /&gt;
&lt;br /&gt;
* appearance show - Show information about avatar appearance. Currently just checks whether the baked texture is &amp;quot;OK&amp;quot; or &amp;quot;corrupt&amp;quot;. Still in development. Only exists in development code at the moment.&lt;br /&gt;
&lt;br /&gt;
=== Archive Commands ===&lt;br /&gt;
&lt;br /&gt;
* load iar &amp;lt;first&amp;gt; &amp;lt;last&amp;gt; &amp;lt;inventory path&amp;gt; &amp;lt;password&amp;gt; [&amp;lt;archive path&amp;gt;] - Load user inventory archive. See [[Inventory Archives]].&lt;br /&gt;
* load oar [filename] - load an OpenSimulator archive. This entirely replaces the current region. Default filename is '''region.oar'''. See [[OpenSim Archives]].&lt;br /&gt;
* load xml [-newIDs [&amp;lt;x&amp;gt; &amp;lt;y&amp;gt; &amp;lt;z&amp;gt;]] - Load a region's data from XML format (0.7.*: DEPRECATED and may be REMOVED soon. Use &amp;quot;load xml2&amp;quot; instead)&lt;br /&gt;
:those xml are the result of the export save or *export save-all&lt;br /&gt;
* load xml2 [filename] - optional parameters not supported for XML2 format as at 1-Jul-2008 &lt;br /&gt;
* save iar &amp;lt;first&amp;gt; &amp;lt;last&amp;gt; &amp;lt;inventory path&amp;gt; &amp;lt;password&amp;gt; [&amp;lt;archive path&amp;gt;] - Save user inventory archive. See [[Inventory Archives]]&lt;br /&gt;
* save oar [filename] - save the current region to an OpenSimulator archive. Default filename is '''region.oar'''. See [[OpenSim Archives]].&lt;br /&gt;
* save prims xml2 [&amp;lt;prim name&amp;gt; &amp;lt;file name&amp;gt;] - Save named prim to XML2&lt;br /&gt;
* save xml [filename] - save prims to XML &lt;br /&gt;
* save xml2 [filename] - save prims to XML (Format 2 - rearrangement of some nodes, to make loading/saving easier) &lt;br /&gt;
&lt;br /&gt;
=== Asset Commands ===&lt;br /&gt;
&lt;br /&gt;
The fcache commands only currently appearance if you are using the fcache asset cache.  This is the default on OpenSimulator.&lt;br /&gt;
&lt;br /&gt;
* fcache assets - Attempt a deep scan and cache of all assets in all scenes&lt;br /&gt;
* fcache clear [file] [memory] - Remove all assets in the cache.  If file or memory is specified then only this cache is cleared.&lt;br /&gt;
* fcache expire &amp;lt;datetime&amp;gt; - Purge cached assets older then the specified date/time&lt;br /&gt;
* fcache status - Display cache status&lt;br /&gt;
* j2k decode &amp;lt;ID&amp;gt; - Do JPEG2000 decoding of an asset.&lt;br /&gt;
&lt;br /&gt;
=== Config Commands ===&lt;br /&gt;
&lt;br /&gt;
* config get [&amp;lt;section&amp;gt;] [&amp;lt;key&amp;gt;] - Get the current configuration, either for a particular key, a particular section or the whole config.&lt;br /&gt;
* config save &amp;lt;path&amp;gt; - Save the current configuration to a file.&lt;br /&gt;
* config set &amp;lt;section&amp;gt; &amp;lt;key&amp;gt; - Set a particular configuration value. On the whole, this is useless since neither OpenSimulator nor modules dynamically reload config values.&lt;br /&gt;
* config show [&amp;lt;section&amp;gt;] [&amp;lt;key&amp;gt;] - Synonym for 'config get'&lt;br /&gt;
&lt;br /&gt;
=== Land Commands ===&lt;br /&gt;
&lt;br /&gt;
* land show - Shows all parcels on the current region.&lt;br /&gt;
&lt;br /&gt;
=== Map Commands ===&lt;br /&gt;
&lt;br /&gt;
* export-map [&amp;lt;path&amp;gt;] - Save an image of the world map (default name is exportmap.jpg)&lt;br /&gt;
* generate map - Regenerates and stores map tile.  Only in development code post 0.7.6.&lt;br /&gt;
&lt;br /&gt;
=== Object Commands ===&lt;br /&gt;
&lt;br /&gt;
* backup - Persist currently unsaved object changes immediately instead of waiting for the normal persistence call.  This shouldn't normally be required - the simulator persists region objects automatically at regular intervals and on shutdown.&lt;br /&gt;
* delete object creator &amp;lt;UUID&amp;gt; - Delete a scene object by creator&lt;br /&gt;
* delete object name [--regex] &amp;lt;name&amp;gt; - Delete a scene object by name.&lt;br /&gt;
* delete object outside - Delete all scene objects outside region boundaries.  This is currently if z &amp;lt; 0 or z &amp;gt; 10000.  Object outside these bounds have been known to cause issues with OpenSimulator's use of some physics engines (such as the Open Dynamics Engine).&lt;br /&gt;
* delete object owner &amp;lt;UUID&amp;gt; - Delete a scene object by owner&lt;br /&gt;
* delete object uuid &amp;lt;UUID&amp;gt; - Delete a scene object by uuid.  In current dev code (post 0.7.5) this is &amp;quot;show object id&amp;quot; and also allows a local ID.&lt;br /&gt;
* dump object id &amp;lt;UUID-or-localID&amp;gt; - Dump the serialization of the given object to a file for debug purposes.&lt;br /&gt;
* edit scale &amp;lt;name&amp;gt; &amp;lt;x&amp;gt; &amp;lt;y&amp;gt; &amp;lt;z&amp;gt; - Change the scale of a named prim&lt;br /&gt;
* force update - Force the region to send all clients updates about all objects.&lt;br /&gt;
* show object name [--regex] &amp;lt;name&amp;gt; - Show details of scene objects with the given name.&lt;br /&gt;
* show object uuid &amp;lt;UUID&amp;gt; - Show details of a scene object with the given UUID.  In current dev code (post 0.7.5) this is &amp;quot;show object id&amp;quot; and also allows a local ID.&lt;br /&gt;
* show part name [--regex] &amp;lt;name&amp;gt; - Show details of scene object parts with the given name.&lt;br /&gt;
* show part uuid &amp;lt;UUID&amp;gt; - Show details of a scene object parts with the given UUID.  In current dev code (post 0.7.5) this is &amp;quot;show object id&amp;quot; and also allows a local ID.&lt;br /&gt;
&lt;br /&gt;
=== Scene Commands ===&lt;br /&gt;
&lt;br /&gt;
*rotate scene &amp;lt;degrees&amp;gt; - Rotates scene around 128,128 axis by x degrees where x=0-360.&lt;br /&gt;
*scale scene &amp;lt;factor&amp;gt; - Scales all scene objects by a factor where original size =1.0.&lt;br /&gt;
*translate scene &amp;lt;x,y,z&amp;gt; - Translate (move) the entire scene to a new coordinate. Useful for moving a scene to a different location on either a Mega or Variable region. &lt;br /&gt;
(please back up your region before using any of these commands and be aware of possible floating point errors the more they are used.)&lt;br /&gt;
 &lt;br /&gt;
=== Script Commands ===&lt;br /&gt;
&lt;br /&gt;
These currently only exist in git master OpenSimulator development code post the 0.7.2 release.&lt;br /&gt;
&lt;br /&gt;
* scripts resume [&amp;lt;script-item-uuid&amp;gt;] - Resumes all suspended scripts&lt;br /&gt;
* scripts show [&amp;lt;script-item-uuid&amp;gt;] - Show script information. &amp;lt;script-item-uuid&amp;gt; option only exists from git master 82f0e19 (2012-01-14) onwards (post OpenSimulator 0.7.2).&lt;br /&gt;
* scripts start [&amp;lt;script-item-uuid&amp;gt;] - Starts all stopped scripts&lt;br /&gt;
* scripts stop [&amp;lt;script-item-uuid&amp;gt;] - Stops all running scripts&lt;br /&gt;
* scripts suspend [&amp;lt;script-item-uuid&amp;gt;] - Suspends all running scripts&lt;br /&gt;
&lt;br /&gt;
=== Stats Commands ===&lt;br /&gt;
&lt;br /&gt;
* show stats - show useful statistical information for this server. See [[#Frame Statistics Values|Frame Statistics Values]] below for more information.&lt;br /&gt;
* stats show - a synonym for &amp;quot;show stats&amp;quot; (OpenSimulator dev code only post 19th March 2014).&lt;br /&gt;
* stats record - record stats periodically to a separate log file.&lt;br /&gt;
* stats save - save a snapshot of current stats to a file (OpenSimulator dev code only post 19th March 2014).&lt;br /&gt;
&lt;br /&gt;
=== Terrain Commands ===&lt;br /&gt;
&lt;br /&gt;
Note that some of these may require a sim restart to show properly.&lt;br /&gt;
* terrain load - Loads a terrain from a specified file.&lt;br /&gt;
* terrain load-tile - Loads a terrain from a section of a larger file.&lt;br /&gt;
* terrain save - Saves the current heightmap to a specified file.&lt;br /&gt;
* terrain fill - Fills the current heightmap with a specified value.&lt;br /&gt;
* terrain elevate - Raises the current heightmap by the specified amount.&lt;br /&gt;
* terrain lower - Lowers the current heightmap by the specified amount.&lt;br /&gt;
* terrain multiply - Multiplies the heightmap by the value specified.&lt;br /&gt;
* terrain bake - Saves the current terrain into the regions revert map.&lt;br /&gt;
* terrain revert - Loads the revert map terrain into the regions heightmap.&lt;br /&gt;
* terrain newbrushes - Enables experimental brushes which replace the standard terrain brushes. WARNING: This is a debug setting and may be removed at any time.&lt;br /&gt;
* terrain stats - Shows some information about the regions heightmap for debugging purposes.&lt;br /&gt;
* terrain effect - Runs a specified plugin effect&lt;br /&gt;
&lt;br /&gt;
=== Tree Commands ===&lt;br /&gt;
&lt;br /&gt;
* tree active - Change activity state for the trees module&lt;br /&gt;
* tree freeze - Freeze/Unfreeze activity for a defined copse&lt;br /&gt;
* tree load - Load a copse definition from an xml file&lt;br /&gt;
* tree plant - Start the planting on a copse&lt;br /&gt;
* tree rate - Reset the tree update rate (mSec)&lt;br /&gt;
* tree reload - Reload copse definitions from the in-scene trees&lt;br /&gt;
* tree remove - Remove a copse definition and all its in-scene trees&lt;br /&gt;
* tree statistics - Log statistics about the trees&lt;br /&gt;
&lt;br /&gt;
=== User Commands ===&lt;br /&gt;
&lt;br /&gt;
* alert &amp;lt;message&amp;gt; - send an in-world alert to everyone&lt;br /&gt;
* alert-user &amp;lt;first&amp;gt; &amp;lt;last&amp;gt; &amp;lt;message&amp;gt; - send an an in-world alert to a specific user&lt;br /&gt;
* bypass permissions &amp;amp;lt;true / false&amp;amp;gt; - Bypass in-world permission checks &lt;br /&gt;
* debug permissions - Turn on permissions debugging&lt;br /&gt;
* force permissions - Force permissions on or off.&lt;br /&gt;
* kick user &amp;lt;first&amp;gt; &amp;lt;last&amp;gt; [message]: - Kick a user off the simulator&lt;br /&gt;
* login disable - Disable user entry to this simulator&lt;br /&gt;
* login enable - Enable user entry to this simulator&lt;br /&gt;
* login status - Show whether logins to this simulator are enabled or disabled&lt;br /&gt;
* show users [full]- show info about currently connected users to this region. Without the 'full' option, only users actually on the region are shown. With the 'full' option child agents of users in neighbouring regions are also shown.&lt;br /&gt;
* teleport user &amp;lt;destination&amp;gt; - Teleport a user on this simulator to a specific destination.  Currently only in OpenSimulator development code after the 0.7.3.1 release (commit bf0b817).&lt;br /&gt;
&lt;br /&gt;
=== Windlight/[[LightShare]] Commands ===&lt;br /&gt;
&lt;br /&gt;
* windlight load - Load windlight profile from the database and broadcast&lt;br /&gt;
* windlight enable - Enable the windlight plugin&lt;br /&gt;
* windlight disable - Enable the windlight plugin&lt;br /&gt;
&lt;br /&gt;
== ROBUST Service Commands ==&lt;br /&gt;
&lt;br /&gt;
These can also be accessed on the simulator command console itself in standalone mode.&lt;br /&gt;
&lt;br /&gt;
=== Asset Service ===&lt;br /&gt;
&lt;br /&gt;
* delete asset - Delete an asset from the database. Doesn't appear to be implemented.&lt;br /&gt;
* dump asset &amp;lt;ID&amp;gt; - Dump an asset to the filesystem.  OpenSimulator 0.7.3 onwards.&lt;br /&gt;
* show digest &amp;lt;ID&amp;gt; - Show summary information about an asset. From OpenSimulator 0.7.3 onwards this will be renamed to &amp;quot;show asset&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Grid Service ===&lt;br /&gt;
&lt;br /&gt;
* set region flags &amp;lt;Region name&amp;gt; &amp;lt;flags&amp;gt; - Set database flags for region&lt;br /&gt;
* show region &amp;lt;Region name&amp;gt; - Show the details of a given region.  This command is renamed to &amp;quot;show region name&amp;quot; in development versions of OpenSimulator.&lt;br /&gt;
&lt;br /&gt;
The following commands currently only exist in development versions of OpenSimulator (post 0.7.3.1).  These are currently found in the &amp;quot;Regions&amp;quot; help section.&lt;br /&gt;
&lt;br /&gt;
* deregister region id &amp;lt;Region UUID&amp;gt; - Deregister a region manually.  This can be helpful if a region was not properly removed due to bad simulator shutdown and the simulator has not since been restarted or its region configuration has been changed.&lt;br /&gt;
* show region at &amp;lt;x-coord&amp;gt; &amp;lt;y-coord&amp;gt; - Show details on a region at the given co-ordinate.&lt;br /&gt;
* show region name &amp;lt;Region name&amp;gt; - Show details on a region&lt;br /&gt;
* show regions - Show details on all regions.  In standalone mode this version of the command is not currently available - the simulator version of &amp;quot;show regions&amp;quot; is used instead, which shows similar information.&lt;br /&gt;
&lt;br /&gt;
=== User Service ===&lt;br /&gt;
* create user [first] [last] [passw] [RegionX] [RegionY] [Email] - creates a new user and password&lt;br /&gt;
:or just: create user - and server prompts for all data&lt;br /&gt;
:&lt;br /&gt;
:'''Note for use of create user in standalone mode:''' use the user default coordinates&lt;br /&gt;
:of 1000,1000 for Start Region X and Y position otherwise server&lt;br /&gt;
:gives error of &amp;quot;[LOGIN]: Not found region&amp;quot; &lt;br /&gt;
&lt;br /&gt;
* reset user password - reset a user's password.&lt;br /&gt;
* show account &amp;lt;firstname&amp;gt; &amp;lt;lastname&amp;gt; - show account details for the given user name (0.7.2-dev)&lt;br /&gt;
&lt;br /&gt;
=== Login Service ===&lt;br /&gt;
* login level &amp;lt;value&amp;gt; - Set the miminim userlevel allowed to login.&lt;br /&gt;
* login reset - reset the login level to its default value.&lt;br /&gt;
* login text &amp;lt;text to print during the login&amp;gt;&lt;br /&gt;
* set user level &amp;lt;firstname&amp;gt; &amp;lt;lastname&amp;gt; &amp;lt;level&amp;gt; - Set UserLevel for the user, which determines whether a user has a god account or can login at all (0.7.2-dev)&lt;br /&gt;
&lt;br /&gt;
== Details of Terrain Module Commands ==&lt;br /&gt;
&lt;br /&gt;
==== terrain load ====&lt;br /&gt;
Loads a terrain from a specified file.&lt;br /&gt;
&lt;br /&gt;
Parameters&lt;br /&gt;
* filename (String)&lt;br /&gt;
	The file you wish to load from, the file extension determines the loader to be used. Supported extensions include: .r32 (RAW32) .f32 (RAW32) .ter (Terragen) .raw (LL/SL RAW) .jpg (JPEG) .jpeg (JPEG) .bmp (BMP) .png (PNG) .gif (GIF) .tif (TIFF) .tiff (TIFF)&lt;br /&gt;
&lt;br /&gt;
==== terrain load-tile ====&lt;br /&gt;
Loads a terrain from a section of a larger file.&lt;br /&gt;
&lt;br /&gt;
Parameters&lt;br /&gt;
* filename (String)&lt;br /&gt;
	The file you wish to load from, the file extension determines the loader to be used. Supported extensions include: .r32 (RAW32) .f32 (RAW32) .ter (Terragen) .raw (LL/SL RAW) .jpg (JPEG) .jpeg (JPEG) .bmp (BMP) .png (PNG) .gif (GIF) .tif (TIFF) .tiff (TIFF)&lt;br /&gt;
* file width (Integer)&lt;br /&gt;
	The width of the file in tiles&lt;br /&gt;
* file height (Integer)&lt;br /&gt;
	The height of the file in tiles&lt;br /&gt;
* minimum X tile (Integer)&lt;br /&gt;
	The X region coordinate of the first section on the file&lt;br /&gt;
* minimum Y tile (Integer)&lt;br /&gt;
	The Y region coordinate of the first section on the file&lt;br /&gt;
&lt;br /&gt;
==== terrain save ====&lt;br /&gt;
Saves the current heightmap to a specified file.&lt;br /&gt;
&lt;br /&gt;
Parameters&lt;br /&gt;
* filename (String)&lt;br /&gt;
	The destination filename for your heightmap, the file extension determines the format to save in. Supported extensions include: .r32 (RAW32) .f32 (RAW32) .ter (Terragen) .raw (LL/SL RAW) .jpg (JPEG) .jpeg (JPEG) .bmp (BMP) .png (PNG) .gif (GIF) .tif (TIFF) .tiff (TIFF)&lt;br /&gt;
&lt;br /&gt;
==== terrain fill ====&lt;br /&gt;
Fills the current heightmap with a specified value.&lt;br /&gt;
&lt;br /&gt;
Parameters&lt;br /&gt;
* value (Double)&lt;br /&gt;
	The numeric value of the height you wish to set your region to.&lt;br /&gt;
&lt;br /&gt;
==== terrain elevate ====&lt;br /&gt;
Raises the current heightmap by the specified amount.&lt;br /&gt;
&lt;br /&gt;
Parameters&lt;br /&gt;
* amount (Double)&lt;br /&gt;
&lt;br /&gt;
==== terrain lower ====&lt;br /&gt;
Lowers the current heightmap by the specified amount.&lt;br /&gt;
&lt;br /&gt;
Parameters&lt;br /&gt;
* amount (Double)&lt;br /&gt;
	The amount of height to remove from the terrain in meters.&lt;br /&gt;
&lt;br /&gt;
==== terrain multiply ====&lt;br /&gt;
Multiplies the heightmap by the value specified.&lt;br /&gt;
&lt;br /&gt;
Parameters&lt;br /&gt;
* value (Double)&lt;br /&gt;
	The value to multiply the heightmap by.&lt;br /&gt;
&lt;br /&gt;
==== terrain bake ====&lt;br /&gt;
Saves the current terrain into the regions revert map.&lt;br /&gt;
&lt;br /&gt;
==== terrain revert ====&lt;br /&gt;
Loads the revert map terrain into the regions heightmap.&lt;br /&gt;
&lt;br /&gt;
==== terrain newbrushes ====&lt;br /&gt;
Enables experimental brushes which replace the standard terrain brushes. WARNING: This is a debug setting and may be removed at any time.&lt;br /&gt;
&lt;br /&gt;
Parameters&lt;br /&gt;
* Enabled? (Boolean)&lt;br /&gt;
	true / false - Enable new brushes&lt;br /&gt;
&lt;br /&gt;
==== terrain stats ====&lt;br /&gt;
Shows some information about the regions heightmap for debugging purposes.&lt;br /&gt;
&lt;br /&gt;
==== terrain effect ====&lt;br /&gt;
Runs a specified plugin effect&lt;br /&gt;
&lt;br /&gt;
Parameters&lt;br /&gt;
* name (String)&lt;br /&gt;
	The plugin effect you wish to run, or 'list' to see all plugins&lt;br /&gt;
&lt;br /&gt;
== Details of Hypergrid Commands ==&lt;br /&gt;
&lt;br /&gt;
For full details and explanations of Hypergrid Commands, see the [http://opensimulator.org/wiki/Installing_and_Running_Hypergrid#Linking_regions_.28Optional.29 Linking Regions] sections of the [http://opensimulator.org/wiki/Installing_and_Running_Hypergrid Installing and Running Hypergrid] page.&lt;br /&gt;
&lt;br /&gt;
'''show hyperlinks''' &lt;br /&gt;
&lt;br /&gt;
This command will show a list of all hypergrid linked regions.&lt;br /&gt;
&lt;br /&gt;
'''link-region &amp;lt;Xloc&amp;gt; &amp;lt;Yloc&amp;gt; &amp;lt;host&amp;gt; &amp;lt;port&amp;gt; &amp;lt;location-name&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.&lt;br /&gt;
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to&lt;br /&gt;
&lt;br /&gt;
E.g. link-region 8998 8998 osl2.nac.uci.edu 9006 OSGrid Gateway&lt;br /&gt;
&lt;br /&gt;
'''unlink-region &amp;lt;local region name&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
This command will unlink the specified hypergrid linked region - be sure to use the exact local name as reported by the &amp;quot;show hyperlinks&amp;quot; command.&lt;br /&gt;
&lt;br /&gt;
'''Important Note'''&lt;br /&gt;
&lt;br /&gt;
Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.&lt;br /&gt;
&lt;br /&gt;
link-mapping&lt;br /&gt;
== Frame Statistics Values ==&lt;br /&gt;
&lt;br /&gt;
The labels of the Frame Statistics values shown by the console command &amp;quot;show stats&amp;quot; are a bit cryptic. Here is a list of the meanings of these values:&lt;br /&gt;
&lt;br /&gt;
* Dilatn - time dilation&lt;br /&gt;
* SimFPS - sim FPS&lt;br /&gt;
* PhyFPS - physics FPS&lt;br /&gt;
* AgntUp - # of agent updates&lt;br /&gt;
* RootAg - # of root agents&lt;br /&gt;
* ChldAg - # of child agents&lt;br /&gt;
* Prims - # of total prims&lt;br /&gt;
* AtvPrm - # of active prims&lt;br /&gt;
* AtvScr - # of active scripts&lt;br /&gt;
* ScrLPS - # of script lines per second&lt;br /&gt;
* PktsIn - # of in packets per second&lt;br /&gt;
* PktOut - # of out packets per second&lt;br /&gt;
* PendDl - # of pending downloads&lt;br /&gt;
* PendUl - # of pending uploads&lt;br /&gt;
* UnackB - # of unacknowledged bytes&lt;br /&gt;
* TotlFt - total frame time&lt;br /&gt;
* NetFt - net frame time&lt;br /&gt;
* PhysFt - physics frame time&lt;br /&gt;
* OthrFt - other frame time&lt;br /&gt;
* AgntFt - agent frame time&lt;br /&gt;
* ImgsFt - image frame time&lt;br /&gt;
&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/General-Purpose_Threadpool</id>
		<title>General-Purpose Threadpool</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/General-Purpose_Threadpool"/>
				<updated>2014-03-25T08:25:32Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Logging Activity */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Overview=&lt;br /&gt;
&lt;br /&gt;
A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. This threadpool is managed in Util.cs.&lt;br /&gt;
&lt;br /&gt;
Tasks are added to the threadpool by calling &amp;lt;code&amp;gt;Util.FireAndForget(function)&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=Logging Activity=&lt;br /&gt;
&lt;br /&gt;
There's a console command that enables logging of the tasks in the threadpool. When this option is enabled, the following events are logged:&lt;br /&gt;
&lt;br /&gt;
* Task queued (added to the threadpool)&lt;br /&gt;
* Task started running&lt;br /&gt;
* Task finished running&lt;br /&gt;
* Task timed-out and was terminated&lt;br /&gt;
&lt;br /&gt;
Each time these events are logged, we also log the number of Queued and Running tasks. This shows how busy OpenSim is.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To enable or disable logging, run from the console:&lt;br /&gt;
&lt;br /&gt;
 debug threadpool level &amp;lt;level&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
There are 4 logging levels:&lt;br /&gt;
&lt;br /&gt;
'''0 = no logging (default)''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Turns off logging.&lt;br /&gt;
&lt;br /&gt;
'''1 = only first line of stack trace; don't log common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Short logging. Instead of logging the full stack trace where the task was queued, this only logs the first line of the stack trace. This doesn't log common tasks such as BeginFireQueueEmpty, since they tend to fill up the log quickly.&lt;br /&gt;
&lt;br /&gt;
'''2 = full stack trace; don't log common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Logs the full stack trace where the task was queued. Still doesn't log common tasks.&lt;br /&gt;
&lt;br /&gt;
'''3 = full stack trace, including common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Logs everything.&lt;br /&gt;
&lt;br /&gt;
== Overload Mode ==&lt;br /&gt;
&lt;br /&gt;
When the threadpool is close to full, we enter &amp;quot;Overload Mode&amp;quot;. In that mode we start logging threadpool activity even if the log level is 0. This is useful when running OpenSim in production, as it means that the log level can be kept at 0, yet we still get useful diagnostic information in case OpenSim becomes overloaded, which can help us find the cause of the overload.&lt;br /&gt;
&lt;br /&gt;
== Sample Logging Output ==&lt;br /&gt;
&lt;br /&gt;
'''Level 1'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre style=&amp;quot;white-space: pre-wrap; word-wrap: break-word;&amp;quot;&amp;gt;&lt;br /&gt;
2014-03-25 08:50:39,403 DEBUG - OpenSim.Framework.Util Queue threadfunc 32 (Queued 1, Running 0) at OpenSim.Region.ClientStack.LindenUDP.LLClientView.SendWindData(Vector2[] windSpeeds) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 1292&lt;br /&gt;
2014-03-25 08:50:39,406 DEBUG - OpenSim.Framework.Util Run threadfunc 32 (Queued 0, Running 1)&lt;br /&gt;
2014-03-25 08:50:39,409 DEBUG - OpenSim.Framework.Util Exit threadfunc 32 (0 ms)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Levels 2-3'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre style=&amp;quot;white-space: pre-wrap; word-wrap: break-word;&amp;quot;&amp;gt;&lt;br /&gt;
2014-03-25 08:50:52,118 DEBUG - OpenSim.Framework.Util Queue threadfunc 33 (Queued 1, Running 0) at OpenSim.Region.Framework.Scenes.ScenePresence.SendScriptEventToAttachments(String eventName, Object[] args) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 4283&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.Animation.ScenePresenceAnimator.TrySetMovementAnimation(String anim) in c:\opensim\OpenSim\Region\Framework\Scenes\Animation\ScenePresenceAnimator.cs:line 190&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.Animation.ScenePresenceAnimator.UpdateMovementAnimations() in c:\opensim\OpenSim\Region\Framework\Scenes\Animation\ScenePresenceAnimator.cs:line 461&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.ScenePresence.AddNewMovement(Vector3 vec, Single thisAddSpeedModifier) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 3060&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.ScenePresence.HandleAgentUpdate(IClientAPI remoteClient, AgentUpdateArgs agentData) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 2154&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.HandleAgentUpdate(IClientAPI sener, Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 5778&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.ProcessPacketMethod(Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 707&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.ProcessInPacket(Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 12372&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.ProcessInPacket(IncomingPacket incomingPacket) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 2265&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.IncomingPacketHandler() in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 1990&lt;br /&gt;
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)&lt;br /&gt;
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)&lt;br /&gt;
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)&lt;br /&gt;
   at System.Threading.ThreadHelper.ThreadStart()&lt;br /&gt;
2014-03-25 08:50:52,126 DEBUG - OpenSim.Framework.Util Run threadfunc 33 (Queued 0, Running 1)&lt;br /&gt;
2014-03-25 08:50:52,129 DEBUG - OpenSim.Framework.Util Exit threadfunc 33 (0 ms)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Terminating Hung Threads=&lt;br /&gt;
&lt;br /&gt;
This threadpool has a watchdog timer, which terminates threads if they've been running for over a minute. This prevents exhaustion of the threadpool due to threads that are hung.&lt;br /&gt;
&lt;br /&gt;
On Windows (using .NET), OpenSim will even log a stack trace of the point where the thread was hung. Unfortunately this isn't possible when using Mono.&lt;br /&gt;
&lt;br /&gt;
Tasks that might actually run longer than a minute should not be run on the threadpool. There's a different utility method for running such tasks: &amp;lt;code&amp;gt;Util.RunThreadNoTimeout()&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Debugging</id>
		<title>Debugging</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Debugging"/>
				<updated>2014-03-25T08:24:45Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=General=&lt;br /&gt;
&lt;br /&gt;
In general, OpenSimulator is a difficult system to debug due to its high concurrency, complexity and the lack of good tools for Mono on the Linux/Mac side.  We won't go through general information about using debuggers here, you can find it elsewhere on the net.  However, one thing to note is that the debugger must be capable of ignoring the SelfDeleteException - this is currently used by the XEngine script engine to kill scripts aborted via the llDie() LSL command.&lt;br /&gt;
&lt;br /&gt;
=Internal tools=&lt;br /&gt;
&lt;br /&gt;
There are also logging statements through the OpenSimulator code, some of which are commented out.  Generally these can be uncommented to provide extra useful information, though you may have to resort to adding new log statements.&lt;br /&gt;
&lt;br /&gt;
There are also some internal methods that might be useful.&lt;br /&gt;
&lt;br /&gt;
* Util.PrintCallStack() - This will print the call stack at the time the method is executed before continuing execution.  Unfortunately, due to Mono limitations can only work on the current thread.&lt;br /&gt;
&lt;br /&gt;
=Specific areas=&lt;br /&gt;
However, there are a few things we say about debugging specific OpenSimulator issues.  This section will be expanded as time goes on.&lt;br /&gt;
&lt;br /&gt;
== Initial connection ==&lt;br /&gt;
This trips people up a lot because of the complex interplay between different server processes in grid mode and between simulator and viewer, with viewers on both the local LAN and over the Internet.  Problems here are generally due to configuration rather than OpenSimulator code issues.  See [[Troubleshooting]] for more details.&lt;br /&gt;
&lt;br /&gt;
== Problems after connection established ==&lt;br /&gt;
Here are some commands that can help you get more information is you have problems when a connection has already been established (e.g. avatars stopping in place), etc.  You can get more help on any of these commands by typing &amp;quot;help &amp;lt;command-name&amp;gt;&amp;quot; on the simulator console.&lt;br /&gt;
&lt;br /&gt;
* debug packet &amp;lt;0-256&amp;gt; [&amp;lt;first-name&amp;gt;] [&amp;lt;last-name&amp;gt;] - this command logs various incoming and outgoing packets depending on the packet level (0-256).  This can help determine whether there is any packet flow between simulator and client at all.&lt;br /&gt;
&lt;br /&gt;
* show queues [&amp;lt;full&amp;gt;] - this command shows packet in, out and resent statistics for particular clients, as well as the packets being queued.  Monitoring the in and outbound packet numbers will show if packets are getting through between simulator and viewer.  If resent is climbing rapidly then its likely you have connection issues since the simulator is having to resend lots of packets that aren't being acknowledged by the viewer.  If the Q numbers increase without going down then clients may have extremely small bandwidth limits or the outgoing network connection from the simulator may be overwhelmed.&lt;br /&gt;
&lt;br /&gt;
* show users - show users active on the simulator&lt;br /&gt;
&lt;br /&gt;
* show connections - show information about individual client connections, including their IP address and whether they are active (in OpenSimulator 0.7.4 dev code only).&lt;br /&gt;
&lt;br /&gt;
== Threadpool Activity ==&lt;br /&gt;
&lt;br /&gt;
A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. You can [[General-Purpose Threadpool|enable logging that shows activity in this threadpool]].&lt;br /&gt;
&lt;br /&gt;
== HTTP Messages Between Simulator and Robust ==&lt;br /&gt;
&lt;br /&gt;
Use this console command to enable logging of HTTP requests and responses between Simulators and Robust:&lt;br /&gt;
&lt;br /&gt;
 debug http in|out|all [&amp;lt;level&amp;gt;]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
If in or all and&lt;br /&gt;
  level &amp;lt;= 0 then no extra logging is done.&lt;br /&gt;
  level &amp;gt;= 1 then short warnings are logged when receiving bad input data.&lt;br /&gt;
  level &amp;gt;= 2 then long warnings are logged when receiving bad input data.&lt;br /&gt;
  level &amp;gt;= 3 then short notices about all incoming non-poll HTTP requests are logged.&lt;br /&gt;
  level &amp;gt;= 4 then the time taken to fulfill the request is logged.&lt;br /&gt;
  level &amp;gt;= 5 then a sample from the beginning of the data is logged.&lt;br /&gt;
  level &amp;gt;= 6 then the entire data is logged.&lt;br /&gt;
  no level is specified then the current level is returned.&lt;br /&gt;
&lt;br /&gt;
If out or all and&lt;br /&gt;
  level &amp;gt;= 3 then short notices about all outgoing requests going through WebUtil are logged.&lt;br /&gt;
  level &amp;gt;= 4 then the time taken to fulfill the request is logged.&lt;br /&gt;
  level &amp;gt;= 5 then a sample from the beginning of the data is logged.&lt;br /&gt;
  level &amp;gt;= 6 then the entire data is logged.&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In particular, to get a good idea of the communications turn on debug level 5 on both the simulator and Robust to see short snippets from each request and response.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/General-Purpose_Threadpool</id>
		<title>General-Purpose Threadpool</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/General-Purpose_Threadpool"/>
				<updated>2014-03-25T07:30:35Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Overview=&lt;br /&gt;
&lt;br /&gt;
A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. This threadpool is managed in Util.cs.&lt;br /&gt;
&lt;br /&gt;
Tasks are added to the threadpool by calling &amp;lt;code&amp;gt;Util.FireAndForget(function)&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=Logging Activity=&lt;br /&gt;
&lt;br /&gt;
There's a console command that enables logging of the tasks in the threadpool. When this option is enabled, the following events are logged:&lt;br /&gt;
&lt;br /&gt;
* Task queued (added to the threadpool)&lt;br /&gt;
* Task started running&lt;br /&gt;
* Task finished running&lt;br /&gt;
* Task timed-out and was terminated&lt;br /&gt;
&lt;br /&gt;
Each time these events are logged, we also log the number of Queued and Running tasks. This shows how busy OpenSim is.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To enable or disable logging, run from the console:&lt;br /&gt;
&lt;br /&gt;
 debug threadpool level &amp;lt;num&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
There are 4 logging levels:&lt;br /&gt;
&lt;br /&gt;
'''0 = no logging (default)''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Turns off logging.&lt;br /&gt;
&lt;br /&gt;
'''1 = only first line of stack trace; don't log common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Short logging. Instead of logging the full stack trace where the task was queued, this only logs the first line of the stack trace. This doesn't log common tasks such as BeginFireQueueEmpty, since they tend to fill up the log quickly.&lt;br /&gt;
&lt;br /&gt;
'''2 = full stack trace; don't log common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Logs the full stack trace where the task was queued. Still doesn't log common tasks.&lt;br /&gt;
&lt;br /&gt;
'''3 = full stack trace, including common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Logs everything.&lt;br /&gt;
&lt;br /&gt;
== Overload Mode ==&lt;br /&gt;
&lt;br /&gt;
When the threadpool is close to full, we enter &amp;quot;Overload Mode&amp;quot;. In that mode we start logging threadpool activity even if the log level is 0. This is useful when running OpenSim in production, as it means that the log level can be kept at 0, yet we still get useful diagnostic information in case OpenSim becomes overloaded, which can help us find the cause of the overload.&lt;br /&gt;
&lt;br /&gt;
== Sample Logging Output ==&lt;br /&gt;
&lt;br /&gt;
'''Level 1'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre style=&amp;quot;white-space: pre-wrap; word-wrap: break-word;&amp;quot;&amp;gt;&lt;br /&gt;
2014-03-25 08:50:39,403 DEBUG - OpenSim.Framework.Util Queue threadfunc 32 (Queued 1, Running 0) at OpenSim.Region.ClientStack.LindenUDP.LLClientView.SendWindData(Vector2[] windSpeeds) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 1292&lt;br /&gt;
2014-03-25 08:50:39,406 DEBUG - OpenSim.Framework.Util Run threadfunc 32 (Queued 0, Running 1)&lt;br /&gt;
2014-03-25 08:50:39,409 DEBUG - OpenSim.Framework.Util Exit threadfunc 32 (0 ms)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Levels 2-3'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre style=&amp;quot;white-space: pre-wrap; word-wrap: break-word;&amp;quot;&amp;gt;&lt;br /&gt;
2014-03-25 08:50:52,118 DEBUG - OpenSim.Framework.Util Queue threadfunc 33 (Queued 1, Running 0) at OpenSim.Region.Framework.Scenes.ScenePresence.SendScriptEventToAttachments(String eventName, Object[] args) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 4283&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.Animation.ScenePresenceAnimator.TrySetMovementAnimation(String anim) in c:\opensim\OpenSim\Region\Framework\Scenes\Animation\ScenePresenceAnimator.cs:line 190&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.Animation.ScenePresenceAnimator.UpdateMovementAnimations() in c:\opensim\OpenSim\Region\Framework\Scenes\Animation\ScenePresenceAnimator.cs:line 461&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.ScenePresence.AddNewMovement(Vector3 vec, Single thisAddSpeedModifier) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 3060&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.ScenePresence.HandleAgentUpdate(IClientAPI remoteClient, AgentUpdateArgs agentData) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 2154&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.HandleAgentUpdate(IClientAPI sener, Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 5778&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.ProcessPacketMethod(Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 707&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.ProcessInPacket(Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 12372&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.ProcessInPacket(IncomingPacket incomingPacket) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 2265&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.IncomingPacketHandler() in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 1990&lt;br /&gt;
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)&lt;br /&gt;
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)&lt;br /&gt;
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)&lt;br /&gt;
   at System.Threading.ThreadHelper.ThreadStart()&lt;br /&gt;
2014-03-25 08:50:52,126 DEBUG - OpenSim.Framework.Util Run threadfunc 33 (Queued 0, Running 1)&lt;br /&gt;
2014-03-25 08:50:52,129 DEBUG - OpenSim.Framework.Util Exit threadfunc 33 (0 ms)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Terminating Hung Threads=&lt;br /&gt;
&lt;br /&gt;
This threadpool has a watchdog timer, which terminates threads if they've been running for over a minute. This prevents exhaustion of the threadpool due to threads that are hung.&lt;br /&gt;
&lt;br /&gt;
On Windows (using .NET), OpenSim will even log a stack trace of the point where the thread was hung. Unfortunately this isn't possible when using Mono.&lt;br /&gt;
&lt;br /&gt;
Tasks that might actually run longer than a minute should not be run on the threadpool. There's a different utility method for running such tasks: &amp;lt;code&amp;gt;Util.RunThreadNoTimeout()&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/General-Purpose_Threadpool</id>
		<title>General-Purpose Threadpool</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/General-Purpose_Threadpool"/>
				<updated>2014-03-25T07:28:19Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Overview=&lt;br /&gt;
&lt;br /&gt;
A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. This threadpool is managed in Util.cs.&lt;br /&gt;
&lt;br /&gt;
Tasks are added to the threadpool by calling &amp;lt;code&amp;gt;Util.FireAndForget(function)&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=Logging Activity=&lt;br /&gt;
&lt;br /&gt;
There's a console command that enables logging of the tasks in the threadpool. When this option is enabled, the following events are logged:&lt;br /&gt;
&lt;br /&gt;
* Task queued (added to the threadpool)&lt;br /&gt;
* Task started running&lt;br /&gt;
* Task finished running&lt;br /&gt;
* Task timed-out and was terminated&lt;br /&gt;
&lt;br /&gt;
Each time these events are logged, we also log the number of Queued and Running tasks. This shows how busy OpenSim is.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To enable or disable logging, run from the console:&lt;br /&gt;
&lt;br /&gt;
 debug threadpool level &amp;lt;num&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
There are 4 logging levels:&lt;br /&gt;
&lt;br /&gt;
'''0 = no logging (default)''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Turns off logging.&lt;br /&gt;
&lt;br /&gt;
'''1 = only first line of stack trace; don't log common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Short logging. Instead of logging the full stack trace where the task was queued, this only logs the first line of the stack trace. This doesn't log common tasks such as BeginFireQueueEmpty, since they tend to fill up the log quickly.&lt;br /&gt;
&lt;br /&gt;
'''2 = full stack trace; don't log common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Logs the full stack trace where the task was queued. Still doesn't log common tasks.&lt;br /&gt;
&lt;br /&gt;
'''3 = full stack trace, including common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Logs everything.&lt;br /&gt;
&lt;br /&gt;
== Sample Logging Output ==&lt;br /&gt;
&lt;br /&gt;
'''Level 1'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre style=&amp;quot;white-space: pre-wrap; word-wrap: break-word;&amp;quot;&amp;gt;&lt;br /&gt;
2014-03-25 08:50:39,403 DEBUG - OpenSim.Framework.Util Queue threadfunc 32 (Queued 1, Running 0) at OpenSim.Region.ClientStack.LindenUDP.LLClientView.SendWindData(Vector2[] windSpeeds) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 1292&lt;br /&gt;
2014-03-25 08:50:39,406 DEBUG - OpenSim.Framework.Util Run threadfunc 32 (Queued 0, Running 1)&lt;br /&gt;
2014-03-25 08:50:39,409 DEBUG - OpenSim.Framework.Util Exit threadfunc 32 (0 ms)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Levels 2-3'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre style=&amp;quot;white-space: pre-wrap; word-wrap: break-word;&amp;quot;&amp;gt;&lt;br /&gt;
2014-03-25 08:50:52,118 DEBUG - OpenSim.Framework.Util Queue threadfunc 33 (Queued 1, Running 0) at OpenSim.Region.Framework.Scenes.ScenePresence.SendScriptEventToAttachments(String eventName, Object[] args) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 4283&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.Animation.ScenePresenceAnimator.TrySetMovementAnimation(String anim) in c:\opensim\OpenSim\Region\Framework\Scenes\Animation\ScenePresenceAnimator.cs:line 190&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.Animation.ScenePresenceAnimator.UpdateMovementAnimations() in c:\opensim\OpenSim\Region\Framework\Scenes\Animation\ScenePresenceAnimator.cs:line 461&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.ScenePresence.AddNewMovement(Vector3 vec, Single thisAddSpeedModifier) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 3060&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.ScenePresence.HandleAgentUpdate(IClientAPI remoteClient, AgentUpdateArgs agentData) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 2154&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.HandleAgentUpdate(IClientAPI sener, Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 5778&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.ProcessPacketMethod(Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 707&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.ProcessInPacket(Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 12372&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.ProcessInPacket(IncomingPacket incomingPacket) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 2265&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.IncomingPacketHandler() in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 1990&lt;br /&gt;
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)&lt;br /&gt;
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)&lt;br /&gt;
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)&lt;br /&gt;
   at System.Threading.ThreadHelper.ThreadStart()&lt;br /&gt;
2014-03-25 08:50:52,126 DEBUG - OpenSim.Framework.Util Run threadfunc 33 (Queued 0, Running 1)&lt;br /&gt;
2014-03-25 08:50:52,129 DEBUG - OpenSim.Framework.Util Exit threadfunc 33 (0 ms)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Terminating Hung Threads=&lt;br /&gt;
&lt;br /&gt;
This threadpool has a watchdog timer, which terminates threads if they've been running for over a minute. This prevents exhaustion of the threadpool due to threads that are hung.&lt;br /&gt;
&lt;br /&gt;
On Windows (using .NET), OpenSim will even log a stack trace of the point where the thread was hung. Unfortunately this isn't possible when using Mono.&lt;br /&gt;
&lt;br /&gt;
Tasks that might actually run longer than a minute should not be run on the threadpool. There's a different utility method for running such tasks: &amp;lt;code&amp;gt;Util.RunThreadNoTimeout()&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/General-Purpose_Threadpool</id>
		<title>General-Purpose Threadpool</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/General-Purpose_Threadpool"/>
				<updated>2014-03-25T07:25:56Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Created page with &amp;quot;*=Overview=  A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. This threadpool is managed in Util.cs.  Tasks are added to the threadp...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;*=Overview=&lt;br /&gt;
&lt;br /&gt;
A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. This threadpool is managed in Util.cs.&lt;br /&gt;
&lt;br /&gt;
Tasks are added to the threadpool by calling &amp;lt;code&amp;gt;Util.FireAndForget(function)&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=Logging Activity=&lt;br /&gt;
&lt;br /&gt;
There's a console command that enables logging of the tasks in the threadpool. When this option is enabled, the following events are logged:&lt;br /&gt;
&lt;br /&gt;
* Task queued (added to the threadpool)&lt;br /&gt;
* Task started running&lt;br /&gt;
* Task finished running&lt;br /&gt;
* Task timed-out and was terminated&lt;br /&gt;
&lt;br /&gt;
Each time these events are logged, we also log the number of Queued and Running tasks. This shows how busy OpenSim is.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To enable or disable logging, run from the console:&lt;br /&gt;
&lt;br /&gt;
 debug threadpool level &amp;lt;num&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
There are 4 logging levels:&lt;br /&gt;
&lt;br /&gt;
'''0 = no logging (default)''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Turns off logging.&lt;br /&gt;
&lt;br /&gt;
'''1 = only first line of stack trace; don't log common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Short logging. Instead of logging the full stack trace where the task was queued, this only logs the first line of the stack trace. This doesn't log common tasks such as BeginFireQueueEmpty, since they tend to fill up the log quickly.&lt;br /&gt;
&lt;br /&gt;
'''2 = full stack trace; don't log common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Logs the full stack trace where the task was queued. Still doesn't log common tasks.&lt;br /&gt;
&lt;br /&gt;
'''3 = full stack trace, including common threads''' &amp;lt;br/&amp;gt;&lt;br /&gt;
Logs everything.&lt;br /&gt;
&lt;br /&gt;
== Sample Logging Output ==&lt;br /&gt;
&lt;br /&gt;
'''Level 1'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre style=&amp;quot;white-space: pre-wrap; word-wrap: break-word;&amp;quot;&amp;gt;&lt;br /&gt;
2014-03-25 08:50:39,403 DEBUG - OpenSim.Framework.Util Queue threadfunc 32 (Queued 1, Running 0) at OpenSim.Region.ClientStack.LindenUDP.LLClientView.SendWindData(Vector2[] windSpeeds) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 1292&lt;br /&gt;
2014-03-25 08:50:39,406 DEBUG - OpenSim.Framework.Util Run threadfunc 32 (Queued 0, Running 1)&lt;br /&gt;
2014-03-25 08:50:39,409 DEBUG - OpenSim.Framework.Util Exit threadfunc 32 (0 ms)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Levels 2-3'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre style=&amp;quot;white-space: pre-wrap; word-wrap: break-word;&amp;quot;&amp;gt;&lt;br /&gt;
2014-03-25 08:50:52,118 DEBUG - OpenSim.Framework.Util Queue threadfunc 33 (Queued 1, Running 0) at OpenSim.Region.Framework.Scenes.ScenePresence.SendScriptEventToAttachments(String eventName, Object[] args) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 4283&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.Animation.ScenePresenceAnimator.TrySetMovementAnimation(String anim) in c:\opensim\OpenSim\Region\Framework\Scenes\Animation\ScenePresenceAnimator.cs:line 190&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.Animation.ScenePresenceAnimator.UpdateMovementAnimations() in c:\opensim\OpenSim\Region\Framework\Scenes\Animation\ScenePresenceAnimator.cs:line 461&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.ScenePresence.AddNewMovement(Vector3 vec, Single thisAddSpeedModifier) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 3060&lt;br /&gt;
   at OpenSim.Region.Framework.Scenes.ScenePresence.HandleAgentUpdate(IClientAPI remoteClient, AgentUpdateArgs agentData) in c:\opensim\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 2154&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.HandleAgentUpdate(IClientAPI sener, Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 5778&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.ProcessPacketMethod(Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 707&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.ProcessInPacket(Packet packet) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 12372&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.ProcessInPacket(IncomingPacket incomingPacket) in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 2265&lt;br /&gt;
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.IncomingPacketHandler() in c:\opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 1990&lt;br /&gt;
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)&lt;br /&gt;
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)&lt;br /&gt;
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)&lt;br /&gt;
   at System.Threading.ThreadHelper.ThreadStart()&lt;br /&gt;
2014-03-25 08:50:52,126 DEBUG - OpenSim.Framework.Util Run threadfunc 33 (Queued 0, Running 1)&lt;br /&gt;
2014-03-25 08:50:52,129 DEBUG - OpenSim.Framework.Util Exit threadfunc 33 (0 ms)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Debugging</id>
		<title>Debugging</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Debugging"/>
				<updated>2014-03-25T07:08:51Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Specific areas */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=General=&lt;br /&gt;
&lt;br /&gt;
In general, OpenSimulator is a difficult system to debug due to its high concurrency, complexity and the lack of good tools for Mono on the Linux/Mac side.  We won't go through general information about using debuggers here, you can find it elsewhere on the net.  However, one thing to note is that the debugger must be capable of ignoring the SelfDeleteException - this is currently used by the XEngine script engine to kill scripts aborted via the llDie() LSL command.&lt;br /&gt;
&lt;br /&gt;
=Internal tools=&lt;br /&gt;
&lt;br /&gt;
There are also logging statements through the OpenSimulator code, some of which are commented out.  Generally these can be uncommented to provide extra useful information, though you may have to resort to adding new log statements.&lt;br /&gt;
&lt;br /&gt;
There are also some internal methods that might be useful.&lt;br /&gt;
&lt;br /&gt;
* Util.PrintCallStack() - This will print the call stack at the time the method is executed before continuing execution.  Unfortunately, due to Mono limitations can only work on the current thread.&lt;br /&gt;
&lt;br /&gt;
=Specific areas=&lt;br /&gt;
However, there are a few things we say about debugging specific OpenSimulator issues.  This section will be expanded as time goes on.&lt;br /&gt;
&lt;br /&gt;
== Initial connection ==&lt;br /&gt;
This trips people up a lot because of the complex interplay between different server processes in grid mode and between simulator and viewer, with viewers on both the local LAN and over the Internet.  Problems here are generally due to configuration rather than OpenSimulator code issues.  See [[Troubleshooting]] for more details.&lt;br /&gt;
&lt;br /&gt;
== Problems after connection established ==&lt;br /&gt;
Here are some commands that can help you get more information is you have problems when a connection has already been established (e.g. avatars stopping in place), etc.  You can get more help on any of these commands by typing &amp;quot;help &amp;lt;command-name&amp;gt;&amp;quot; on the simulator console.&lt;br /&gt;
&lt;br /&gt;
* debug packet &amp;lt;0-256&amp;gt; [&amp;lt;first-name&amp;gt;] [&amp;lt;last-name&amp;gt;] - this command logs various incoming and outgoing packets depending on the packet level (0-256).  This can help determine whether there is any packet flow between simulator and client at all.&lt;br /&gt;
&lt;br /&gt;
* show queues [&amp;lt;full&amp;gt;] - this command shows packet in, out and resent statistics for particular clients, as well as the packets being queued.  Monitoring the in and outbound packet numbers will show if packets are getting through between simulator and viewer.  If resent is climbing rapidly then its likely you have connection issues since the simulator is having to resend lots of packets that aren't being acknowledged by the viewer.  If the Q numbers increase without going down then clients may have extremely small bandwidth limits or the outgoing network connection from the simulator may be overwhelmed.&lt;br /&gt;
&lt;br /&gt;
* show users - show users active on the simulator&lt;br /&gt;
&lt;br /&gt;
* show connections - show information about individual client connections, including their IP address and whether they are active (in OpenSimulator 0.7.4 dev code only).&lt;br /&gt;
&lt;br /&gt;
== Threadpool Activity ==&lt;br /&gt;
&lt;br /&gt;
A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. You can [[General-Purpose Threadpool|enable logging that shows activity in this threadpool]].&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Development_Team</id>
		<title>Development Team</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Development_Team"/>
				<updated>2014-03-22T08:03:37Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Active Core Developers */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__ {{Quicklinks}} &lt;br /&gt;
&lt;br /&gt;
== Active Core Developers ==&lt;br /&gt;
&lt;br /&gt;
Developers who have commit access to our central server, are [http://www.ohloh.net/projects/4753/contributors regular contributors] to the codebase, and have voting rights over development and process issues of the OpenSimulator project. See [[Organization]]. &lt;br /&gt;
&lt;br /&gt;
* '''Only voted in developers are listed here, please do not list yourself'''&lt;br /&gt;
&lt;br /&gt;
{| cellspacing=&amp;quot;0&amp;quot; cellpadding=&amp;quot;2&amp;quot; border=&amp;quot;1&amp;quot; class=&amp;quot;sortable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! IRC Nick &lt;br /&gt;
! Name &lt;br /&gt;
! SL Avatar &lt;br /&gt;
! Other Grid &lt;br /&gt;
! Time Zone&amp;lt;br /&amp;gt;(UTC) &lt;br /&gt;
! Org &lt;br /&gt;
! Areas of Interest&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Adam Frisby|Adam Frisby]] &lt;br /&gt;
| Adam Frisby &lt;br /&gt;
| Adam Zaius &lt;br /&gt;
| &lt;br /&gt;
| +8 &lt;br /&gt;
| DeepThink Pty Ltd &lt;br /&gt;
| Terrain, Performance&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Justincc|justincc]] &lt;br /&gt;
| Justin Clark-Casey &lt;br /&gt;
| Lulworth Beaumont &lt;br /&gt;
| Justin Clark-Casey (all other grids) &lt;br /&gt;
| 0 &lt;br /&gt;
| OSVW Consulting&amp;lt;br /&amp;gt;[http://justincc.org/blog justincc's OpenSimulator blog] &lt;br /&gt;
| Grid, performance &amp;amp;amp; reliability, inventory (avatar and object), assets, scenes, OARs, etc. Generally speaking, my main interest is to create infrastructure that other people can build on top of.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Dahlia|dahlia]] &lt;br /&gt;
| T. Hoff &lt;br /&gt;
| Dahlia Trimble &lt;br /&gt;
| &lt;br /&gt;
| -8 / -7 &lt;br /&gt;
| Independent &lt;br /&gt;
| Collision geometry, various math and physics issues, occasional bug fixes and random enhancements&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Melanie T|Melanie_T]] &lt;br /&gt;
| Melanie &lt;br /&gt;
| Melanie Milland &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +1 &lt;br /&gt;
| Independent &lt;br /&gt;
| Scripting, Prims/Scene, Life, The Universe, and Everything&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Diva|Diva]] &lt;br /&gt;
| Crista Lopes &lt;br /&gt;
| Diva Canto &lt;br /&gt;
| Crista Lopes / Diva Canto &lt;br /&gt;
| -8 &lt;br /&gt;
| University of California, Irvine &lt;br /&gt;
| Everything, except databases&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Dslake|dslake]] &lt;br /&gt;
| Dan Lake &lt;br /&gt;
| Dan Lake &lt;br /&gt;
| ScienceSim &lt;br /&gt;
| -8 / -7 &lt;br /&gt;
| Intel &lt;br /&gt;
| Scalability, Performance, Network stack&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| cmickeyb &lt;br /&gt;
| Mic Bowman &lt;br /&gt;
| Mic Bowman &lt;br /&gt;
| ScienceSim &lt;br /&gt;
| -8 / -7 &lt;br /&gt;
| Intel &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| [[User:BlueWall|BlueWall]] &lt;br /&gt;
| James Hughes &lt;br /&gt;
| BlueWall Slade &lt;br /&gt;
| BlueWall Slade &lt;br /&gt;
| -5 &lt;br /&gt;
| BlueWall Information Technologies, LLC &lt;br /&gt;
| Various parts&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Nebadon|Nebadon]] &lt;br /&gt;
| Michael Emory Cerquoni &lt;br /&gt;
| Nebadon Izumi &lt;br /&gt;
| Nebadon Izumi &lt;br /&gt;
| -7 Arizona &lt;br /&gt;
| Oni Kenkon Creations &lt;br /&gt;
| Building, Scripting, Testing&lt;br /&gt;
|-&lt;br /&gt;
| radams&lt;br /&gt;
| Robert Adams&lt;br /&gt;
|  &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| Looking Glass Viewer &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| orenh&lt;br /&gt;
| Oren Hurvitz&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
| +2&lt;br /&gt;
| Kitely&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| kcozens&lt;br /&gt;
| aka Plugh (on IRC)&lt;br /&gt;
| Andrew Hellershanks&lt;br /&gt;
| Andrew Hellershanks&lt;br /&gt;
| -5&lt;br /&gt;
| &lt;br /&gt;
| Building, Scripting&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Core Developers Following the White Rabbit ==&lt;br /&gt;
&lt;br /&gt;
Core developers who have temporarily (we hope) gone chasing the white rabbit. They are in all similar to the active core developers, except that they haven't been that active lately, so their voting rights are awaiting their come back. &lt;br /&gt;
&lt;br /&gt;
* '''Only voted in developers are listed here, please do not list yourself'''&lt;br /&gt;
&lt;br /&gt;
{| cellspacing=&amp;quot;0&amp;quot; cellpadding=&amp;quot;2&amp;quot; border=&amp;quot;1&amp;quot; class=&amp;quot;sortable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! IRC Nick &lt;br /&gt;
! Name &lt;br /&gt;
! SL Avatar &lt;br /&gt;
! Other Grid &lt;br /&gt;
! Time Zone&amp;lt;br /&amp;gt;(UTC) &lt;br /&gt;
! Org &lt;br /&gt;
! Areas of Interest&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Lbsa71|lbsa71]] &lt;br /&gt;
| Stefan Andersson &lt;br /&gt;
| Tribal Skytower &lt;br /&gt;
| OSG:Stefan Andersson&amp;lt;br /&amp;gt;TN:Stefan Andersson &lt;br /&gt;
| +1 &lt;br /&gt;
| [http://tribalmedia.se/ Tribal Media AB] &lt;br /&gt;
| Web Integration&lt;br /&gt;
|-&lt;br /&gt;
| [[User:MW|MW]] &lt;br /&gt;
| Darren &lt;br /&gt;
| Wright Juran &lt;br /&gt;
| &lt;br /&gt;
| 0 &lt;br /&gt;
| &lt;br /&gt;
| Everything&lt;br /&gt;
|-&lt;br /&gt;
| ckrinke &lt;br /&gt;
| Charles&amp;amp;nbsp;Krinke &lt;br /&gt;
| Charlesk&amp;amp;nbsp;Bing &lt;br /&gt;
| &lt;br /&gt;
| -8 &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Reliability/Grid servers/ll-functions&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Mikem|mikem]] &lt;br /&gt;
| Mike Mazur &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +9 &lt;br /&gt;
| Independent &lt;br /&gt;
| Patches, scripting improvements, LSL compiler&lt;br /&gt;
|-&lt;br /&gt;
| [[User:HomerHorwitz|homerh]] &lt;br /&gt;
| Homer Horwitz &lt;br /&gt;
| Homer Horwitz &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +2 &lt;br /&gt;
| Independent &lt;br /&gt;
| Rev. engineering, &amp;quot;now, that's funny&amp;quot; problems, but still interested in all parts of it&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Nlin|nlin]] &lt;br /&gt;
| N Lin &lt;br /&gt;
| Standard Drucker &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +9 &lt;br /&gt;
| [http://www.3di.jp/en/ 3Di Inc, Japan]&amp;lt;br /&amp;gt;http://www.3di.jp/en/ &lt;br /&gt;
| Physics, scripting, more to come&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Arthursv|arthursv]] &lt;br /&gt;
| Arthur Valadares &lt;br /&gt;
| &lt;br /&gt;
| NONE &lt;br /&gt;
| -8 &lt;br /&gt;
| University of California, Irvine &lt;br /&gt;
| Unit testing, database plugins, bug fixes, general&lt;br /&gt;
|-&lt;br /&gt;
| [[User:DrScofield|drscofld]] &lt;br /&gt;
| Dirk Husemann &lt;br /&gt;
| Dr Scofield &lt;br /&gt;
| &lt;br /&gt;
| +1 &lt;br /&gt;
| [http://xyzzyxyzzy.net/ xyzzyxyzzy.net] &lt;br /&gt;
| Reliability, networking protocols, inventory, assets, remote control, voice, and pretty much everything else&amp;amp;nbsp;:-) &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| [[User:Teravus|Teravus]] &lt;br /&gt;
| Daniel Olivares &lt;br /&gt;
| Teravus Ousley &lt;br /&gt;
| &lt;br /&gt;
| -5 &lt;br /&gt;
| W3z &lt;br /&gt;
| Physics &amp;amp;amp; Admin tools, A working sim.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Chi11ken|chi11ken]] &lt;br /&gt;
| Jeff Ames &lt;br /&gt;
| Chillken Proto &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +9 &lt;br /&gt;
| [http://www.genkii.com Genkii] &lt;br /&gt;
| &amp;lt;br /&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Marck|Marck00]] &lt;br /&gt;
| M. Kirsch &lt;br /&gt;
| Marck Kjeller &lt;br /&gt;
| &lt;br /&gt;
| +1 &lt;br /&gt;
| Independent &lt;br /&gt;
| Everything that catches my attention and that I can get my head around. &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| [[User:Snoopy2|Snoopy2]] &lt;br /&gt;
| Snoopy Pfeffer &lt;br /&gt;
| Snoopy Pfeffer &lt;br /&gt;
| Snoopy Pfeffer &lt;br /&gt;
|&lt;br /&gt;
| [http://www.dreamlandmetaverse.com/ http://www.dreamlandmetaverse.com/] &lt;br /&gt;
| OpenSim region and grid hosting&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Retired Core Developers ==&lt;br /&gt;
&lt;br /&gt;
Core developers who have transcended our mortal plane, i.e. they are no longer directly engaged with the project. Thank you forever for your contributions! &lt;br /&gt;
&lt;br /&gt;
* '''Only formerly voted in developers are listed here, please do not list yourself'''&lt;br /&gt;
&lt;br /&gt;
{| cellspacing=&amp;quot;0&amp;quot; cellpadding=&amp;quot;2&amp;quot; border=&amp;quot;1&amp;quot; class=&amp;quot;sortable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! IRC Nick &lt;br /&gt;
! Name &lt;br /&gt;
! SL Avatar &lt;br /&gt;
! Other Grid &lt;br /&gt;
! Time Zone&amp;lt;br /&amp;gt;(UTC) &lt;br /&gt;
! Org &lt;br /&gt;
! Areas of Interest&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Babblefrog|babblefrog]] &lt;br /&gt;
| Brian McBee &lt;br /&gt;
| Dogen Coldstream &lt;br /&gt;
| Babblefrog Ballistic (osgrid) &lt;br /&gt;
| -8 &lt;br /&gt;
| Disorganized &lt;br /&gt;
| &amp;amp;nbsp;&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Danx0r|danx0r]] &lt;br /&gt;
| Dan Miller &lt;br /&gt;
| Albert Pascal &lt;br /&gt;
| &lt;br /&gt;
| -8 &lt;br /&gt;
| squiggle.com &lt;br /&gt;
| PHEEZIKS; everything&lt;br /&gt;
|-&lt;br /&gt;
| Tleiades &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Tleiades&amp;amp;nbsp;Hax &lt;br /&gt;
| &lt;br /&gt;
| +1 &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Grid servers/Database&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Darok|Darok]] &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Darok Kaminski &lt;br /&gt;
| &lt;br /&gt;
| +1 &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Physics engines (especially BulletX)&lt;br /&gt;
|-&lt;br /&gt;
| Gareth / Gwen &lt;br /&gt;
| Gareth Nelson &lt;br /&gt;
| Gareth Ellison &lt;br /&gt;
| Gareth Nelson (on everywhere but SL) &lt;br /&gt;
| BST (UTC+1) &lt;br /&gt;
| Litesim Ltd &lt;br /&gt;
| Grid servers, sim border crossing, avatar animations&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Dalien|dalien]] &lt;br /&gt;
| Dalien Talbot &lt;br /&gt;
| Dalien Talbot &lt;br /&gt;
| &lt;br /&gt;
| +1 &lt;br /&gt;
| Mostly TCP-based &lt;br /&gt;
| Small fixes; rev.eng./prototyping; nightlies; git-keeper&lt;br /&gt;
|-&lt;br /&gt;
| [[Alondria]] &lt;br /&gt;
| &lt;br /&gt;
| Alondria LeFay &lt;br /&gt;
| Alondria LeFay (OSGrid) &lt;br /&gt;
| -8 &lt;br /&gt;
| Independent &lt;br /&gt;
| Implementation of LSL functions and other scripting tidbits.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:SeanDague|sdague]] &lt;br /&gt;
| Sean Dague &lt;br /&gt;
| Neas Bade &lt;br /&gt;
| &lt;br /&gt;
| -5 &lt;br /&gt;
| IBM &lt;br /&gt;
| Database, Linux, Testing, Misc&lt;br /&gt;
|-&lt;br /&gt;
| [[User:MingChen|MingChen]] &lt;br /&gt;
| Mike/Michael Ortman &lt;br /&gt;
| Ming Chen &lt;br /&gt;
| &lt;br /&gt;
| -6 (-5 in Summer) &lt;br /&gt;
| DeepThink Pty Ltd &lt;br /&gt;
| Estate/Parcel Support/Modules/Keeping things all neat and tidy.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Tedd|Tedd]] &lt;br /&gt;
| Tedd Hansen &lt;br /&gt;
| Tedd Maa &lt;br /&gt;
| &lt;br /&gt;
| +1 &lt;br /&gt;
| Tedd Hansen &lt;br /&gt;
| Programming/Scripting/Architecture&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Adjohn|adjohn]] &lt;br /&gt;
| Adam Johnson &lt;br /&gt;
| Zeuz Zenovka &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +9 &lt;br /&gt;
| [http://www.genkii.com Genkii] &lt;br /&gt;
| &amp;lt;br /&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Joha1|joha1]] &lt;br /&gt;
| Johan Berntsson &lt;br /&gt;
| Joppi Brandenburg &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +9 &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Performance, packet handling/libSL&lt;br /&gt;
|-&lt;br /&gt;
| jhurliman &lt;br /&gt;
| John Hurliman &lt;br /&gt;
| John Hurliman &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Wiki Sysops ==&lt;br /&gt;
&lt;br /&gt;
Along with the core developers, these people help manage the OpenSimulator wiki as well as make other contributions (see Areas of Interest). &lt;br /&gt;
&lt;br /&gt;
{| cellspacing=&amp;quot;0&amp;quot; cellpadding=&amp;quot;2&amp;quot; border=&amp;quot;1&amp;quot; class=&amp;quot;sortable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! IRC Nick &lt;br /&gt;
! Name &lt;br /&gt;
! SL Avatar &lt;br /&gt;
! Other Grid &lt;br /&gt;
! Time Zone&amp;lt;br /&amp;gt;(UTC) &lt;br /&gt;
! Org &lt;br /&gt;
! Areas of Interest&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Makopoppo|Makopoppo]] &lt;br /&gt;
| Makiko Nomura &lt;br /&gt;
| Mako Nozaki &lt;br /&gt;
| Everywhere &lt;br /&gt;
| +9 Tokyo, Japan &lt;br /&gt;
| As an individual developer &lt;br /&gt;
| Everything for improving usability and connectability - wiki/issue management, documentation, localization(Japanese), modifying the interface mainly of core modules&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Fritigern|Fritigern]] &lt;br /&gt;
| S-E-C-R-E-T &lt;br /&gt;
| Fritigern Gothly &lt;br /&gt;
| SecondLife, OSGrid &lt;br /&gt;
| +1 GMT &lt;br /&gt;
| &lt;br /&gt;
| My interests are many, and extremely varied. One thing that i am very interested in, is seeing OpenSimulator grow, mature, and develop into something that really does rival SL/LL.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Additional Developers/Testers/Contributors ==&lt;br /&gt;
&lt;br /&gt;
These people have contributed and/or are contributing bug reports, patches, testing, and all sorts of other goodies to the project. &amp;lt;br /&amp;gt; '''Newcomers please add yourself to bottom of the list!''' &amp;lt;br /&amp;gt; &lt;br /&gt;
&lt;br /&gt;
{| cellspacing=&amp;quot;0&amp;quot; cellpadding=&amp;quot;2&amp;quot; border=&amp;quot;1&amp;quot; class=&amp;quot;sortable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! IRC Nick &lt;br /&gt;
! Name &lt;br /&gt;
! SL Avatar &lt;br /&gt;
! Other Grid &lt;br /&gt;
! Time Zone&amp;lt;br /&amp;gt;(UTC) &lt;br /&gt;
! Org &lt;br /&gt;
! Areas of Interest&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Jtclark48|jclark4]] &lt;br /&gt;
| Jay Clark &lt;br /&gt;
| Jay Clarke &lt;br /&gt;
| &lt;br /&gt;
| -5 &lt;br /&gt;
| IBM &lt;br /&gt;
| Physics, Grid Host, AI, Scripting, Testing&lt;br /&gt;
|-&lt;br /&gt;
| [[User:AdamStevenson|BigFootAg]] &lt;br /&gt;
| Adam Stevenson &lt;br /&gt;
| Adamus Petrov &lt;br /&gt;
| &lt;br /&gt;
| -6 &lt;br /&gt;
| Texas A&amp;amp;amp;M University &lt;br /&gt;
| AI, Skynet, Evolving Systems, Biology&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Jeff1564|Jeff1564]] &lt;br /&gt;
| Jeff &lt;br /&gt;
| Potter Taurog &lt;br /&gt;
| Potter Taurog &lt;br /&gt;
| -8 &lt;br /&gt;
| http://myopengrid.com &lt;br /&gt;
| Building, Scripting, Testing&lt;br /&gt;
|-&lt;br /&gt;
| Rock_Vacirca &lt;br /&gt;
| Colin Withers &lt;br /&gt;
| Rock Vacirca &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| +1 &lt;br /&gt;
| http://rock-vacirca.blogspot.com &lt;br /&gt;
| Testing, building, scripting, maintaining an opensim blog.&lt;br /&gt;
|-&lt;br /&gt;
| simsim &lt;br /&gt;
| caocao &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| +9 &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Testing whole functions of OpenSimulator system,working with OpenSim-Engine,reporting on OpenSimulator&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Vicero Lambert|Vicero Lambert]] &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| &amp;amp;nbsp;&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Magi|Magi]] &lt;br /&gt;
| Andy Agnew &lt;br /&gt;
| Magi Merlin &lt;br /&gt;
| &lt;br /&gt;
| +10 &lt;br /&gt;
| Spun Pty Ltd &lt;br /&gt;
| 3D Web Integration, Database stuff and playing with the odds and ends box.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:ClarkZone|ClarkZone]] &lt;br /&gt;
| Troy Admin(@ClarkZone) &lt;br /&gt;
| Troy Childs &lt;br /&gt;
| Troy Admin (ClarkZone) &lt;br /&gt;
| -5 &lt;br /&gt;
| Http://clarkzone.dyndns.org &lt;br /&gt;
| Tester and Grid Host&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Aiaustin|aiaustin]] &lt;br /&gt;
| Ai Austin &lt;br /&gt;
| Ai Austin &lt;br /&gt;
| Ai Austin &lt;br /&gt;
| +0 &lt;br /&gt;
| AIAI, Virtual University of Edinburgh&amp;lt;br /&amp;gt;http://www.aiai.ed.ac.uk/~ai/&amp;lt;br /&amp;gt;http://vue.ed.ac.uk/openvue/ &lt;br /&gt;
| Windows tests&amp;lt;br /&amp;gt;Content testing&amp;lt;br /&amp;gt;Use of multiple VWs&lt;br /&gt;
|-&lt;br /&gt;
| Marc Manders &lt;br /&gt;
| Marc Manders &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| +6 &lt;br /&gt;
| marcmanders@gmail.com &lt;br /&gt;
| Creative features&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Balthazar|balthazar]] &lt;br /&gt;
| Trevor Brooks &lt;br /&gt;
| Balthazar Sin &lt;br /&gt;
| &lt;br /&gt;
| -5 &lt;br /&gt;
| None &lt;br /&gt;
| Terrains, testing and some small coding tasks&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Jimbo2120|jimbo2120]] &lt;br /&gt;
| Michael Osias &lt;br /&gt;
| Illuminous Beltran &lt;br /&gt;
| &lt;br /&gt;
| -5 &lt;br /&gt;
| IBM &lt;br /&gt;
| Grid, AI, Skynet, coding and testing&lt;br /&gt;
|-&lt;br /&gt;
| ZeroPoint &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Guilderoy&amp;amp;nbsp;Dench &lt;br /&gt;
| &lt;br /&gt;
| -5 &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Programming/Database&lt;br /&gt;
|-&lt;br /&gt;
| [[User:DerekTang|DerekTang]] &lt;br /&gt;
| Derek Tang &lt;br /&gt;
| Derek Timeless &lt;br /&gt;
| Derek Tang (ChineseGrid) &lt;br /&gt;
| +8 &lt;br /&gt;
| http://ChineseGrid.net &lt;br /&gt;
| Running a public WINDOWS sim for testing, Docs, Helping Chinese users to enjoy OpenSim; building Chinese OpenSimulator communities. In construction...&lt;br /&gt;
|-&lt;br /&gt;
| [[User:TayB|TayB]] &lt;br /&gt;
| Earl Balai &lt;br /&gt;
| Taylor Dae &lt;br /&gt;
| &lt;br /&gt;
| -10 &lt;br /&gt;
| WhynGrid &lt;br /&gt;
| Grid Host,Networking,Contributions &amp;amp;amp; Testing.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:JamieDav|JamieDav]] &lt;br /&gt;
| Jamie David &lt;br /&gt;
| Jamie David &lt;br /&gt;
| &lt;br /&gt;
| +7 &lt;br /&gt;
| Forum &lt;br /&gt;
| Grid, Sim, Avitar, Functionality&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Krtaylor|Krtaylor]] &lt;br /&gt;
| Kurt Taylor &lt;br /&gt;
| Kurt Stringer &lt;br /&gt;
| &lt;br /&gt;
| -6 &lt;br /&gt;
| IBM &lt;br /&gt;
| Grid, Networking, Monitoring, Scripting, Inventory, Testing&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Nink|Nink]] &lt;br /&gt;
| Peter Finn &lt;br /&gt;
| Nink Noonan &lt;br /&gt;
| &lt;br /&gt;
| -5 &lt;br /&gt;
| IBM &lt;br /&gt;
| Disruptive Influence.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Bruce|Bruce]] &lt;br /&gt;
| Bruce Meerson &lt;br /&gt;
| Bruce Meerson &lt;br /&gt;
| &lt;br /&gt;
| +8 &lt;br /&gt;
| HiPiHi &lt;br /&gt;
| Watching.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Darb|DarbD]] &lt;br /&gt;
| Brian B. Quinn &lt;br /&gt;
| Darb Dabney &lt;br /&gt;
| regions&amp;lt;br /&amp;gt;near Marin &lt;br /&gt;
| PST/SLT (-7 or -8) &lt;br /&gt;
| County of Marin, California&amp;lt;br /&amp;gt; http://blog.3dmap.me &lt;br /&gt;
| LiDAR-based sculpties, real-world terrain, &amp;lt;br /&amp;gt;pursuit of civic paraverses, virtual Emergency Operations Centers&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Charlie Omega|CharlieO]] &lt;br /&gt;
| Dan &lt;br /&gt;
| Charlie Omega &lt;br /&gt;
| &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Mild coding/tweaking/simple feature adds, Stress testing/break stuff, Testing limits of existing code. Making sure [[LSL Status]] is up to date&lt;br /&gt;
|-&lt;br /&gt;
| oobscure &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Opensource Obscure &lt;br /&gt;
| &lt;br /&gt;
| +1 &lt;br /&gt;
| http://www.opensim.it &lt;br /&gt;
| Running a public Linux sim for testing, Docs, Helping italian users, Building opensim communities, Watching&lt;br /&gt;
|-&lt;br /&gt;
| pitman &lt;br /&gt;
| Mike Pitman &lt;br /&gt;
| Rez Tone &lt;br /&gt;
| &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| IBM &lt;br /&gt;
| Scientific visualization schemes, virt world product design, persistant workspaces, virt world based big biz&lt;br /&gt;
|-&lt;br /&gt;
| Shenlei &lt;br /&gt;
| Shenlei Winkler &lt;br /&gt;
| Shenlei Flasheart, Shenlei Winkler &lt;br /&gt;
| &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Fashion Research Institute &lt;br /&gt;
| Product Design and Development, Apparel industry, and o yes, I wrote the book&amp;amp;nbsp;;)&lt;br /&gt;
|-&lt;br /&gt;
| cmu &lt;br /&gt;
| Christopher Mumme &lt;br /&gt;
| Snook Destiny &lt;br /&gt;
| &lt;br /&gt;
| +1 &lt;br /&gt;
| http://www.cmu-develop.de/ and research group &amp;quot;Collaboration Systems and CSCW&amp;quot; at Clausthal University of Technology &lt;br /&gt;
| Testing OpenSim, working with OpenSim-Engine, reporting on OpenSimulator&lt;br /&gt;
|-&lt;br /&gt;
| [[Silpol]] &lt;br /&gt;
| Andriy Tymchenko &lt;br /&gt;
| Andy Tir &lt;br /&gt;
| &lt;br /&gt;
| EET (+2/3) &lt;br /&gt;
| http://silpol.blogspot.com/ (also visible at Nokia) &lt;br /&gt;
| Highly uncoordinated mess with elements of palace games, under-table diplomacy, rebellion, coup d'état and mutiny. optionally pirate&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Grumly|Grumly]] &lt;br /&gt;
| &lt;br /&gt;
| Forest Klaar &lt;br /&gt;
| Grumly TheBear &lt;br /&gt;
| GMT+1 &lt;br /&gt;
| .NET MCAD Dev/Arch/Trainer http://www.devoteam.com &lt;br /&gt;
| Trying to get into OpenSimulator code for now. Particularly interrested in data persistence. blog (Hello, Avatar!): http://lslblog.free.fr&lt;br /&gt;
|-&lt;br /&gt;
| [[User:DaTwitch|DaTwitch]] &lt;br /&gt;
| James G. Stallings II &lt;br /&gt;
| &amp;lt;br /&amp;gt;Lazarus Longstaff &lt;br /&gt;
| Hiro Protagonist (OSGrid) &lt;br /&gt;
| -5 &lt;br /&gt;
| House Husband &lt;br /&gt;
| OSGrid Region owner, OSGrid Operator,&amp;lt;br /&amp;gt;Forum Admin, sometime wiki editor&lt;br /&gt;
|-&lt;br /&gt;
| gryc &lt;br /&gt;
| Gryc Ueusp &lt;br /&gt;
| Gryc Uriza &lt;br /&gt;
| Gryc Uriza(OSGrid) &lt;br /&gt;
| -6 &lt;br /&gt;
| &lt;br /&gt;
| PHP scripting, web interfaces, interconnectivity, cross-platformedness&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Phrearch|Phrearch]] &lt;br /&gt;
| Jeroen van Veen &lt;br /&gt;
| Phrearch Miles &lt;br /&gt;
| Phrearch Miles(OSGrid) &lt;br /&gt;
| Amsterdam/Paris &lt;br /&gt;
| &lt;br /&gt;
| HWIOS, WiXTD, Wikidoc, Moo, User interfaces&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Burnman|Burnman]] &lt;br /&gt;
| Allen &lt;br /&gt;
| Burnman Bedlam &lt;br /&gt;
| &lt;br /&gt;
| Boston, USA &lt;br /&gt;
| &lt;br /&gt;
| Testing, testing, and more testing! Getting familiar with the source, interested in all aspects of the project.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Krisbfunk|krisbfunk]] &lt;br /&gt;
| Kris Bulman &lt;br /&gt;
| Krisbfunk Vought &lt;br /&gt;
| Krisbfunk Nocturnal(OSGrid) &lt;br /&gt;
| PE, Canada (-4) &lt;br /&gt;
| Edactive Technologies&amp;lt;br /&amp;gt;NocturnalEye Productions&amp;lt;br /&amp;gt;UPEI &lt;br /&gt;
| Currently: Testing, bug reports, wiki updating, building on OSGrid&lt;br /&gt;
|-&lt;br /&gt;
| [[User:HashBox|HashBox]] &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Sibariel Darkstone &lt;br /&gt;
| Sibariel Darkstone (OSGrid) &lt;br /&gt;
| New Zealand (+12) &lt;br /&gt;
| &lt;br /&gt;
| Testing, bug reports, and updating the wiki.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Kinoc|Kinoc]] &lt;br /&gt;
| Kino Coursey &lt;br /&gt;
| Daxxon Jaxxon &lt;br /&gt;
| Daxxon Kinoc (OSgrid) &lt;br /&gt;
| -6 &lt;br /&gt;
| Daxtron Laboratories &amp;lt;br /&amp;gt; http://www.daxtron.com&amp;lt;br /&amp;gt; University of North Texas &lt;br /&gt;
| AI, Semantic web, Ontologies, Natural Laanguage Processing, Cyc, Bots, NPC&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Trapuh|trapuh]] &lt;br /&gt;
| Pedro Ribeiro &lt;br /&gt;
| Vaiten Forder &lt;br /&gt;
| &lt;br /&gt;
| GMT &lt;br /&gt;
| University Student, Escola Superior de Educação de Viseu, Portugal &lt;br /&gt;
| Testing, eventual bug reports and wiki. Music, web/digital arts and php+sql.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:SonicViz|SonicViz]] &lt;br /&gt;
| Paul Cohen &lt;br /&gt;
| Komuso Tokugawa &lt;br /&gt;
| &lt;br /&gt;
| +9 &lt;br /&gt;
| Http://sonicviz.com &lt;br /&gt;
| Audio/Music, Interactive Music, Control Protocols, Interfaces, VisualFX, Procedural animation/Generative systems + testing and general dev&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Mokele|mokele]] &lt;br /&gt;
| Scott Norman &lt;br /&gt;
| Mokelembembe Mokeev &lt;br /&gt;
| &lt;br /&gt;
| -8 (Southern California) &lt;br /&gt;
| Web Developer (PHP and MySQL) &lt;br /&gt;
| Interested in seeing running on PowerPC Macs which it is. So, when I can, I'll compile and test on PowerPC Mac (PowerBook G4) and submit reports and then update the wiki if need on installing on Mac. Also have a Ubuntu 7.10 server that I can do testing on too.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Devalnor|devalnor]] &lt;br /&gt;
| Devalnor &lt;br /&gt;
| M. Watkin &lt;br /&gt;
| &lt;br /&gt;
| +1 (Belgium) &lt;br /&gt;
| &lt;br /&gt;
| Small Patch code, bug reports, and updating the wiki.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Ezekiel|Ezekiel]] &lt;br /&gt;
| Ezekiel &lt;br /&gt;
| Ezekiel Zabelin &lt;br /&gt;
| &lt;br /&gt;
| +1 &lt;br /&gt;
| http://www.yosims.com &lt;br /&gt;
| Concepts, business aspects of virtual worlds - web developer (PHP, MySQL, Javascript, LSL)&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Buggmaster|Buggmaster]] &lt;br /&gt;
| Mike D &lt;br /&gt;
| Bug Master &lt;br /&gt;
| None &lt;br /&gt;
| -8 &lt;br /&gt;
| http://www.adultmetaverse.com &lt;br /&gt;
| Grid, Data/Web PHP/PERL/MySQL&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Nixnerd|nixnerd]] &lt;br /&gt;
| &lt;br /&gt;
| Dangerously Moody &lt;br /&gt;
| None &lt;br /&gt;
| GMT &lt;br /&gt;
| http://www.integratedtechnologies.eu &lt;br /&gt;
| Cross Platform Testing, Feedback, Bug Reporting&lt;br /&gt;
|-&lt;br /&gt;
| [[User:MoHax|mohax]] &lt;br /&gt;
| Mo Hax &lt;br /&gt;
| Mo Hax &lt;br /&gt;
| &lt;br /&gt;
| -5 Eastern &lt;br /&gt;
| IBM &lt;br /&gt;
| Testing, Feedback, Content Contributions, Bug Reporting, Documenting, Development&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Webmage|webmage]] &lt;br /&gt;
| webmage &lt;br /&gt;
| Leyla Masala &lt;br /&gt;
| Web Mage &lt;br /&gt;
| +1 &lt;br /&gt;
| IBM &lt;br /&gt;
| Testing, terrain&lt;br /&gt;
|-&lt;br /&gt;
| [[User:NLStitch|NLStitch]] &lt;br /&gt;
| Marijn Oosterveld &lt;br /&gt;
| Stitch Seale &lt;br /&gt;
| NYA &lt;br /&gt;
| GMT +1 Amsterdam &lt;br /&gt;
| Twingate Systems (http://www.twingate.nl)&amp;lt;br /&amp;gt;HanzeHogeschool Groningen, Netherlands &lt;br /&gt;
| Programming, Photography, AI&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Ideia Boa|Ideia Boa]] &lt;br /&gt;
| Joao Lopes &lt;br /&gt;
| Ideia Boa &lt;br /&gt;
| Ideia Boa or Boa Ideia in some grids &lt;br /&gt;
| GTM+1 Stockholm/Sweden &lt;br /&gt;
| WorldSimTERRA - Virtual World that speaks Portuguese too&amp;lt;br /&amp;gt;http://www.worldsimterra.com &lt;br /&gt;
| Testing and more testing! Updating the original wiki and translating the OpenSimulator Wiki into Portuguese and reporting on OpenSimulator&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Lulurun|lulurun]] &lt;br /&gt;
| liu &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +9 &lt;br /&gt;
| 3Di Inc, Japan &amp;lt;br /&amp;gt;http://www.3di.jp &lt;br /&gt;
| Patches, openid, server performance, UGAI&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Carlosroundel|Carlosrounde]] &lt;br /&gt;
| Carlosroundel &lt;br /&gt;
| Carlos Roundel &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +1 &lt;br /&gt;
| Cyberlandia Italy&amp;lt;br /&amp;gt;http://www.cyberlandia.net &lt;br /&gt;
| Grid, programmer, database, tester&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Mikebert|Mikebert]] &lt;br /&gt;
| Michael Strunck &lt;br /&gt;
| Mikebert Miles &lt;br /&gt;
| Mikebert M34 &lt;br /&gt;
| +1 &lt;br /&gt;
| OpenSIM Wiki, Germany&amp;lt;br /&amp;gt;http://www.opensim.de &lt;br /&gt;
| German Wiki, Translater, Server Performance (Linux/Windows), Tester, Feedback, Bug Reporting, Server-Hosting&lt;br /&gt;
|-&lt;br /&gt;
| Taoki &lt;br /&gt;
| Mircea Kitsune / Taoki Vixen &lt;br /&gt;
| Mircea Kitsune (OSGrid) / Mircea Lobo (LL grid) &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| GMT +2 &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| Usually testing and bug reporting but I also make smaller patches where I know what to do.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Patnad|Patnad]] &lt;br /&gt;
| Patrick &lt;br /&gt;
| Patnad Babii &lt;br /&gt;
| Patnad Babii (OSGrid) &lt;br /&gt;
| GMT -5 &lt;br /&gt;
| RezzMe Technologies&amp;lt;br /&amp;gt;http://www.rezzme.com &lt;br /&gt;
| Bug testing and reporting, I code C# and have submitted a few patches&lt;br /&gt;
|-&lt;br /&gt;
| [[User:^DarkMan|^DarkMan]] &lt;br /&gt;
| Brian Adair &lt;br /&gt;
| Patrick Ouachita &lt;br /&gt;
| Brian Adair &amp;amp;#124; Patrick Meta &lt;br /&gt;
| -6 CST &lt;br /&gt;
| RealMetaLife &amp;amp;#124; B&amp;amp;amp;H Networking &lt;br /&gt;
| Building, Scripting, Testing, etc.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Tlaukkan|Tommi Laukkanen]] &lt;br /&gt;
| Tommi Laukkanen &lt;br /&gt;
| &amp;amp;nbsp; &lt;br /&gt;
| Tommi Laukkanen &lt;br /&gt;
| +2 GMT &lt;br /&gt;
| http://www.bubblecloud.org &lt;br /&gt;
| Protocols ([http://www.bubblecloud.org MXP]), NHibernate, Scrip API, Map Generation, Bug Fixes, Grid Hosting&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Mystical|Mystical]] &lt;br /&gt;
| Kevin Tweedy &lt;br /&gt;
| Mystical Demina &lt;br /&gt;
| Mystical Demina &lt;br /&gt;
| -5 &lt;br /&gt;
| Extreme Reality Grid&amp;lt;br /&amp;gt;http://www.XRGrid.com &lt;br /&gt;
| Windows Communication Framework, Windows Workflow,Entity Framework, MSSQL&amp;lt;br /&amp;gt;Enhancements,Commerce, Content,DotNetNuke based portal, development services&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Godfrey|Godfrey]] &lt;br /&gt;
| Jeff Lee &lt;br /&gt;
| Warin Cascabel &lt;br /&gt;
| &lt;br /&gt;
| -5 (EST5EDT) &lt;br /&gt;
| &lt;br /&gt;
| Testing, minor bugfixes. Scripting, building, animating&lt;br /&gt;
|-&lt;br /&gt;
| Jamenai &lt;br /&gt;
| Christopher Händler &lt;br /&gt;
| Jamenai Luik &lt;br /&gt;
| Jamenai Luik &lt;br /&gt;
| +1 &lt;br /&gt;
| Playneko Grid &amp;amp;#124; XIMDEX Jamenai&amp;lt;br /&amp;gt;http://www.playneko.de&amp;lt;br /&amp;gt;http://www.ximdex.de &lt;br /&gt;
| Performance,Bug Reporting, Hosting, Grid-Owner,(PHP, MySQL, Perl, JavaScript, LSL)&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Bikcmp|bikcmp]] &lt;br /&gt;
| Jason &lt;br /&gt;
| Jake1500 Allen &lt;br /&gt;
| Jason Helios (The Helios Grid) &lt;br /&gt;
| EST &lt;br /&gt;
| Blue Software &lt;br /&gt;
| Search, groups, land, and currency&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Mark.malewski|Slipaway]] &lt;br /&gt;
| Mark Malewski &lt;br /&gt;
| Chris Rock &lt;br /&gt;
| &lt;br /&gt;
| -6 (-5 during summer - CDT) &lt;br /&gt;
| NexTECH / Joopla &lt;br /&gt;
| Web development &amp;amp;amp; systems integration, terrain, WIKI documentation, tutorials, testing, bug reporting and feedback.&lt;br /&gt;
|-&lt;br /&gt;
| barakademi &lt;br /&gt;
| Steve Topp &lt;br /&gt;
| barakademi Barzane &lt;br /&gt;
| same avi on baragrid OSgrid Grid4us sciencesim &lt;br /&gt;
| utc+1 (CET) paris &lt;br /&gt;
| http://xbot-sl.barakademi.org http://vps.barakademi.org/oswi http://vps.barakademi.org/oswi/loginscreen.php &lt;br /&gt;
| Music LiveMusic MetaverseMusic Opensim Libomv Mono-2.4 Linux (suse,debian,ubuntu) Admin Scripting Automating Development Intergration php mysql bash nant +++&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Robert d|robert_d]] &lt;br /&gt;
| Robert Dzikowski &lt;br /&gt;
| &lt;br /&gt;
| OSGrid: robert_d 13 &lt;br /&gt;
| UTC+1 &lt;br /&gt;
| [http://blog.rd-it.net http://blog.rd-it.net] &lt;br /&gt;
| Region Modules, Tutorials&lt;br /&gt;
|-&lt;br /&gt;
| john_ &lt;br /&gt;
| John&amp;amp;nbsp;Moyer &lt;br /&gt;
| VAJohn&amp;amp;nbsp;GeekSquad or&amp;amp;nbsp;Matthew&amp;amp;nbsp;Kendal &lt;br /&gt;
| &lt;br /&gt;
| -5 &lt;br /&gt;
| Best&amp;amp;nbsp;Buy/Geek&amp;amp;nbsp;Squad &lt;br /&gt;
| Tester&lt;br /&gt;
|-&lt;br /&gt;
| [[User:W!cKeD|_WicKeD]] &lt;br /&gt;
| Maik &lt;br /&gt;
| Maik Galaxy &lt;br /&gt;
| El Diablo &lt;br /&gt;
| +1 Germany &lt;br /&gt;
| Creatio Inc. / [http://www.OpenSimGerman.us/ OpenSimGerman.us] &lt;br /&gt;
| German Support, Translator, Building, Scripting, Testing, Hosting&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Stevie Wakowski|Stevie Wakowksi]] &lt;br /&gt;
| Steve Roberts &lt;br /&gt;
| Stevie Wakowski &lt;br /&gt;
| &lt;br /&gt;
| +10 Australia &lt;br /&gt;
| IBM &lt;br /&gt;
| OpenSimulator builds, Linux, Modrex, bug reporting, evangalist for OpenSimulator in business applications.&lt;br /&gt;
|-&lt;br /&gt;
| Revolution &lt;br /&gt;
| Matthew &lt;br /&gt;
| Revolution Smythe &lt;br /&gt;
| Revolution Smythe &lt;br /&gt;
| -6 Central USA &lt;br /&gt;
| None &lt;br /&gt;
| Script engine, physics engine, general odd bugs, interesting and odd things&lt;br /&gt;
|-&lt;br /&gt;
| [[User:ClemsonGS|clemsonGS]] &lt;br /&gt;
| Brian Cass &lt;br /&gt;
| BC Sands &lt;br /&gt;
| Brian Cass (VWC Grid) &lt;br /&gt;
| -5 &lt;br /&gt;
| http://www.cvwconline.org/ &lt;br /&gt;
| Developing virtual worlds for use in higher education&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| AlexRa &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| Independent &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| Mikko Pallari &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| Realxtend &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| StrawberryFride &lt;br /&gt;
| Chris Hart &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| ReactionGrid &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| [[User:RemedyTomm|RemedyTomm]] &lt;br /&gt;
| Tom Grimshaw &lt;br /&gt;
| Tomm Remedy &lt;br /&gt;
| KGrid: Casper Warden OSGrid: Tomm Remedy &lt;br /&gt;
| UTC+0 (BST) &lt;br /&gt;
| Remedy Communications &lt;br /&gt;
| Texture pipeline, Groups, ObjectUpdates&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| Rob Smart &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| IBM &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| MicheilMerlin &lt;br /&gt;
| Micheil Merlin &lt;br /&gt;
| Micheil Merlin &lt;br /&gt;
| Micheil Merlin &lt;br /&gt;
| -6 &lt;br /&gt;
| Independent &amp;lt;br /&amp;gt; [http://www.iliveisl.com/ http://www.iliveisl.com/] &lt;br /&gt;
| Scripting, patches, and testcases&lt;br /&gt;
|-&lt;br /&gt;
| Pato Donald &lt;br /&gt;
| Pato Donald &lt;br /&gt;
| Morgam Biedermann &lt;br /&gt;
| Pato Donald &lt;br /&gt;
| -3 &lt;br /&gt;
| Independent [http://www.matheusmk3.co.cc/ http://www.matheusmk3.co.cc/ &lt;br /&gt;
| Groups, Scripts, Physics, Communication, Integration&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| Sera Marx &lt;br /&gt;
| Darkfire Soulstar &lt;br /&gt;
| &lt;br /&gt;
| +12 &lt;br /&gt;
| Radiance promotions &lt;br /&gt;
| Grid Host, Commissioner. ~ Anyone looking for work related to the development of Opensimulator or Viewers please contact me. Any work undertaken for me will be returned to Opensimulator unless made strictly for my Grid&lt;br /&gt;
|-&lt;br /&gt;
|[[User:dz|dz]]  &lt;br /&gt;
| Doug Osborn &lt;br /&gt;
| ydoo magic&lt;br /&gt;
| delta zed @ OSGRID Doug Osborn @ ScienceSim &amp;amp; MOSES grids&lt;br /&gt;
| PST/SLT (-7 or -8) &lt;br /&gt;
| CEO OpenSimian &lt;br /&gt;
| Performance testing, advanced scripting, high prim count builds,  Client and server side bots, Animation Overrides, MANTIS maintenance.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Hallow Palmer|Hallow Palmer]] &lt;br /&gt;
| Markus &lt;br /&gt;
| Hallow Palmer &lt;br /&gt;
| &amp;lt;br /&amp;gt; &lt;br /&gt;
| +1 &lt;br /&gt;
| Grid4Us&amp;lt;br /&amp;gt;http://www.grid4us.net &lt;br /&gt;
| Server Performance (Windows), Tester, Feedback, Business concepts,Bug Reporting, Server-Hosting&lt;br /&gt;
|-&lt;br /&gt;
| [[User:LenaVanilli|LenaVanilli]] &lt;br /&gt;
| Lena Vanilli &lt;br /&gt;
| Lena Vanilli &lt;br /&gt;
| Lena Vanilli &lt;br /&gt;
| +1 Germany &lt;br /&gt;
| [http://www.hypergrid.org http://www.hypergrid.org] &lt;br /&gt;
| Grid-Management, Testing Testing Testing, Region Hosting&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Aduffy70|aduffy70]] &lt;br /&gt;
| Aaron Duffy &lt;br /&gt;
| Aeran Stipe &lt;br /&gt;
| Aaron Duffy @ScienceSim &lt;br /&gt;
| -7 &lt;br /&gt;
| USU &lt;br /&gt;
| Scientific visualization &amp;amp;amp; education, Region modules, Heavily scripted regions&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| Erich Bremer &lt;br /&gt;
| Erich Bremer &lt;br /&gt;
| &lt;br /&gt;
Erich Bremer@OSGrid &lt;br /&gt;
&lt;br /&gt;
| -5 &lt;br /&gt;
| http://www.ebremer.com &lt;br /&gt;
| Semantic Web, Data Visualization&lt;br /&gt;
|-&lt;br /&gt;
| [[User:MarkIDCAS|MarkIDCAS]] &lt;br /&gt;
| Mark Bannon &lt;br /&gt;
| Mark IDCAS &lt;br /&gt;
| 3D Grid Association, AtMeeting, Valhalla Virtual and IDCAS. &lt;br /&gt;
| GMT &lt;br /&gt;
| [http://www.valhallavirtual.com http://www.valhallavirtual.com] &lt;br /&gt;
| Grid Management &amp;amp;amp; systems integration. Scripting. WIKI documentation, tutorials, bug reporting and feedback.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Allquixotic|allquixotic]] &lt;br /&gt;
| Sean McNamara &lt;br /&gt;
| Tiyuk Quellmalz &lt;br /&gt;
| OSG: Tiyuk Quellmalz &lt;br /&gt;
| -5 &lt;br /&gt;
| None &lt;br /&gt;
| Bugfixing; networking; performance; data integrity; LSL; auto-backup; null DB (eventual consistency).&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Orenh|orenh]] &lt;br /&gt;
| Oren Hurvitz &lt;br /&gt;
| &lt;br /&gt;
| Oren Hurvitz (Kitely) &lt;br /&gt;
| +2 &lt;br /&gt;
| Kitely &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| [[User:Randomhuman|randomhuman]] &lt;br /&gt;
| Kevin Houlihan &lt;br /&gt;
| random Radikal &lt;br /&gt;
| random human (OSGrid) &lt;br /&gt;
| WET/IST &lt;br /&gt;
| CrimsonCookie &lt;br /&gt;
| RemoteAdmin module; On-demand grids; web integration.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Oddball Otoole|oddball otoole]]&lt;br /&gt;
| J.v.Hogeloon&lt;br /&gt;
| Oddball Otoole&lt;br /&gt;
| Oddball Otoole (OSGrid&lt;br /&gt;
| +1 (The Netherlands&lt;br /&gt;
| None&lt;br /&gt;
| Building, scripting, testing, social stuff.&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Pixel|Pixel Tomsen]]&lt;br /&gt;
| Christian Kurzhals&lt;br /&gt;
| Pixel Tomsen&lt;br /&gt;
| Pixel Tomsen OSGrid&lt;br /&gt;
| +1 (Germany&lt;br /&gt;
| see my profil&lt;br /&gt;
| Dev, Building, scripting, sim-hosting, some modules, patches, osgrid&lt;br /&gt;
|-&lt;br /&gt;
| [[User:kenearlg|kenearlg]]&lt;br /&gt;
| Ken Grunke&lt;br /&gt;
| Key Grau&lt;br /&gt;
| Key Gruin (Osgrid)&lt;br /&gt;
| -6 CST&lt;br /&gt;
| http://www.osgrid.org/&lt;br /&gt;
| testing, moderating, inworld games &amp;amp; recreation, wiki spam control&lt;br /&gt;
|-&lt;br /&gt;
| [[User:CG4Life|CG4Life]]&lt;br /&gt;
| CG Anderson&lt;br /&gt;
| Cyn Hak&lt;br /&gt;
| &lt;br /&gt;
| -8 PST&lt;br /&gt;
| Little Dogs Media&lt;br /&gt;
| Networking, Security, Performance (parallelization, compression, encryption), physics, 3D manipulation, bugfixing, documentation.  Just getting into the code base, so will start with compression/parallelizatoin ideas and bugfixing, then other stuff later.&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Retired Additional Developers ==&lt;br /&gt;
&lt;br /&gt;
Additional developers who are no longer working on the OpenSimulator project. Thank you forever for your contributions! &lt;br /&gt;
&lt;br /&gt;
{| cellspacing=&amp;quot;0&amp;quot; cellpadding=&amp;quot;2&amp;quot; border=&amp;quot;1&amp;quot; class=&amp;quot;sortable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! IRC Nick &lt;br /&gt;
! Name &lt;br /&gt;
! SL Avatar &lt;br /&gt;
! Other Grid &lt;br /&gt;
! Time Zone&amp;lt;br /&amp;gt;(UTC) &lt;br /&gt;
! Org &lt;br /&gt;
! Areas of Interest&lt;br /&gt;
|-&lt;br /&gt;
| [[User:Fly-man-|Fly-Man-]] &lt;br /&gt;
| Laurence &lt;br /&gt;
| &lt;br /&gt;
| OSGrid: Fly Man &lt;br /&gt;
| GMT +1 &lt;br /&gt;
| Private Company&lt;br /&gt;
| Testing, OpenSimSearch, OpenSimProfile&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Category:OSSL_Functions</id>
		<title>Category:OSSL Functions</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Category:OSSL_Functions"/>
				<updated>2014-01-28T05:36:42Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Grid Information */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Current OSSL Functions Implemented  ==&lt;br /&gt;
&lt;br /&gt;
Updated OSSL Functions as of OpenSim DEV 0.7.4 r/21068 17th November, 2012&lt;br /&gt;
&amp;lt;br /&amp;gt;&amp;lt;br /&amp;gt;&lt;br /&gt;
'''!''' Partial Update December.10.2010 With commits of this date some functions have been corrected to use standard ossl conventions. The previous are tagged as deprecated with their replacement shown. The deprecated functions will advise you with a msg that they have been deprecated and to use new osFunction name instead. Further Updates are needed to complete existing list of osFunctions.&lt;br /&gt;
&lt;br /&gt;
Special Note: Some Functions as shown use '''&amp;quot;double&amp;quot;''' as a Value instead of '''&amp;quot;float&amp;quot; '''these vary for purposes of accuracy as shown Below. &lt;br /&gt;
&lt;br /&gt;
(Float is short for &amp;quot;floating point&amp;quot;, and just means a number with a point something on the end.) &lt;br /&gt;
&lt;br /&gt;
The difference between the two is in the size of the numbers that they can hold. For float, you can have up to 7 digits in your number. For doubles, you can have up to 16 digits. To be more precise, here's the official size: ( float: 1.5 × 10-45 to 3.4 × 1038 ) ( double: 5.0 × 10-324 to 1.7 × 10308 ) &lt;br /&gt;
&lt;br /&gt;
Note that some function takes doubles as arguments but may be internally down-casted to floats.&lt;br /&gt;
&lt;br /&gt;
Each of these functions has an threat level associated to it. See [[Threat level]] for more information and an overview of each function's level.&lt;br /&gt;
&lt;br /&gt;
=== Avatars ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osGetAgentIP]] &lt;br /&gt;
*[[osGetAgents]]&lt;br /&gt;
*[[osGetAvatarList]] &lt;br /&gt;
*[[osAvatarName2Key]]&lt;br /&gt;
*[[osAvatarPlayAnimation]] &lt;br /&gt;
*[[osAvatarStopAnimation]] &lt;br /&gt;
*[[osAgentSaveAppearance]]&lt;br /&gt;
*[[osOwnerSaveAppearance]]&lt;br /&gt;
*[[osTeleportAgent]] &lt;br /&gt;
*[[osTeleportOwner]] &lt;br /&gt;
*[[osKickAvatar]]&lt;br /&gt;
*[[osCauseDamage]] &lt;br /&gt;
*[[osCauseHealing]]&lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osGetHealth]]&lt;br /&gt;
*[[osSetSpeed]]&lt;br /&gt;
*[[osInviteToGroup]]&lt;br /&gt;
*[[osEjectFromGroup]]&lt;br /&gt;
*[[osForceAttachToAvatar]]&lt;br /&gt;
*[[osForceAttachToAvatarFromInventory]]&lt;br /&gt;
*[[osForceAttachToOtherAvatarFromInventory]]&lt;br /&gt;
*[[osForceDetachFromAvatar]]&lt;br /&gt;
*[[osGetNumberOfAttachments]]&lt;br /&gt;
*[[osDropAttachment]]&lt;br /&gt;
*[[osDropAttachmentAt]]&lt;br /&gt;
*[[osForceDropAttachment]]&lt;br /&gt;
*[[osForceDropAttachmentAt]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== NPCs ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osNpcCreate]]&lt;br /&gt;
*[[osNpcGetPos]]&lt;br /&gt;
*[[osNpcGetRot]]&lt;br /&gt;
*[[osNpcGetOwner]]&lt;br /&gt;
*[[osNpcLoadAppearance]]&lt;br /&gt;
*[[osNpcMoveTo]]&lt;br /&gt;
*[[osNpcMoveToTarget]]&lt;br /&gt;
*[[osNpcRemove]]&lt;br /&gt;
*[[osNpcSaveAppearance]]&lt;br /&gt;
*[[osNpcSay]]&lt;br /&gt;
*[[osNpcSay (with channel)]]&lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osNpcSetRot]]&lt;br /&gt;
*[[osNpcShout]]&lt;br /&gt;
*[[osNpcSit]]&lt;br /&gt;
*[[osNpcStand]]&lt;br /&gt;
*[[osNpcStopMoveToTarget]]&lt;br /&gt;
*[[osIsNpc]]&lt;br /&gt;
*[[osNpcPlayAnimation]]&lt;br /&gt;
*[[osNpcStopAnimation]]&lt;br /&gt;
*[[osNpcTouch]]&lt;br /&gt;
*[[osNpcWhisper]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Prim Manipulations ===&lt;br /&gt;
*[[osGetPrimitiveParams]] &lt;br /&gt;
*[[osGetLinkPrimitiveParams]] &lt;br /&gt;
*[[osSetPrimitiveParams]] &lt;br /&gt;
*[[osSetProjectionParams]] &lt;br /&gt;
*[[osSetSpeed]] &lt;br /&gt;
*[[osMessageObject]]&lt;br /&gt;
*[[osGetInventoryDesc]]&lt;br /&gt;
*[[osGetRezzingObject]]&lt;br /&gt;
*[[osIsUUID]]&lt;br /&gt;
*[[osListenRegex]]&lt;br /&gt;
*[[osMessageAttachments]]&lt;br /&gt;
&lt;br /&gt;
=== Prim Drawings ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osMovePen]] &lt;br /&gt;
*[[osDrawLine]] &lt;br /&gt;
*[[osDrawText]] &lt;br /&gt;
*[[osDrawEllipse]] &lt;br /&gt;
*[[osDrawRectangle]] &lt;br /&gt;
*[[osDrawFilledRectangle]] &lt;br /&gt;
*[[osDrawPolygon]] &lt;br /&gt;
*[[osDrawFilledPolygon]] &lt;br /&gt;
*[[osDrawImage]] &lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osGetDrawStringSize]] &lt;br /&gt;
*[[osSetFontName]] &lt;br /&gt;
*[[osSetFontSize]] &lt;br /&gt;
*[[osSetPenSize]] &lt;br /&gt;
*[[osSetPenColor]] &lt;br /&gt;
*[[osSetPenCap]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Textures ===&lt;br /&gt;
*[[osSetDynamicTextureData]] &lt;br /&gt;
*[[osSetDynamicTextureDataBlend]] &lt;br /&gt;
*[[osSetDynamicTextureDataBlendFace]] &lt;br /&gt;
*[[osSetDynamicTextureURL]] &lt;br /&gt;
*[[osSetDynamicTextureURLBlend]] &lt;br /&gt;
*[[osSetDynamicTextureURLBlendFace]]&lt;br /&gt;
&lt;br /&gt;
=== Notecards ===&lt;br /&gt;
*[[osMakeNotecard]] &lt;br /&gt;
*[[osGetNotecard]] &lt;br /&gt;
*[[osGetNotecardLine]] &lt;br /&gt;
*[[osGetNumberOfNotecardLines]] &lt;br /&gt;
&lt;br /&gt;
=== Parcels ===&lt;br /&gt;
*[[osParcelJoin]] &lt;br /&gt;
*[[osParcelSubdivide]] &lt;br /&gt;
*[[osSetParcelDetails]]&lt;br /&gt;
&lt;br /&gt;
=== Terrains ===&lt;br /&gt;
*[[osGetTerrainHeight]] &lt;br /&gt;
*[[osSetTerrainHeight]] &lt;br /&gt;
*[[osTerrainFlush]]&lt;br /&gt;
*[[osSetTerrainTexture]]&lt;br /&gt;
*[[osSetTerrainTextureHeight]]&lt;br /&gt;
&lt;br /&gt;
=== WindLights ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osSetRegionWaterHeight]] &lt;br /&gt;
*[[osSetRegionSunSettings]] &lt;br /&gt;
*[[osSetEstateSunSettings]] &lt;br /&gt;
*[[osGetCurrentSunHour]] &lt;br /&gt;
*[[osGetSunParam]] &lt;br /&gt;
*[[osSetSunParam]] &lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osWindActiveModelPluginName]] &lt;br /&gt;
*[[osGetWindParam]] &lt;br /&gt;
*[[osSetWindParam]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Grid Information ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osGetGridName]] &lt;br /&gt;
*[[osGetGridNick]] &lt;br /&gt;
*[[osGetGridLoginURI]]&lt;br /&gt;
*[[osGetGridHomeURI]]&lt;br /&gt;
*[[osGetGridGatekeeperURI]]&lt;br /&gt;
*[[osGetGridCustom]]&lt;br /&gt;
*[[osGetScriptEngineName]] &lt;br /&gt;
*[[osGetSimulatorVersion]] &lt;br /&gt;
*[[osGetSimulatorMemory]] &lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osGetMapTexture]] &lt;br /&gt;
*[[osGetRegionMapTexture]] &lt;br /&gt;
*[[osGetRegionSize]]&lt;br /&gt;
*[[osGetRegionStats]] &lt;br /&gt;
*[[osLoadedCreationDate]] &lt;br /&gt;
*[[osLoadedCreationTime]] &lt;br /&gt;
*[[osLoadedCreationID]] &lt;br /&gt;
*[[osGetPhysicsEngineType]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Administration ===&lt;br /&gt;
*[[osRegionNotice]] &lt;br /&gt;
*[[osRegionRestart]] &lt;br /&gt;
*[[osConsoleCommand]] &lt;br /&gt;
*[[osSetParcelMediaURL]] &lt;br /&gt;
*[[osSetPrimFloatOnWater]]&lt;br /&gt;
*[[osSetParcelSIPAddress]]&lt;br /&gt;
&lt;br /&gt;
=== Misc ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osSetStateEvents]] &lt;br /&gt;
*[[osList2Double]] &lt;br /&gt;
*[[osKey2Name]] &lt;br /&gt;
*[[osFormatString]] &lt;br /&gt;
*[[osMatchString]] &lt;br /&gt;
*[[osUnixTimeToTimestamp]] &lt;br /&gt;
*[[osParseJSON]]&lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osParseJSONNew]]&lt;br /&gt;
*[[osMax]]&lt;br /&gt;
*[[osMin]]&lt;br /&gt;
*[[osRegexIsMatch]]&lt;br /&gt;
*[[osReplaceString]]&lt;br /&gt;
*[[osSetContentType]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Deprecated ===&lt;br /&gt;
*[[osParcelSetDetails|&amp;lt;strike&amp;gt;osParcelSetDetails&amp;lt;/strike&amp;gt;]] - Use [[osSetParcelDetails]] &lt;br /&gt;
*[[osSetPenColour|&amp;lt;strike&amp;gt;osSetPenColour&amp;lt;/strike&amp;gt;]] - Use [[osSetPenColor]] &lt;br /&gt;
*[[osSunGetParam|&amp;lt;strike&amp;gt;osSunGetParam&amp;lt;/strike&amp;gt;]] - Use [[osGetSunParam]] &lt;br /&gt;
*[[osSunSetParam|&amp;lt;strike&amp;gt;osSunSetParam&amp;lt;/strike&amp;gt;]] - Use [[osSetSunParam]] &lt;br /&gt;
*[[osTerrainGetHeight|&amp;lt;strike&amp;gt;osTerrainGetHeight&amp;lt;/strike&amp;gt;]] - Use [[osGetTerrainHeight]] &lt;br /&gt;
*[[osTerrainSetHeight|&amp;lt;strike&amp;gt;osTerrainSetHeight&amp;lt;/strike&amp;gt;]] - Use [[osSetTerrainHeight]]&lt;br /&gt;
&lt;br /&gt;
== See Also  ==&lt;br /&gt;
&lt;br /&gt;
*[[LSL Status|LSL/OSSL Status Page]] &lt;br /&gt;
*OSSL &lt;br /&gt;
**[[OSSL_Implemented|OSSL Implemented Functions]] &lt;br /&gt;
**[[OSSL Constants|OSSL Constants]] &lt;br /&gt;
**[[OSSL Status/Types|OSSL Types Status Page]] &lt;br /&gt;
**[[OSSL Status/Events|OSSL Events Status Page]] &lt;br /&gt;
&lt;br /&gt;
**[[Dynamic_textures|OSSL osDynamicTextures Functions Index Page]]&lt;br /&gt;
**[[OSSL TextureDrawing|OSSL TextureDrawing Extended Information]]&lt;br /&gt;
**[[OSSLNPC|OSSL functions for working with NPCs]]&lt;br /&gt;
&lt;br /&gt;
**[[OSSL Proposals|OSSL Proposed Functions]] &lt;br /&gt;
**[[OSSL Enabling Functions]] &lt;br /&gt;
**[[OSSL Standards|OSSL Standards]]&lt;br /&gt;
&lt;br /&gt;
* LS&lt;br /&gt;
** [[LightShare#LightShare Scripting|LightShare Functions]]&lt;br /&gt;
&lt;br /&gt;
* MOD&lt;br /&gt;
** [[OSSL Script Library/ModSendCommand|modSendCommand()]]&lt;br /&gt;
** [[OSSL Script Library/ModInvoke|Custom functions using modInvoke()]]&lt;br /&gt;
&lt;br /&gt;
[[Category:OSSL]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Category:OSSL_Functions</id>
		<title>Category:OSSL Functions</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Category:OSSL_Functions"/>
				<updated>2014-01-28T05:35:42Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Current OSSL Functions Implemented */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Current OSSL Functions Implemented  ==&lt;br /&gt;
&lt;br /&gt;
Updated OSSL Functions as of OpenSim DEV 0.7.4 r/21068 17th November, 2012&lt;br /&gt;
&amp;lt;br /&amp;gt;&amp;lt;br /&amp;gt;&lt;br /&gt;
'''!''' Partial Update December.10.2010 With commits of this date some functions have been corrected to use standard ossl conventions. The previous are tagged as deprecated with their replacement shown. The deprecated functions will advise you with a msg that they have been deprecated and to use new osFunction name instead. Further Updates are needed to complete existing list of osFunctions.&lt;br /&gt;
&lt;br /&gt;
Special Note: Some Functions as shown use '''&amp;quot;double&amp;quot;''' as a Value instead of '''&amp;quot;float&amp;quot; '''these vary for purposes of accuracy as shown Below. &lt;br /&gt;
&lt;br /&gt;
(Float is short for &amp;quot;floating point&amp;quot;, and just means a number with a point something on the end.) &lt;br /&gt;
&lt;br /&gt;
The difference between the two is in the size of the numbers that they can hold. For float, you can have up to 7 digits in your number. For doubles, you can have up to 16 digits. To be more precise, here's the official size: ( float: 1.5 × 10-45 to 3.4 × 1038 ) ( double: 5.0 × 10-324 to 1.7 × 10308 ) &lt;br /&gt;
&lt;br /&gt;
Note that some function takes doubles as arguments but may be internally down-casted to floats.&lt;br /&gt;
&lt;br /&gt;
Each of these functions has an threat level associated to it. See [[Threat level]] for more information and an overview of each function's level.&lt;br /&gt;
&lt;br /&gt;
=== Avatars ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osGetAgentIP]] &lt;br /&gt;
*[[osGetAgents]]&lt;br /&gt;
*[[osGetAvatarList]] &lt;br /&gt;
*[[osAvatarName2Key]]&lt;br /&gt;
*[[osAvatarPlayAnimation]] &lt;br /&gt;
*[[osAvatarStopAnimation]] &lt;br /&gt;
*[[osAgentSaveAppearance]]&lt;br /&gt;
*[[osOwnerSaveAppearance]]&lt;br /&gt;
*[[osTeleportAgent]] &lt;br /&gt;
*[[osTeleportOwner]] &lt;br /&gt;
*[[osKickAvatar]]&lt;br /&gt;
*[[osCauseDamage]] &lt;br /&gt;
*[[osCauseHealing]]&lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osGetHealth]]&lt;br /&gt;
*[[osSetSpeed]]&lt;br /&gt;
*[[osInviteToGroup]]&lt;br /&gt;
*[[osEjectFromGroup]]&lt;br /&gt;
*[[osForceAttachToAvatar]]&lt;br /&gt;
*[[osForceAttachToAvatarFromInventory]]&lt;br /&gt;
*[[osForceAttachToOtherAvatarFromInventory]]&lt;br /&gt;
*[[osForceDetachFromAvatar]]&lt;br /&gt;
*[[osGetNumberOfAttachments]]&lt;br /&gt;
*[[osDropAttachment]]&lt;br /&gt;
*[[osDropAttachmentAt]]&lt;br /&gt;
*[[osForceDropAttachment]]&lt;br /&gt;
*[[osForceDropAttachmentAt]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== NPCs ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osNpcCreate]]&lt;br /&gt;
*[[osNpcGetPos]]&lt;br /&gt;
*[[osNpcGetRot]]&lt;br /&gt;
*[[osNpcGetOwner]]&lt;br /&gt;
*[[osNpcLoadAppearance]]&lt;br /&gt;
*[[osNpcMoveTo]]&lt;br /&gt;
*[[osNpcMoveToTarget]]&lt;br /&gt;
*[[osNpcRemove]]&lt;br /&gt;
*[[osNpcSaveAppearance]]&lt;br /&gt;
*[[osNpcSay]]&lt;br /&gt;
*[[osNpcSay (with channel)]]&lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osNpcSetRot]]&lt;br /&gt;
*[[osNpcShout]]&lt;br /&gt;
*[[osNpcSit]]&lt;br /&gt;
*[[osNpcStand]]&lt;br /&gt;
*[[osNpcStopMoveToTarget]]&lt;br /&gt;
*[[osIsNpc]]&lt;br /&gt;
*[[osNpcPlayAnimation]]&lt;br /&gt;
*[[osNpcStopAnimation]]&lt;br /&gt;
*[[osNpcTouch]]&lt;br /&gt;
*[[osNpcWhisper]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Prim Manipulations ===&lt;br /&gt;
*[[osGetPrimitiveParams]] &lt;br /&gt;
*[[osGetLinkPrimitiveParams]] &lt;br /&gt;
*[[osSetPrimitiveParams]] &lt;br /&gt;
*[[osSetProjectionParams]] &lt;br /&gt;
*[[osSetSpeed]] &lt;br /&gt;
*[[osMessageObject]]&lt;br /&gt;
*[[osGetInventoryDesc]]&lt;br /&gt;
*[[osGetRezzingObject]]&lt;br /&gt;
*[[osIsUUID]]&lt;br /&gt;
*[[osListenRegex]]&lt;br /&gt;
*[[osMessageAttachments]]&lt;br /&gt;
&lt;br /&gt;
=== Prim Drawings ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osMovePen]] &lt;br /&gt;
*[[osDrawLine]] &lt;br /&gt;
*[[osDrawText]] &lt;br /&gt;
*[[osDrawEllipse]] &lt;br /&gt;
*[[osDrawRectangle]] &lt;br /&gt;
*[[osDrawFilledRectangle]] &lt;br /&gt;
*[[osDrawPolygon]] &lt;br /&gt;
*[[osDrawFilledPolygon]] &lt;br /&gt;
*[[osDrawImage]] &lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osGetDrawStringSize]] &lt;br /&gt;
*[[osSetFontName]] &lt;br /&gt;
*[[osSetFontSize]] &lt;br /&gt;
*[[osSetPenSize]] &lt;br /&gt;
*[[osSetPenColor]] &lt;br /&gt;
*[[osSetPenCap]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Textures ===&lt;br /&gt;
*[[osSetDynamicTextureData]] &lt;br /&gt;
*[[osSetDynamicTextureDataBlend]] &lt;br /&gt;
*[[osSetDynamicTextureDataBlendFace]] &lt;br /&gt;
*[[osSetDynamicTextureURL]] &lt;br /&gt;
*[[osSetDynamicTextureURLBlend]] &lt;br /&gt;
*[[osSetDynamicTextureURLBlendFace]]&lt;br /&gt;
&lt;br /&gt;
=== Notecards ===&lt;br /&gt;
*[[osMakeNotecard]] &lt;br /&gt;
*[[osGetNotecard]] &lt;br /&gt;
*[[osGetNotecardLine]] &lt;br /&gt;
*[[osGetNumberOfNotecardLines]] &lt;br /&gt;
&lt;br /&gt;
=== Parcels ===&lt;br /&gt;
*[[osParcelJoin]] &lt;br /&gt;
*[[osParcelSubdivide]] &lt;br /&gt;
*[[osSetParcelDetails]]&lt;br /&gt;
&lt;br /&gt;
=== Terrains ===&lt;br /&gt;
*[[osGetTerrainHeight]] &lt;br /&gt;
*[[osSetTerrainHeight]] &lt;br /&gt;
*[[osTerrainFlush]]&lt;br /&gt;
*[[osSetTerrainTexture]]&lt;br /&gt;
*[[osSetTerrainTextureHeight]]&lt;br /&gt;
&lt;br /&gt;
=== WindLights ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osSetRegionWaterHeight]] &lt;br /&gt;
*[[osSetRegionSunSettings]] &lt;br /&gt;
*[[osSetEstateSunSettings]] &lt;br /&gt;
*[[osGetCurrentSunHour]] &lt;br /&gt;
*[[osGetSunParam]] &lt;br /&gt;
*[[osSetSunParam]] &lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osWindActiveModelPluginName]] &lt;br /&gt;
*[[osGetWindParam]] &lt;br /&gt;
*[[osSetWindParam]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Grid Information ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osGetGridName]] &lt;br /&gt;
*[[osGetGridNick]] &lt;br /&gt;
*[[osGetGridLoginURI]]&lt;br /&gt;
*[[osGetGridHomeURI]]&lt;br /&gt;
*[[osGetGridGatekeeperURI]]&lt;br /&gt;
*[[osGetGridCustom]]&lt;br /&gt;
*[[osGetScriptEngineName]] &lt;br /&gt;
*[[osGetSimulatorVersion]] &lt;br /&gt;
*[[osGetSimulatorMemory]] &lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osGetMapTexture]] &lt;br /&gt;
*[[osGetRegionMapTexture]] &lt;br /&gt;
*[[osGetRegionStats]] &lt;br /&gt;
*[[osGetRegionSize]]&lt;br /&gt;
*[[osLoadedCreationDate]] &lt;br /&gt;
*[[osLoadedCreationTime]] &lt;br /&gt;
*[[osLoadedCreationID]] &lt;br /&gt;
*[[osGetPhysicsEngineType]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Administration ===&lt;br /&gt;
*[[osRegionNotice]] &lt;br /&gt;
*[[osRegionRestart]] &lt;br /&gt;
*[[osConsoleCommand]] &lt;br /&gt;
*[[osSetParcelMediaURL]] &lt;br /&gt;
*[[osSetPrimFloatOnWater]]&lt;br /&gt;
*[[osSetParcelSIPAddress]]&lt;br /&gt;
&lt;br /&gt;
=== Misc ===&lt;br /&gt;
{{multicol}}&lt;br /&gt;
*[[osSetStateEvents]] &lt;br /&gt;
*[[osList2Double]] &lt;br /&gt;
*[[osKey2Name]] &lt;br /&gt;
*[[osFormatString]] &lt;br /&gt;
*[[osMatchString]] &lt;br /&gt;
*[[osUnixTimeToTimestamp]] &lt;br /&gt;
*[[osParseJSON]]&lt;br /&gt;
{{multicol-break}}&lt;br /&gt;
*[[osParseJSONNew]]&lt;br /&gt;
*[[osMax]]&lt;br /&gt;
*[[osMin]]&lt;br /&gt;
*[[osRegexIsMatch]]&lt;br /&gt;
*[[osReplaceString]]&lt;br /&gt;
*[[osSetContentType]]&lt;br /&gt;
{{multicol-end}}&lt;br /&gt;
&lt;br /&gt;
=== Deprecated ===&lt;br /&gt;
*[[osParcelSetDetails|&amp;lt;strike&amp;gt;osParcelSetDetails&amp;lt;/strike&amp;gt;]] - Use [[osSetParcelDetails]] &lt;br /&gt;
*[[osSetPenColour|&amp;lt;strike&amp;gt;osSetPenColour&amp;lt;/strike&amp;gt;]] - Use [[osSetPenColor]] &lt;br /&gt;
*[[osSunGetParam|&amp;lt;strike&amp;gt;osSunGetParam&amp;lt;/strike&amp;gt;]] - Use [[osGetSunParam]] &lt;br /&gt;
*[[osSunSetParam|&amp;lt;strike&amp;gt;osSunSetParam&amp;lt;/strike&amp;gt;]] - Use [[osSetSunParam]] &lt;br /&gt;
*[[osTerrainGetHeight|&amp;lt;strike&amp;gt;osTerrainGetHeight&amp;lt;/strike&amp;gt;]] - Use [[osGetTerrainHeight]] &lt;br /&gt;
*[[osTerrainSetHeight|&amp;lt;strike&amp;gt;osTerrainSetHeight&amp;lt;/strike&amp;gt;]] - Use [[osSetTerrainHeight]]&lt;br /&gt;
&lt;br /&gt;
== See Also  ==&lt;br /&gt;
&lt;br /&gt;
*[[LSL Status|LSL/OSSL Status Page]] &lt;br /&gt;
*OSSL &lt;br /&gt;
**[[OSSL_Implemented|OSSL Implemented Functions]] &lt;br /&gt;
**[[OSSL Constants|OSSL Constants]] &lt;br /&gt;
**[[OSSL Status/Types|OSSL Types Status Page]] &lt;br /&gt;
**[[OSSL Status/Events|OSSL Events Status Page]] &lt;br /&gt;
&lt;br /&gt;
**[[Dynamic_textures|OSSL osDynamicTextures Functions Index Page]]&lt;br /&gt;
**[[OSSL TextureDrawing|OSSL TextureDrawing Extended Information]]&lt;br /&gt;
**[[OSSLNPC|OSSL functions for working with NPCs]]&lt;br /&gt;
&lt;br /&gt;
**[[OSSL Proposals|OSSL Proposed Functions]] &lt;br /&gt;
**[[OSSL Enabling Functions]] &lt;br /&gt;
**[[OSSL Standards|OSSL Standards]]&lt;br /&gt;
&lt;br /&gt;
* LS&lt;br /&gt;
** [[LightShare#LightShare Scripting|LightShare Functions]]&lt;br /&gt;
&lt;br /&gt;
* MOD&lt;br /&gt;
** [[OSSL Script Library/ModSendCommand|modSendCommand()]]&lt;br /&gt;
** [[OSSL Script Library/ModInvoke|Custom functions using modInvoke()]]&lt;br /&gt;
&lt;br /&gt;
[[Category:OSSL]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Feature_Proposals/OsGetRegionSize</id>
		<title>Feature Proposals/OsGetRegionSize</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Feature_Proposals/OsGetRegionSize"/>
				<updated>2014-01-28T05:35:05Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Orenh moved page Feature Proposals/OsGetRegionSize to OsGetRegionSize&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#REDIRECT [[OsGetRegionSize]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OsGetRegionSize</id>
		<title>OsGetRegionSize</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OsGetRegionSize"/>
				<updated>2014-01-28T05:35:05Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Orenh moved page Feature Proposals/OsGetRegionSize to OsGetRegionSize&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{osslfunc&lt;br /&gt;
|threat_level=None&lt;br /&gt;
|function_syntax=vector osGetRegionSize()&lt;br /&gt;
|ossl_example=&amp;lt;source lang=&amp;quot;lsl&amp;quot;&amp;gt;&lt;br /&gt;
default&lt;br /&gt;
{&lt;br /&gt;
    touch_start(integer t)&lt;br /&gt;
    {&lt;br /&gt;
        llSay(0, &amp;quot;Region size: &amp;quot; + (string)osGetRegionSize());&lt;br /&gt;
    }&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
|description=Returns the size of the region in meters.&lt;br /&gt;
&lt;br /&gt;
Usually this function returns 256x256.&lt;br /&gt;
However, when called in a megaregion it returns the size of the megaregion.&lt;br /&gt;
|&lt;br /&gt;
}}&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OsGetRegionSize</id>
		<title>OsGetRegionSize</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OsGetRegionSize"/>
				<updated>2014-01-22T13:13:51Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{osslfunc&lt;br /&gt;
|threat_level=None&lt;br /&gt;
|function_syntax=vector osGetRegionSize()&lt;br /&gt;
|ossl_example=&amp;lt;source lang=&amp;quot;lsl&amp;quot;&amp;gt;&lt;br /&gt;
default&lt;br /&gt;
{&lt;br /&gt;
    touch_start(integer t)&lt;br /&gt;
    {&lt;br /&gt;
        llSay(0, &amp;quot;Region size: &amp;quot; + (string)osGetRegionSize());&lt;br /&gt;
    }&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
|description=Returns the size of the region in meters.&lt;br /&gt;
&lt;br /&gt;
Usually this function returns 256x256.&lt;br /&gt;
However, when called in a megaregion it returns the size of the megaregion.&lt;br /&gt;
|&lt;br /&gt;
}}&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OsGetRegionSize</id>
		<title>OsGetRegionSize</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OsGetRegionSize"/>
				<updated>2014-01-22T13:10:37Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{osslfunc&lt;br /&gt;
|threat_level=None&lt;br /&gt;
|function_syntax=vector osGetRegionSize()&lt;br /&gt;
|ossl_example=&amp;lt;source lang=&amp;quot;lsl&amp;quot;&amp;gt;&lt;br /&gt;
default&lt;br /&gt;
{&lt;br /&gt;
    touch_start(integer t)&lt;br /&gt;
    {&lt;br /&gt;
        llSay(0, &amp;quot;Region size: &amp;quot; + (string)osGetRegionSize());&lt;br /&gt;
    }&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
|description=Returns the size of the region in meters.&lt;br /&gt;
&lt;br /&gt;
Usually this function returns 256x256.&lt;br /&gt;
However, when called in the root region of a megaregion it returns the size of the megaregion.&lt;br /&gt;
|&lt;br /&gt;
}}&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OsGetRegionSize</id>
		<title>OsGetRegionSize</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OsGetRegionSize"/>
				<updated>2014-01-22T13:08:13Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Created page with &amp;quot;{{osslfunc |threat_level=None |function_syntax=vector osGetRegionSize() |ossl_example=&amp;lt;source lang=&amp;quot;lsl&amp;quot;&amp;gt; default {     touch(integer t)     {         llSay(0, &amp;quot;Region size: &amp;quot;...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{osslfunc&lt;br /&gt;
|threat_level=None&lt;br /&gt;
|function_syntax=vector osGetRegionSize()&lt;br /&gt;
|ossl_example=&amp;lt;source lang=&amp;quot;lsl&amp;quot;&amp;gt;&lt;br /&gt;
default&lt;br /&gt;
{&lt;br /&gt;
    touch(integer t)&lt;br /&gt;
    {&lt;br /&gt;
        llSay(0, &amp;quot;Region size: &amp;quot; + (string)osGetRegionSize());&lt;br /&gt;
    }&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
|description=Returns the size of the region in meters.&lt;br /&gt;
&lt;br /&gt;
Usually this function returns 256x256.&lt;br /&gt;
However, when called in the root region of a megaregion it returns the size of the megaregion.&lt;br /&gt;
|&lt;br /&gt;
}}&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Feature_Proposals</id>
		<title>Feature Proposals</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Feature_Proposals"/>
				<updated>2014-01-22T13:00:57Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Feature Proposals==&lt;br /&gt;
If you want to propose a feature, you should do so on the opensim-dev mailing list. If there is interest or if you plan to write the code yourself, you can create a page here. Please do not propose features in the Mantis bug tracker. Please do not propose features if you don't have a clear idea of how they would work on a technical level. Please do not propose features expecting other people to do the implementation work without convincing them first - this will not happen.&lt;br /&gt;
&lt;br /&gt;
Feature proposals must be created in conjunction with a post to the opensim-dev mailing list - if they are just created here then it's possible they will not get seen by other developers.&lt;br /&gt;
&lt;br /&gt;
If you're adding a proposal here, please do it with a page name of Feature_Proposals/&amp;lt;name of service&amp;gt;. For example Feature_Proposals/AutoBackup.&lt;br /&gt;
&lt;br /&gt;
=== Templates ===&lt;br /&gt;
&lt;br /&gt;
* [[Feature Proposal Template]] - Use this template for your document.&lt;br /&gt;
&lt;br /&gt;
=== Present ===&lt;br /&gt;
&lt;br /&gt;
* [[Feature Proposals/OsGetRegionSize]]&lt;br /&gt;
* [[Feature Proposals/Dynamic Attributes in Scene Objects]]&lt;br /&gt;
* [[Feature Proposals/Deduplicating Asset Service]]&lt;br /&gt;
* [[Feature Proposals/Improve Groups Service]]&lt;br /&gt;
* [[Feature Proposals/BulletSim_OpenCL]]&lt;br /&gt;
* [[IntegrationService]]&lt;br /&gt;
* [[RemoteAdmin:RemoteAdmin_Proposals]] - proposals for additional [[RemoteAdmin]] external methods.&lt;br /&gt;
&lt;br /&gt;
=== Past ===&lt;br /&gt;
&lt;br /&gt;
* [[Feature Proposals/Multi-Region OARs]]&lt;br /&gt;
* [[Feature Proposals/AutoBackup|AutoBackup]]&lt;br /&gt;
* [[Statistics Server]] - Proposal for a statistics server in OpenSimulator.&lt;br /&gt;
* [[OpenID]] - Proposal for using OpenID in OpenSimulator&lt;br /&gt;
* [[AssetServerProposal]] - Proposal for a distributed asset server&lt;br /&gt;
* [[A better SimCrossing]] - A work in progress about implementing a smooth simcrossing&lt;br /&gt;
* [[Creating profiles not used for login]] - RFC for alternative ways of creating profiles that will never be used for login&lt;br /&gt;
* [[OpenSim Profile Anchors]] - a mechanism for retaining creator information for offline item transfers&lt;br /&gt;
* [[Explicit Object Serialization]] - a proposal to explicitly serialize scene objects rather than using automatic .NET XML serialization&lt;br /&gt;
* [[Opensim: 0.5 Release Target Discussion]]&lt;br /&gt;
* [[Opensim: 0.6 Release Target Discussion]]&lt;br /&gt;
* [[Opensim: Future Release Discussion]]&lt;br /&gt;
* [[OpenWiredux: Taking the next step]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;br /&gt;
[[Category:Proposal]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Feature_Proposals/Dynamic_Attributes_in_Scene_Objects</id>
		<title>Feature Proposals/Dynamic Attributes in Scene Objects</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Feature_Proposals/Dynamic_Attributes_in_Scene_Objects"/>
				<updated>2013-01-22T10:58:54Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Status (draft, in progress, done or abandoned) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Date=&lt;br /&gt;
&lt;br /&gt;
Jan. 2, 2013&lt;br /&gt;
&lt;br /&gt;
= Status (draft, in progress, done or abandoned) =&lt;br /&gt;
&lt;br /&gt;
Patch submitted.&lt;br /&gt;
&lt;br /&gt;
= Proposers =&lt;br /&gt;
&lt;br /&gt;
Originally implemented by JustinCC in 2010.&lt;br /&gt;
&lt;br /&gt;
Being revived by Oren Hurvitz.&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
This is a proposal to add a way of attaching arbitrary data to any Scene Object. The feature has actually already been implemented by JustinCC, but it was never pushed to the master branch. I would like to move this feature into master, and fill in any missing functionality (e.g., serialization).&lt;br /&gt;
&lt;br /&gt;
= Proposal =&lt;br /&gt;
&lt;br /&gt;
Here's Justin's original message about this feature (from http://lists.berlios.de/pipermail/opensim-dev/2010-August/009166.html):&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Hi folks.  As I mentioned last week, I have now pushed a dynamic-attributes branch to the Git repository.  This is work &lt;br /&gt;
that I was experimenting with while doing media-on-a-prim.&lt;br /&gt;
&lt;br /&gt;
Essentially, this allows region modules to store and retrieve data on SceneObjectParts and PrimitiveBaseShapes without &lt;br /&gt;
adding new attributes to those core classes.&lt;br /&gt;
&lt;br /&gt;
Both SOP and PBS have an OSDMap property (which for various reasons is wrappered by OpenSim.Framework.DAMap).  Modules &lt;br /&gt;
can insert any class derived from libopenmetaverse's OSD class in this map (this includes OSDMap, OSDString, OSDInteger, &lt;br /&gt;
etc.  See the StructuredData.cs file in libopenmetavere's OpenMetaverse.StructuredData/ directory for more details.&lt;br /&gt;
&lt;br /&gt;
Persistence is achieved by [de]serializing this map to xml and storing it in a DynAttrs column in the database. &lt;br /&gt;
Persistence is implemented for sqlite, mysql and mssql.&lt;br /&gt;
&lt;br /&gt;
There is a small region module in OpenSim.Region.CoreModules/Framework/DynamicAttributes/DAExampleModule.cs that &lt;br /&gt;
demonstrates this.  Every time an object is moved in the scene, it adds 1 to SOP.DynamicAttributes[&amp;quot;moves&amp;quot;] and tells &lt;br /&gt;
all users in the region how many times the object has moved.  If the server is restarted, the number of moves is &lt;br /&gt;
restored on restart.&lt;br /&gt;
&lt;br /&gt;
It didn't take much code to achieve this.  However, as discussed previously, there is some awkardness in using OSD in &lt;br /&gt;
this way.  Any feedback on this or other aspects of dynamic attributes is appreciated.&lt;br /&gt;
&lt;br /&gt;
This branch is a 'technology preview' at most and should not be relied upon in production in any way whatsoever.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Feature_Proposals/Dynamic_Attributes_in_Scene_Objects</id>
		<title>Feature Proposals/Dynamic Attributes in Scene Objects</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Feature_Proposals/Dynamic_Attributes_in_Scene_Objects"/>
				<updated>2013-01-02T20:59:52Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Date=&lt;br /&gt;
&lt;br /&gt;
Jan. 2, 2013&lt;br /&gt;
&lt;br /&gt;
= Status (draft, in progress, done or abandoned) =&lt;br /&gt;
&lt;br /&gt;
This feature has been mostly implemented, in a separate branch. It is currently suspended for discussion.&lt;br /&gt;
&lt;br /&gt;
= Proposers =&lt;br /&gt;
&lt;br /&gt;
Originally implemented by JustinCC in 2010.&lt;br /&gt;
&lt;br /&gt;
Being revived by Oren Hurvitz.&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
This is a proposal to add a way of attaching arbitrary data to any Scene Object. The feature has actually already been implemented by JustinCC, but it was never pushed to the master branch. I would like to move this feature into master, and fill in any missing functionality (e.g., serialization).&lt;br /&gt;
&lt;br /&gt;
= Proposal =&lt;br /&gt;
&lt;br /&gt;
Here's Justin's original message about this feature (from http://lists.berlios.de/pipermail/opensim-dev/2010-August/009166.html):&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Hi folks.  As I mentioned last week, I have now pushed a dynamic-attributes branch to the Git repository.  This is work &lt;br /&gt;
that I was experimenting with while doing media-on-a-prim.&lt;br /&gt;
&lt;br /&gt;
Essentially, this allows region modules to store and retrieve data on SceneObjectParts and PrimitiveBaseShapes without &lt;br /&gt;
adding new attributes to those core classes.&lt;br /&gt;
&lt;br /&gt;
Both SOP and PBS have an OSDMap property (which for various reasons is wrappered by OpenSim.Framework.DAMap).  Modules &lt;br /&gt;
can insert any class derived from libopenmetaverse's OSD class in this map (this includes OSDMap, OSDString, OSDInteger, &lt;br /&gt;
etc.  See the StructuredData.cs file in libopenmetavere's OpenMetaverse.StructuredData/ directory for more details.&lt;br /&gt;
&lt;br /&gt;
Persistence is achieved by [de]serializing this map to xml and storing it in a DynAttrs column in the database. &lt;br /&gt;
Persistence is implemented for sqlite, mysql and mssql.&lt;br /&gt;
&lt;br /&gt;
There is a small region module in OpenSim.Region.CoreModules/Framework/DynamicAttributes/DAExampleModule.cs that &lt;br /&gt;
demonstrates this.  Every time an object is moved in the scene, it adds 1 to SOP.DynamicAttributes[&amp;quot;moves&amp;quot;] and tells &lt;br /&gt;
all users in the region how many times the object has moved.  If the server is restarted, the number of moves is &lt;br /&gt;
restored on restart.&lt;br /&gt;
&lt;br /&gt;
It didn't take much code to achieve this.  However, as discussed previously, there is some awkardness in using OSD in &lt;br /&gt;
this way.  Any feedback on this or other aspects of dynamic attributes is appreciated.&lt;br /&gt;
&lt;br /&gt;
This branch is a 'technology preview' at most and should not be relied upon in production in any way whatsoever.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Feature_Proposals/Dynamic_Attributes_in_Scene_Objects</id>
		<title>Feature Proposals/Dynamic Attributes in Scene Objects</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Feature_Proposals/Dynamic_Attributes_in_Scene_Objects"/>
				<updated>2013-01-02T20:56:41Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Created page with &amp;quot;This is a proposal to add a way of attaching arbitrary data to any Scene Object. The feature has actually already been implemented by JustinCC, but it was never pushed to the mas...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a proposal to add a way of attaching arbitrary data to any Scene Object. The feature has actually already been implemented by JustinCC, but it was never pushed to the master branch. I would like to move this feature into master, and fill in any missing functionality (e.g., serialization).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here's Justin's original message about this feature (from http://lists.berlios.de/pipermail/opensim-dev/2010-August/009166.html):&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Hi folks.  As I mentioned last week, I have now pushed a dynamic-attributes branch to the Git repository.  This is work &lt;br /&gt;
that I was experimenting with while doing media-on-a-prim.&lt;br /&gt;
&lt;br /&gt;
Essentially, this allows region modules to store and retrieve data on SceneObjectParts and PrimitiveBaseShapes without &lt;br /&gt;
adding new attributes to those core classes.&lt;br /&gt;
&lt;br /&gt;
Both SOP and PBS have an OSDMap property (which for various reasons is wrappered by OpenSim.Framework.DAMap).  Modules &lt;br /&gt;
can insert any class derived from libopenmetaverse's OSD class in this map (this includes OSDMap, OSDString, OSDInteger, &lt;br /&gt;
etc.  See the StructuredData.cs file in libopenmetavere's OpenMetaverse.StructuredData/ directory for more details.&lt;br /&gt;
&lt;br /&gt;
Persistence is achieved by [de]serializing this map to xml and storing it in a DynAttrs column in the database. &lt;br /&gt;
Persistence is implemented for sqlite, mysql and mssql.&lt;br /&gt;
&lt;br /&gt;
There is a small region module in OpenSim.Region.CoreModules/Framework/DynamicAttributes/DAExampleModule.cs that &lt;br /&gt;
demonstrates this.  Every time an object is moved in the scene, it adds 1 to SOP.DynamicAttributes[&amp;quot;moves&amp;quot;] and tells &lt;br /&gt;
all users in the region how many times the object has moved.  If the server is restarted, the number of moves is &lt;br /&gt;
restored on restart.&lt;br /&gt;
&lt;br /&gt;
It didn't take much code to achieve this.  However, as discussed previously, there is some awkardness in using OSD in &lt;br /&gt;
this way.  Any feedback on this or other aspects of dynamic attributes is appreciated.&lt;br /&gt;
&lt;br /&gt;
This branch is a 'technology preview' at most and should not be relied upon in production in any way whatsoever.&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Feature_Proposals</id>
		<title>Feature Proposals</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Feature_Proposals"/>
				<updated>2013-01-02T20:51:09Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Feature Proposals==&lt;br /&gt;
If you want to propose a feature, you should do so on the opensim-dev mailing list. If there is interest or if you plan to write the code yourself, you can create a page here. Please do not propose features in the Mantis bug tracker. Please do not propose features if you don't have a clear idea of how they would work on a technical level. Please do not propose features expecting other people to do the implementation work without convincing them first - this will not happen.&lt;br /&gt;
&lt;br /&gt;
Feature proposals must be created in conjunction with a post to the opensim-dev mailing list - if they are just created here then it's possible they will not get seen by other developers.&lt;br /&gt;
&lt;br /&gt;
If you're adding a proposal here, please do it with a page name of Feature_Proposals/&amp;lt;name of service&amp;gt;. For example Feature_Proposals/AutoBackup.&lt;br /&gt;
&lt;br /&gt;
=== Templates ===&lt;br /&gt;
&lt;br /&gt;
* [[Feature Proposal Template]] - Use this template for your document.&lt;br /&gt;
&lt;br /&gt;
=== Present ===&lt;br /&gt;
&lt;br /&gt;
* [[Feature Proposals/Dynamic Attributes in Scene Objects]]&lt;br /&gt;
* [[Feature Proposals/Deduplicating Asset Service]]&lt;br /&gt;
* [[Feature Proposals/Improve Groups Service]]&lt;br /&gt;
* [[IntegrationService]]&lt;br /&gt;
&lt;br /&gt;
=== Past ===&lt;br /&gt;
&lt;br /&gt;
* [[Feature Proposals/Multi-Region OARs]]&lt;br /&gt;
* [[Feature Proposals/AutoBackup|AutoBackup]]&lt;br /&gt;
* [[Statistics Server]] - Proposal for a statistics server in OpenSimulator.&lt;br /&gt;
* [[OpenID]] - Proposal for using OpenID in OpenSimulator&lt;br /&gt;
* [[AssetServerProposal]] - Proposal for a distributed asset server&lt;br /&gt;
* [[A better SimCrossing]] - A work in progress about implementing a smooth simcrossing&lt;br /&gt;
* [[Creating profiles not used for login]] - RFC for alternative ways of creating profiles that will never be used for login&lt;br /&gt;
* [[OpenSim Profile Anchors]] - a mechanism for retaining creator information for offline item transfers&lt;br /&gt;
* [[Explicit Object Serialization]] - a proposal to explicitly serialize scene objects rather than using automatic .NET XML serialization&lt;br /&gt;
* [[Opensim: 0.5 Release Target Discussion]]&lt;br /&gt;
* [[Opensim: 0.6 Release Target Discussion]]&lt;br /&gt;
* [[Opensim: Future Release Discussion]]&lt;br /&gt;
* [[OpenWiredux: Taking the next step]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;br /&gt;
[[Category:Proposal]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Feature_Proposals/Multi-Region_OARs</id>
		<title>Feature Proposals/Multi-Region OARs</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Feature_Proposals/Multi-Region_OARs"/>
				<updated>2012-10-07T08:16:02Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''UPDATE: this feature has been implemented. See [[OAR Format 1.0]].'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This feature extends the OAR format to allow saving multiple regions in a single file.&lt;br /&gt;
&lt;br /&gt;
The save-oar command still creates single-region OARs by default (OAR version 0.8). It saves the new format if the &amp;quot;--all&amp;quot; parameter is specified. The new format has version number 1.0 because older versions of OpenSim can't read it.&lt;br /&gt;
&lt;br /&gt;
The load-oar command supports both OAR formats (0.x and 1.x). When it's given a 1.x OAR file it loads all the regions in the OAR into the corresponding regions in the simulator, according to their position relative to the root region. If the simulator doesn't have a region in a location that is present in the OAR then that region isn't loaded.&lt;br /&gt;
&lt;br /&gt;
The layout of the OAR file is as follows. Each region is stored in a separate directory, but the assets are shared:&lt;br /&gt;
&lt;br /&gt;
 archive.xml&lt;br /&gt;
 assets/&lt;br /&gt;
 regions/&lt;br /&gt;
   1_1_Arizona/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
   2_1_New_Mexico/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
   1_2_Utah/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
   2_2_Colorado/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
&lt;br /&gt;
The regions' directory names include the region's location (relative to the root region) in order to ensure uniqueness even if regions have duplicate names.&lt;br /&gt;
&lt;br /&gt;
The file archive.xml contains a manifest of the included regions. The list of regions always describes a rectangle, with the root region (the region where the &amp;quot;save-oar&amp;quot; command was run) in the SW corner. The regions are listed in the following order: rows from South to North, and within each row regions are listed West-to-East. Missing regions are supported: they're represented by empty elements.&lt;br /&gt;
&lt;br /&gt;
For example:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-16&amp;quot;?&amp;gt;&lt;br /&gt;
 &amp;lt;archive major_version=&amp;quot;1&amp;quot; minor_version=&amp;quot;0&amp;quot;&amp;gt;&lt;br /&gt;
   &amp;lt;creation_info&amp;gt;&lt;br /&gt;
     &amp;lt;datetime&amp;gt;1343204139&amp;lt;/datetime&amp;gt;&lt;br /&gt;
   &amp;lt;/creation_info&amp;gt;&lt;br /&gt;
   &amp;lt;assets_included&amp;gt;True&amp;lt;/assets_included&amp;gt;&lt;br /&gt;
   &amp;lt;regions&amp;gt;&lt;br /&gt;
     &amp;lt;row&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-1111-1111-1111-111111111111&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;1_1_Arizona&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-2222-2222-2222-222222222222&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;2_1_New_Mexico&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
     &amp;lt;/row&amp;gt;&lt;br /&gt;
     &amp;lt;row&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-3333-3333-3333-333333333333&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;1_2_Utah&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-4444-4444-4444-444444444444&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;2_2_Colorado&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
     &amp;lt;/row&amp;gt;&lt;br /&gt;
   &amp;lt;/regions&amp;gt;&lt;br /&gt;
 &amp;lt;/archive&amp;gt;&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OpenSim_Archives</id>
		<title>OpenSim Archives</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OpenSim_Archives"/>
				<updated>2012-09-23T07:11:38Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* How do I use the OpenSimulator Archive Function? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= How do I use the OpenSimulator Archive Function? =&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
The OpenSimulator Archive (OAR) function has existed since OpenSimulator 0.5.9. The facility does a similar job to load-xml2/save-xml2 in that it saves prims so that they can be later reloaded. However, OpenSimulator archives (OAR) go a step further in that they can save all the necessary asset data so that you may fully restore the terrain, region parcel data, the textures of objects and their inventories when loaded onto a completely different system using a different asset database.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
From the region console, one can type &lt;br /&gt;
&lt;br /&gt;
 save oar [--noassets] [-h|--home=&amp;amp;lt;url&amp;amp;gt;] [--publish] [--perm=&amp;amp;lt;permissions&amp;amp;gt;] [--all] [&amp;amp;lt;filename&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
to save an OpenSimulator archive. If no filename is given, then the name region.oar is used in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 save oar&lt;br /&gt;
 save oar my.oar&lt;br /&gt;
 save oar c:/mybackups/filename.oar&lt;br /&gt;
 save oar oars/11nov.oar&lt;br /&gt;
&lt;br /&gt;
To load an archive, type &lt;br /&gt;
&lt;br /&gt;
 load oar [--merge] [--skip-assets] [&amp;amp;lt;location&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
at the console. The location can be a filesystem path (as for &amp;quot;save oar&amp;quot;) or an HTTP address to load an oar directly over the web. If no location is given, then the server looks for a file called region.oar in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 load oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar --merge oars/3rd-party.oar&lt;br /&gt;
 load oar http://path.to/oarfile.oar&lt;br /&gt;
&lt;br /&gt;
By default, loading an archive will delete all the existing objects in the regions and replace them with the archive contents. It's like being in the Matrix (when they swap environments), except much slower (all the scene objects are slowly deleted before the new environment is loaded&amp;amp;nbsp;:-) &lt;br /&gt;
&lt;br /&gt;
When an archive is loaded, owners will be restored if the relevant uuids can be found in the OpenSimulator installation's user database. Otherwise, prim ownership will default to the master avatar for the region. &lt;br /&gt;
&lt;br /&gt;
I recommend that you use filenames with the extension '''.oar'''. The filename extension of the download links on this page is '''.tar.gz''' which illustrates that the '''.oar''' format is actually a zipped tar file.&lt;br /&gt;
&lt;br /&gt;
=== Switches ===&lt;br /&gt;
==== Saving ====&lt;br /&gt;
&lt;br /&gt;
===== --publish =====&lt;br /&gt;
&lt;br /&gt;
If set, then objects in the saved oar are stripped of owner and last owner information, though not of creator information.&lt;br /&gt;
&lt;br /&gt;
This is useful if you are publishing OARs (rather than using them for backup) where those OARs might be loaded to the same grid from which you published.&lt;br /&gt;
&lt;br /&gt;
As of OpenSimulator 0.7.4, this switch will also strip ownership information from land parcels.&lt;br /&gt;
&lt;br /&gt;
===== --noassets =====&lt;br /&gt;
&lt;br /&gt;
If the --noassets option is specified then the oar will be saved without assets. This can be handy if you're backing up the asset database separately and don't want the expense of including all the assets in each OAR.&lt;br /&gt;
&lt;br /&gt;
===== --home =====&lt;br /&gt;
&lt;br /&gt;
(formerly known as --profile up to 0.7.3)&lt;br /&gt;
&lt;br /&gt;
If the --home option is specified then all names of creators from this world will be appended with links to their home world. It is not required that the service be operational; the information will be added and it will be available in all worlds that import this OAR.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;url&amp;gt; is the URL of this world's profile service. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --home=http://mygrid.com my.oar&lt;br /&gt;
&lt;br /&gt;
===== --perm =====&lt;br /&gt;
&lt;br /&gt;
If the --perm option is specified then objects with insufficient permissions will not be saved to the OAR. The user whose permissions are checked is the estate owner. This can be useful for grids that allow their customers to export their regions to OARs, because it ensures that exporting to OAR can't be used to bypass content permissions.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;permissions&amp;gt; specifies which permissions are required. It's a string that contains one or more of these characters:&lt;br /&gt;
* &amp;quot;C&amp;quot; = Copy&lt;br /&gt;
* &amp;quot;T&amp;quot; = Transfer&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --perm=CT my.oar&lt;br /&gt;
&lt;br /&gt;
===== --all =====&lt;br /&gt;
&lt;br /&gt;
If the --all option is specified then the OAR will contain all the regions in the simulator. If this option isn't specified (which is the default) then the OAR will contain only the current region.&lt;br /&gt;
&lt;br /&gt;
==== Loading ====&lt;br /&gt;
&lt;br /&gt;
===== --skip-assets =====&lt;br /&gt;
&lt;br /&gt;
If set, this will not attempt to load any of the assets from the OAR, though all other data will be loaded.  This can be useful if you are loading the OAR back into a grid that you know already contains the assets.&lt;br /&gt;
&lt;br /&gt;
===== --merge =====&lt;br /&gt;
&lt;br /&gt;
If the --merge option is specified then the oar will be merged with the existing region objects rather than replace them. The existing terrain, region settings and parcels will be left in place.&lt;br /&gt;
&lt;br /&gt;
== Multi-Region OARs ==&lt;br /&gt;
&lt;br /&gt;
By default, the save-oar command saves only the current region into the OAR (using OAR Format 0.8). However, if the --all option is specified then all the regions in the simulator are saved into a multi-region OAR file (using OAR Format 1.0). This is useful when saving a build that spans multiple regions.&lt;br /&gt;
&lt;br /&gt;
The load-oar command supports both OAR formats (0.x and 1.x). When it's given a 1.x OAR file it loads all the regions in the OAR into the corresponding regions in the simulator, according to their position relative to the root region. If the simulator doesn't have a region in a location that is present in the OAR then that region isn't loaded.&lt;br /&gt;
&lt;br /&gt;
For historical context, see [[Feature_Proposals/Multi-Region_OARs]] and [http://opensimulator.org/mantis/view.php?id=6105 Mantis 6105]&lt;br /&gt;
&lt;br /&gt;
==== OAR Format Compatibility ====&lt;br /&gt;
&lt;br /&gt;
OAR Format 1.0 isn't backwards-compatible, so it can only be read in OpenSim 0.7.5 and above. However, since most current instances of OpenSim can't read this format, there is a transition period in which OpenSim still saves single-region OARs using OAR Format 0.8. This means that the most common behavior (save-oar for a single region) creates OARs that are readable by all instances of OpenSim. The new OAR Format 1.0 is only used when using the --all option.&lt;br /&gt;
&lt;br /&gt;
== Example OARs ==&lt;br /&gt;
&lt;br /&gt;
[http://www.secondlifelab.it/downloads/cyberlandia.tar.gz cyberlandia.tar.gz] - cyberlandia landscape designed by the architect Simone Riccardi aka turboy. Contemporary architecture surrounded with a natural/synthetic context [http://www.flickr.com/photos/8905571@N05/3182585775/ image_1] [http://www.flickr.com/photos/8905571@N05/3171070049/ image_2] (work under [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons by attribution]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== OpenVCE 3D Assets OAR ===&lt;br /&gt;
&lt;br /&gt;
The [http://openvce.net OpenVCE.net] virtual worlds assets described at http://openvce.net/vwassets provided by Clever Zebra and the OpenVCE.net team at AIAI in the University of Edinburgh are available as an OAR (Opensim Archive) file.&lt;br /&gt;
&lt;br /&gt;
 http://openvce.net/resources/downloads/&lt;br /&gt;
&lt;br /&gt;
Get file &amp;quot;opensim-openvce.oar&amp;quot; from there (right click on the file in the above directory in your browser, and select download is the easiest way to obtain the materials). A &amp;quot;full&amp;quot; set of the buildings with a large 400 seat amphitheatre intended to be placed on the corner of 4 sims is also available via &amp;quot;opensim-openvce-full.oar&amp;quot;. Images of the buildings in place in Opensim are at:&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-1.jpg Image 1],&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-2.jpg Image 2]&lt;br /&gt;
&lt;br /&gt;
=== Others ===&lt;br /&gt;
&lt;br /&gt;
Please feel free to place links to other environments here, though unfortunately you'll have to host them on some other site. &lt;br /&gt;
&lt;br /&gt;
[http://www.hypergridbusiness.com/2011/06/where-to-get-content-for-opensim/ Where to get content for OpenSim]&amp;amp;nbsp;-- Hypergrid Business page, regularly updated, containing links to major OAR sites. Also has download links to individual OAR files. &lt;br /&gt;
&lt;br /&gt;
[http://www.lindakellie.com/myoars.htm LindaKellie.com] &lt;br /&gt;
&lt;br /&gt;
[http://opensim-creations.com/category/regions/oars/ OpenSimulator Creations] &lt;br /&gt;
&lt;br /&gt;
[http://www.opensimworlds.com/index.php?part=worlds http://www.opensimworlds.com/index.php?part=worlds]&lt;br /&gt;
&lt;br /&gt;
[http://forums.osgrid.org/viewforum.php?f=20 http://forums.osgrid.org/viewforum.php]&lt;br /&gt;
&lt;br /&gt;
== Further Information ==&lt;br /&gt;
&lt;br /&gt;
* [http://justincc.org/blog/category/oars/ http://justincc.org/blog/category/oars/] - various OAR related articles from justincc, including background information and possible future development.&lt;br /&gt;
&lt;br /&gt;
== Use cases ==&lt;br /&gt;
&lt;br /&gt;
Possible current uses are&lt;br /&gt;
&lt;br /&gt;
1. To migrate data from an SQLite region database to one based on MySQL&lt;br /&gt;
&lt;br /&gt;
2. To distribute entire regions to other people.&lt;br /&gt;
&lt;br /&gt;
== Current limitations ==&lt;br /&gt;
&lt;br /&gt;
* Performance is not very good, especially with large archives. This will be addressed in the future&lt;br /&gt;
* Loading large OARs using the default SQLite database plugin will take a very very long time (in the order of many hours). I highly recommend that you switch to MySQL if you want to load large archives.&lt;br /&gt;
&lt;br /&gt;
== OAR Format ==&lt;br /&gt;
&lt;br /&gt;
The region [[OpenSim Archives|OpenSimulator Archive (OAR)]] format is designed with three aims in mind:&lt;br /&gt;
&lt;br /&gt;
# Make it easy for people to read and change individual objects, assets, etc. within an archive.&lt;br /&gt;
# Make it easy to compose two region archives into a single region archive.&lt;br /&gt;
# Make it easy to compose archives from scratch.&lt;br /&gt;
&lt;br /&gt;
Therefore, all the different entities (assets, objects, terrains, etc.) are packaged in individual files (e.g. one for each asset) with human readable filenames and machine readable extensions (e.g. .jp2 for textures, .txt for notecards).&lt;br /&gt;
&lt;br /&gt;
* [[OAR Format 0.1]]&lt;br /&gt;
* [[OAR Format 0.2]]&lt;br /&gt;
* [[OAR Format 0.6]]&lt;br /&gt;
* [[OAR Format 0.7]]&lt;br /&gt;
* [[OAR Format 0.8]]&lt;br /&gt;
* [[OAR Format 1.0]]&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
1. What is this .tar.gz format you are using for the internal OAR format? Why not zip?&lt;br /&gt;
&lt;br /&gt;
.tar.gz is a standard unix way of zipping up files into a single larger compressed file for distribution. Windows users should be able to open these files using freeware programs such as [http://www.7-zip.org/ 7-zip]. &lt;br /&gt;
&lt;br /&gt;
I'm using .tar.gz because all the zip (and tar) libraries for .net are licensed either under the GPL (with exception) or under the MSPL. Unfortunately, not all members of the OpenSimulator development team are comfortable with the MSPL, so these libaries are not currently an option. It is also significantly easier to write code to create and read tar archives than zip archives.&lt;br /&gt;
&lt;br /&gt;
Also, if you're only ever loading and saving oars (rather than pulling them apart and putting them back together), then you don't need to worry about the internal format at all :)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2. Can you load and save multiple regions to an archive?&lt;br /&gt;
&lt;br /&gt;
Yes, since OpenSim 0.7.5. See [[OpenSim Archives#Multi-Region OARs]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3. Can you load and save parts of a region to an archive?&lt;br /&gt;
&lt;br /&gt;
Not yet.&lt;br /&gt;
&lt;br /&gt;
== Bugs ==&lt;br /&gt;
&lt;br /&gt;
* Due to a possible bug in the Mono 1.2.4 libraries, this feature may cause a debug dump when used (the problem appears to be in writing out a compressed stream). Mono 1.2.6 is okay. Since Mono 1.2.4 is fairly old now, this bug will not be addressed.&lt;br /&gt;
&lt;br /&gt;
== Current Status ==&lt;br /&gt;
&lt;br /&gt;
Operational. Bug reports are appreciated [[User:Justincc|Justincc]] 14:53, 14 September 2009 (UTC)&lt;br /&gt;
&lt;br /&gt;
Though we will strive to maintain compatibilty for old archives with newer OpenSimulator versions, please don't rely on these archives as the only backup for regions.&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OpenSim_Archives</id>
		<title>OpenSim Archives</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OpenSim_Archives"/>
				<updated>2012-09-23T06:43:31Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Multi-Region OARs */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= How do I use the OpenSimulator Archive Function? =&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
The OpenSimulator Archive (OAR) function has existed since OpenSimulator 0.5.9. The facility does a similar job to load-xml2/save-xml2 in that it saves prims so that they can be later reloaded. However, OpenSimulator archives (OAR) go a step further in that they can save all the necessary asset data so that you may fully restore the terrain, region parcel data, the textures of objects and their inventories when loaded onto a completely different system using a different asset database.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
From the region console, one can type &lt;br /&gt;
&lt;br /&gt;
 save oar [--noassets] [-h|--home=&amp;amp;lt;url&amp;amp;gt;] [--publish] [--perm=&amp;amp;lt;permissions&amp;amp;gt;] [--all] [&amp;amp;lt;filename&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
to save an OpenSimulator archive. If no filename is given, then the name region.oar is used in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 save oar&lt;br /&gt;
 save oar my.oar&lt;br /&gt;
 save oar c:/mybackups/filename.oar&lt;br /&gt;
 save oar oars/11nov.oar&lt;br /&gt;
&lt;br /&gt;
To load an archive, type &lt;br /&gt;
&lt;br /&gt;
 load oar [--merge] [--skip-assets] [&amp;amp;lt;location&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
at the console. The location can be a filesystem path (as for &amp;quot;save oar&amp;quot;) or an HTTP address to load an oar directly over the web. If no location is given, then the server looks for a file called region.oar in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 load oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar --merge oars/3rd-party.oar&lt;br /&gt;
 load oar http://path.to/oarfile.oar&lt;br /&gt;
&lt;br /&gt;
By default, loading an archive will delete all the existing objects in the regions and replace them with the archive contents. It's like being in the Matrix (when they swap environments), except much slower (all the scene objects are slowly deleted before the new environment is loaded&amp;amp;nbsp;:-) &lt;br /&gt;
&lt;br /&gt;
When an archive is loaded, owners will be restored if the relevant uuids can be found in the OpenSimulator installation's user database. Otherwise, prim ownership will default to the master avatar for the region. &lt;br /&gt;
&lt;br /&gt;
I recommend that you use filenames with the extension '''.oar'''. The filename extension of the download links on this page is '''.tar.gz''' which illustrates that the '''.oar''' format is actually a zipped tar file.&lt;br /&gt;
&lt;br /&gt;
=== Switches ===&lt;br /&gt;
==== Saving ====&lt;br /&gt;
&lt;br /&gt;
===== --publish =====&lt;br /&gt;
&lt;br /&gt;
If set, then objects in the saved oar are stripped of owner and last owner information, though not of creator information.&lt;br /&gt;
&lt;br /&gt;
This is useful if you are publishing OARs (rather than using them for backup) where those OARs might be loaded to the same grid from which you published.&lt;br /&gt;
&lt;br /&gt;
As of OpenSimulator 0.7.4, this switch will also strip ownership information from land parcels.&lt;br /&gt;
&lt;br /&gt;
===== --noassets =====&lt;br /&gt;
&lt;br /&gt;
If the --noassets option is specified then the oar will be saved without assets. This can be handy if you're backing up the asset database separately and don't want the expense of including all the assets in each OAR.&lt;br /&gt;
&lt;br /&gt;
===== --home =====&lt;br /&gt;
&lt;br /&gt;
(formerly known as --profile up to 0.7.3)&lt;br /&gt;
&lt;br /&gt;
If the --home option is specified then all names of creators from this world will be appended with links to their home world. It is not required that the service be operational; the information will be added and it will be available in all worlds that import this OAR.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;url&amp;gt; is the URL of this world's profile service. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --home=http://mygrid.com my.oar&lt;br /&gt;
&lt;br /&gt;
===== --perm =====&lt;br /&gt;
&lt;br /&gt;
If the --perm option is specified then objects with insufficient permissions will not be saved to the OAR. The user whose permissions are checked is the estate owner. This can be useful for grids that allow their customers to export their regions to OARs, because it ensures that exporting to OAR can't be used to bypass content permissions.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;permissions&amp;gt; specifies which permissions are required. It's a string that contains one or more of these characters:&lt;br /&gt;
* &amp;quot;C&amp;quot; = Copy&lt;br /&gt;
* &amp;quot;T&amp;quot; = Transfer&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --perm=CT my.oar&lt;br /&gt;
&lt;br /&gt;
===== --all =====&lt;br /&gt;
&lt;br /&gt;
If the --all option is specified then the OAR will contain all the regions in the simulator. If this option isn't specified (which is the default) then the OAR will contain only the current region.&lt;br /&gt;
&lt;br /&gt;
==== Loading ====&lt;br /&gt;
&lt;br /&gt;
===== --skip-assets =====&lt;br /&gt;
&lt;br /&gt;
If set, this will not attempt to load any of the assets from the OAR, though all other data will be loaded.  This can be useful if you are loading the OAR back into a grid that you know already contains the assets.&lt;br /&gt;
&lt;br /&gt;
===== --merge =====&lt;br /&gt;
&lt;br /&gt;
If the --merge option is specified then the oar will be merged with the existing region objects rather than replace them. The existing terrain, region settings and parcels will be left in place.&lt;br /&gt;
&lt;br /&gt;
== Multi-Region OARs ==&lt;br /&gt;
&lt;br /&gt;
By default, the save-oar command saves only the current region into the OAR (using OAR Format 0.8). However, if the --all option is specified then all the regions in the simulator are saved into a multi-region OAR file (using OAR Format 1.0). This is useful when saving a build that spans multiple regions.&lt;br /&gt;
&lt;br /&gt;
The load-oar command supports both OAR formats (0.x and 1.x). When it's given a 1.x OAR file it loads all the regions in the OAR into the corresponding regions in the simulator, according to their position relative to the root region. If the simulator doesn't have a region in a location that is present in the OAR then that region isn't loaded.&lt;br /&gt;
&lt;br /&gt;
For historical context, see [[Feature_Proposals/Multi-Region_OARs]] and [http://opensimulator.org/mantis/view.php?id=6105 Mantis 6105]&lt;br /&gt;
&lt;br /&gt;
==== OAR Format Compatibility ====&lt;br /&gt;
&lt;br /&gt;
OAR Format 1.0 isn't backwards-compatible, so it can only be read in OpenSim 0.7.5 and above. However, since most current instances of OpenSim can't read this format, there is a transition period in which OpenSim still saves single-region OARs using OAR Format 0.8. This means that the most common behavior (save-oar for a single region) creates OARs that are readable by all instances of OpenSim. The new OAR Format 1.0 is only used when using the --all option.&lt;br /&gt;
&lt;br /&gt;
== Example OARs ==&lt;br /&gt;
&lt;br /&gt;
[http://www.secondlifelab.it/downloads/cyberlandia.tar.gz cyberlandia.tar.gz] - cyberlandia landscape designed by the architect Simone Riccardi aka turboy. Contemporary architecture surrounded with a natural/synthetic context [http://www.flickr.com/photos/8905571@N05/3182585775/ image_1] [http://www.flickr.com/photos/8905571@N05/3171070049/ image_2] (work under [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons by attribution]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== OpenVCE 3D Assets OAR ===&lt;br /&gt;
&lt;br /&gt;
The [http://openvce.net OpenVCE.net] virtual worlds assets described at http://openvce.net/vwassets provided by Clever Zebra and the OpenVCE.net team at AIAI in the University of Edinburgh are available as an OAR (Opensim Archive) file.&lt;br /&gt;
&lt;br /&gt;
 http://openvce.net/resources/downloads/&lt;br /&gt;
&lt;br /&gt;
Get file &amp;quot;opensim-openvce.oar&amp;quot; from there (right click on the file in the above directory in your browser, and select download is the easiest way to obtain the materials). A &amp;quot;full&amp;quot; set of the buildings with a large 400 seat amphitheatre intended to be placed on the corner of 4 sims is also available via &amp;quot;opensim-openvce-full.oar&amp;quot;. Images of the buildings in place in Opensim are at:&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-1.jpg Image 1],&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-2.jpg Image 2]&lt;br /&gt;
&lt;br /&gt;
=== Others ===&lt;br /&gt;
&lt;br /&gt;
Please feel free to place links to other environments here, though unfortunately you'll have to host them on some other site. &lt;br /&gt;
&lt;br /&gt;
[http://www.hypergridbusiness.com/2011/06/where-to-get-content-for-opensim/ Where to get content for OpenSim]&amp;amp;nbsp;-- Hypergrid Business page, regularly updated, containing links to major OAR sites. Also has download links to individual OAR files. &lt;br /&gt;
&lt;br /&gt;
[http://www.lindakellie.com/myoars.htm LindaKellie.com] &lt;br /&gt;
&lt;br /&gt;
[http://opensim-creations.com/category/regions/oars/ OpenSimulator Creations] &lt;br /&gt;
&lt;br /&gt;
[http://www.opensimworlds.com/index.php?part=worlds http://www.opensimworlds.com/index.php?part=worlds]&lt;br /&gt;
&lt;br /&gt;
[http://forums.osgrid.org/viewforum.php?f=20 http://forums.osgrid.org/viewforum.php]&lt;br /&gt;
&lt;br /&gt;
== Further Information ==&lt;br /&gt;
&lt;br /&gt;
* [http://justincc.org/blog/category/oars/ http://justincc.org/blog/category/oars/] - various OAR related articles from justincc, including background information and possible future development.&lt;br /&gt;
&lt;br /&gt;
== Use cases ==&lt;br /&gt;
&lt;br /&gt;
Possible current uses are&lt;br /&gt;
&lt;br /&gt;
1. To migrate data from an SQLite region database to one based on MySQL&lt;br /&gt;
&lt;br /&gt;
2. To distribute entire regions to other people.&lt;br /&gt;
&lt;br /&gt;
== Current limitations ==&lt;br /&gt;
&lt;br /&gt;
* Performance is not very good, especially with large archives. This will be addressed in the future&lt;br /&gt;
* Loading large OARs using the default SQLite database plugin will take a very very long time (in the order of many hours). I highly recommend that you switch to MySQL if you want to load large archives.&lt;br /&gt;
&lt;br /&gt;
== OAR Format ==&lt;br /&gt;
&lt;br /&gt;
The region [[OpenSim Archives|OpenSimulator Archive (OAR)]] format is designed with three aims in mind:&lt;br /&gt;
&lt;br /&gt;
# Make it easy for people to read and change individual objects, assets, etc. within an archive.&lt;br /&gt;
# Make it easy to compose two region archives into a single region archive.&lt;br /&gt;
# Make it easy to compose archives from scratch.&lt;br /&gt;
&lt;br /&gt;
Therefore, all the different entities (assets, objects, terrains, etc.) are packaged in individual files (e.g. one for each asset) with human readable filenames and machine readable extensions (e.g. .jp2 for textures, .txt for notecards).&lt;br /&gt;
&lt;br /&gt;
* [[OAR Format 0.1]]&lt;br /&gt;
* [[OAR Format 0.2]]&lt;br /&gt;
* [[OAR Format 0.6]]&lt;br /&gt;
* [[OAR Format 0.7]]&lt;br /&gt;
* [[OAR Format 0.8]]&lt;br /&gt;
* [[OAR Format 1.0]]&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
1. What is this .tar.gz format you are using for the internal OAR format? Why not zip?&lt;br /&gt;
&lt;br /&gt;
.tar.gz is a standard unix way of zipping up files into a single larger compressed file for distribution. Windows users should be able to open these files using freeware programs such as [http://www.7-zip.org/ 7-zip]. &lt;br /&gt;
&lt;br /&gt;
I'm using .tar.gz because all the zip (and tar) libraries for .net are licensed either under the GPL (with exception) or under the MSPL. Unfortunately, not all members of the OpenSimulator development team are comfortable with the MSPL, so these libaries are not currently an option. It is also significantly easier to write code to create and read tar archives than zip archives.&lt;br /&gt;
&lt;br /&gt;
Also, if you're only ever loading and saving oars (rather than pulling them apart and putting them back together), then you don't need to worry about the internal format at all :)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2. Can you load and save multiple regions to an archive?&lt;br /&gt;
&lt;br /&gt;
[[Feature_Proposals/Multi-Region_OARs|Present in development code, will be released in OpenSimulator 0.7.5.  Considered experimental.]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3. Can you load and save parts of a region to an archive?&lt;br /&gt;
&lt;br /&gt;
Not yet.&lt;br /&gt;
&lt;br /&gt;
== Bugs ==&lt;br /&gt;
&lt;br /&gt;
* Due to a possible bug in the Mono 1.2.4 libraries, this feature may cause a debug dump when used (the problem appears to be in writing out a compressed stream). Mono 1.2.6 is okay. Since Mono 1.2.4 is fairly old now, this bug will not be addressed.&lt;br /&gt;
&lt;br /&gt;
== Current Status ==&lt;br /&gt;
&lt;br /&gt;
Operational. Bug reports are appreciated [[User:Justincc|Justincc]] 14:53, 14 September 2009 (UTC)&lt;br /&gt;
&lt;br /&gt;
Though we will strive to maintain compatibilty for old archives with newer OpenSimulator versions, please don't rely on these archives as the only backup for regions.&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OpenSim_Archives</id>
		<title>OpenSim Archives</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OpenSim_Archives"/>
				<updated>2012-09-23T06:41:23Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* How do I use the OpenSimulator Archive Function? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= How do I use the OpenSimulator Archive Function? =&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
The OpenSimulator Archive (OAR) function has existed since OpenSimulator 0.5.9. The facility does a similar job to load-xml2/save-xml2 in that it saves prims so that they can be later reloaded. However, OpenSimulator archives (OAR) go a step further in that they can save all the necessary asset data so that you may fully restore the terrain, region parcel data, the textures of objects and their inventories when loaded onto a completely different system using a different asset database.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
From the region console, one can type &lt;br /&gt;
&lt;br /&gt;
 save oar [--noassets] [-h|--home=&amp;amp;lt;url&amp;amp;gt;] [--publish] [--perm=&amp;amp;lt;permissions&amp;amp;gt;] [--all] [&amp;amp;lt;filename&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
to save an OpenSimulator archive. If no filename is given, then the name region.oar is used in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 save oar&lt;br /&gt;
 save oar my.oar&lt;br /&gt;
 save oar c:/mybackups/filename.oar&lt;br /&gt;
 save oar oars/11nov.oar&lt;br /&gt;
&lt;br /&gt;
To load an archive, type &lt;br /&gt;
&lt;br /&gt;
 load oar [--merge] [--skip-assets] [&amp;amp;lt;location&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
at the console. The location can be a filesystem path (as for &amp;quot;save oar&amp;quot;) or an HTTP address to load an oar directly over the web. If no location is given, then the server looks for a file called region.oar in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 load oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar --merge oars/3rd-party.oar&lt;br /&gt;
 load oar http://path.to/oarfile.oar&lt;br /&gt;
&lt;br /&gt;
By default, loading an archive will delete all the existing objects in the regions and replace them with the archive contents. It's like being in the Matrix (when they swap environments), except much slower (all the scene objects are slowly deleted before the new environment is loaded&amp;amp;nbsp;:-) &lt;br /&gt;
&lt;br /&gt;
When an archive is loaded, owners will be restored if the relevant uuids can be found in the OpenSimulator installation's user database. Otherwise, prim ownership will default to the master avatar for the region. &lt;br /&gt;
&lt;br /&gt;
I recommend that you use filenames with the extension '''.oar'''. The filename extension of the download links on this page is '''.tar.gz''' which illustrates that the '''.oar''' format is actually a zipped tar file.&lt;br /&gt;
&lt;br /&gt;
=== Switches ===&lt;br /&gt;
==== Saving ====&lt;br /&gt;
&lt;br /&gt;
===== --publish =====&lt;br /&gt;
&lt;br /&gt;
If set, then objects in the saved oar are stripped of owner and last owner information, though not of creator information.&lt;br /&gt;
&lt;br /&gt;
This is useful if you are publishing OARs (rather than using them for backup) where those OARs might be loaded to the same grid from which you published.&lt;br /&gt;
&lt;br /&gt;
As of OpenSimulator 0.7.4, this switch will also strip ownership information from land parcels.&lt;br /&gt;
&lt;br /&gt;
===== --noassets =====&lt;br /&gt;
&lt;br /&gt;
If the --noassets option is specified then the oar will be saved without assets. This can be handy if you're backing up the asset database separately and don't want the expense of including all the assets in each OAR.&lt;br /&gt;
&lt;br /&gt;
===== --home =====&lt;br /&gt;
&lt;br /&gt;
(formerly known as --profile up to 0.7.3)&lt;br /&gt;
&lt;br /&gt;
If the --home option is specified then all names of creators from this world will be appended with links to their home world. It is not required that the service be operational; the information will be added and it will be available in all worlds that import this OAR.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;url&amp;gt; is the URL of this world's profile service. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --home=http://mygrid.com my.oar&lt;br /&gt;
&lt;br /&gt;
===== --perm =====&lt;br /&gt;
&lt;br /&gt;
If the --perm option is specified then objects with insufficient permissions will not be saved to the OAR. The user whose permissions are checked is the estate owner. This can be useful for grids that allow their customers to export their regions to OARs, because it ensures that exporting to OAR can't be used to bypass content permissions.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;permissions&amp;gt; specifies which permissions are required. It's a string that contains one or more of these characters:&lt;br /&gt;
* &amp;quot;C&amp;quot; = Copy&lt;br /&gt;
* &amp;quot;T&amp;quot; = Transfer&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --perm=CT my.oar&lt;br /&gt;
&lt;br /&gt;
===== --all =====&lt;br /&gt;
&lt;br /&gt;
If the --all option is specified then the OAR will contain all the regions in the simulator. If this option isn't specified (which is the default) then the OAR will contain only the current region.&lt;br /&gt;
&lt;br /&gt;
==== Loading ====&lt;br /&gt;
&lt;br /&gt;
===== --skip-assets =====&lt;br /&gt;
&lt;br /&gt;
If set, this will not attempt to load any of the assets from the OAR, though all other data will be loaded.  This can be useful if you are loading the OAR back into a grid that you know already contains the assets.&lt;br /&gt;
&lt;br /&gt;
===== --merge =====&lt;br /&gt;
&lt;br /&gt;
If the --merge option is specified then the oar will be merged with the existing region objects rather than replace them. The existing terrain, region settings and parcels will be left in place.&lt;br /&gt;
&lt;br /&gt;
== Multi-Region OARs ==&lt;br /&gt;
&lt;br /&gt;
By default, the save-oar command saves only the current region into the OAR (using OAR Format 0.8). However, if the --all option is specified then all the regions in the simulator are saved into a multi-region OAR file (using OAR Format 1.0). This is useful when saving a build that spans multiple regions.&lt;br /&gt;
&lt;br /&gt;
The load-oar command supports both OAR formats (0.x and 1.x). When it's given a 1.x OAR file it loads all the regions in the OAR into the corresponding regions in the simulator, according to their position relative to the root region. If the simulator doesn't have a region in a location that is present in the OAR then that region isn't loaded. &lt;br /&gt;
&lt;br /&gt;
==== OAR Format Compatibility ====&lt;br /&gt;
&lt;br /&gt;
OAR Format 1.0 isn't backwards-compatible, so it can only be read in OpenSim 0.7.5 and above. However, since most current instances of OpenSim can't read this format, there is a transition period in which OpenSim still saves single-region OARs using OAR Format 0.8. This means that the most common behavior (save-oar for a single region) creates OARs that are readable by all instances of OpenSim. The new OAR Format 1.0 is only used when using the --all option.&lt;br /&gt;
&lt;br /&gt;
== Example OARs ==&lt;br /&gt;
&lt;br /&gt;
[http://www.secondlifelab.it/downloads/cyberlandia.tar.gz cyberlandia.tar.gz] - cyberlandia landscape designed by the architect Simone Riccardi aka turboy. Contemporary architecture surrounded with a natural/synthetic context [http://www.flickr.com/photos/8905571@N05/3182585775/ image_1] [http://www.flickr.com/photos/8905571@N05/3171070049/ image_2] (work under [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons by attribution]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== OpenVCE 3D Assets OAR ===&lt;br /&gt;
&lt;br /&gt;
The [http://openvce.net OpenVCE.net] virtual worlds assets described at http://openvce.net/vwassets provided by Clever Zebra and the OpenVCE.net team at AIAI in the University of Edinburgh are available as an OAR (Opensim Archive) file.&lt;br /&gt;
&lt;br /&gt;
 http://openvce.net/resources/downloads/&lt;br /&gt;
&lt;br /&gt;
Get file &amp;quot;opensim-openvce.oar&amp;quot; from there (right click on the file in the above directory in your browser, and select download is the easiest way to obtain the materials). A &amp;quot;full&amp;quot; set of the buildings with a large 400 seat amphitheatre intended to be placed on the corner of 4 sims is also available via &amp;quot;opensim-openvce-full.oar&amp;quot;. Images of the buildings in place in Opensim are at:&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-1.jpg Image 1],&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-2.jpg Image 2]&lt;br /&gt;
&lt;br /&gt;
=== Others ===&lt;br /&gt;
&lt;br /&gt;
Please feel free to place links to other environments here, though unfortunately you'll have to host them on some other site. &lt;br /&gt;
&lt;br /&gt;
[http://www.hypergridbusiness.com/2011/06/where-to-get-content-for-opensim/ Where to get content for OpenSim]&amp;amp;nbsp;-- Hypergrid Business page, regularly updated, containing links to major OAR sites. Also has download links to individual OAR files. &lt;br /&gt;
&lt;br /&gt;
[http://www.lindakellie.com/myoars.htm LindaKellie.com] &lt;br /&gt;
&lt;br /&gt;
[http://opensim-creations.com/category/regions/oars/ OpenSimulator Creations] &lt;br /&gt;
&lt;br /&gt;
[http://www.opensimworlds.com/index.php?part=worlds http://www.opensimworlds.com/index.php?part=worlds]&lt;br /&gt;
&lt;br /&gt;
[http://forums.osgrid.org/viewforum.php?f=20 http://forums.osgrid.org/viewforum.php]&lt;br /&gt;
&lt;br /&gt;
== Further Information ==&lt;br /&gt;
&lt;br /&gt;
* [http://justincc.org/blog/category/oars/ http://justincc.org/blog/category/oars/] - various OAR related articles from justincc, including background information and possible future development.&lt;br /&gt;
&lt;br /&gt;
== Use cases ==&lt;br /&gt;
&lt;br /&gt;
Possible current uses are&lt;br /&gt;
&lt;br /&gt;
1. To migrate data from an SQLite region database to one based on MySQL&lt;br /&gt;
&lt;br /&gt;
2. To distribute entire regions to other people.&lt;br /&gt;
&lt;br /&gt;
== Current limitations ==&lt;br /&gt;
&lt;br /&gt;
* Performance is not very good, especially with large archives. This will be addressed in the future&lt;br /&gt;
* Loading large OARs using the default SQLite database plugin will take a very very long time (in the order of many hours). I highly recommend that you switch to MySQL if you want to load large archives.&lt;br /&gt;
&lt;br /&gt;
== OAR Format ==&lt;br /&gt;
&lt;br /&gt;
The region [[OpenSim Archives|OpenSimulator Archive (OAR)]] format is designed with three aims in mind:&lt;br /&gt;
&lt;br /&gt;
# Make it easy for people to read and change individual objects, assets, etc. within an archive.&lt;br /&gt;
# Make it easy to compose two region archives into a single region archive.&lt;br /&gt;
# Make it easy to compose archives from scratch.&lt;br /&gt;
&lt;br /&gt;
Therefore, all the different entities (assets, objects, terrains, etc.) are packaged in individual files (e.g. one for each asset) with human readable filenames and machine readable extensions (e.g. .jp2 for textures, .txt for notecards).&lt;br /&gt;
&lt;br /&gt;
* [[OAR Format 0.1]]&lt;br /&gt;
* [[OAR Format 0.2]]&lt;br /&gt;
* [[OAR Format 0.6]]&lt;br /&gt;
* [[OAR Format 0.7]]&lt;br /&gt;
* [[OAR Format 0.8]]&lt;br /&gt;
* [[OAR Format 1.0]]&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
1. What is this .tar.gz format you are using for the internal OAR format? Why not zip?&lt;br /&gt;
&lt;br /&gt;
.tar.gz is a standard unix way of zipping up files into a single larger compressed file for distribution. Windows users should be able to open these files using freeware programs such as [http://www.7-zip.org/ 7-zip]. &lt;br /&gt;
&lt;br /&gt;
I'm using .tar.gz because all the zip (and tar) libraries for .net are licensed either under the GPL (with exception) or under the MSPL. Unfortunately, not all members of the OpenSimulator development team are comfortable with the MSPL, so these libaries are not currently an option. It is also significantly easier to write code to create and read tar archives than zip archives.&lt;br /&gt;
&lt;br /&gt;
Also, if you're only ever loading and saving oars (rather than pulling them apart and putting them back together), then you don't need to worry about the internal format at all :)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2. Can you load and save multiple regions to an archive?&lt;br /&gt;
&lt;br /&gt;
[[Feature_Proposals/Multi-Region_OARs|Present in development code, will be released in OpenSimulator 0.7.5.  Considered experimental.]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3. Can you load and save parts of a region to an archive?&lt;br /&gt;
&lt;br /&gt;
Not yet.&lt;br /&gt;
&lt;br /&gt;
== Bugs ==&lt;br /&gt;
&lt;br /&gt;
* Due to a possible bug in the Mono 1.2.4 libraries, this feature may cause a debug dump when used (the problem appears to be in writing out a compressed stream). Mono 1.2.6 is okay. Since Mono 1.2.4 is fairly old now, this bug will not be addressed.&lt;br /&gt;
&lt;br /&gt;
== Current Status ==&lt;br /&gt;
&lt;br /&gt;
Operational. Bug reports are appreciated [[User:Justincc|Justincc]] 14:53, 14 September 2009 (UTC)&lt;br /&gt;
&lt;br /&gt;
Though we will strive to maintain compatibilty for old archives with newer OpenSimulator versions, please don't rely on these archives as the only backup for regions.&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OAR_Format_1.0</id>
		<title>OAR Format 1.0</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OAR_Format_1.0"/>
				<updated>2012-09-23T06:30:19Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Created page with &amp;quot;= What is the OAR 1.0 format? =  == Changes ==  This format is currently in the development version of OpenSimulator only. Please do not rely on it as the details are subject to ...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= What is the OAR 1.0 format? =&lt;br /&gt;
&lt;br /&gt;
== Changes ==&lt;br /&gt;
&lt;br /&gt;
This format is currently in the development version of OpenSimulator only. Please do not rely on it as the details are subject to change without notice.&lt;br /&gt;
&lt;br /&gt;
OAR format 1.0 is the first format that supports storing multiple regions in a single OAR file. It's not backwards compatible with the previous OAR formats, which is why it has a new major version number.&lt;br /&gt;
&lt;br /&gt;
== Detail ==&lt;br /&gt;
&lt;br /&gt;
An OAR file is a gzipped tar file (tar.gz) in the the original unix tar format (not USTAR). This can be extracted and created with standard tools ([http://www.7-zip.org/ 7-zip] on Windows). The file can contain multiple regions. The structure of the archive is as follows (this example contains 4 regions):&lt;br /&gt;
&lt;br /&gt;
 archive.xml&lt;br /&gt;
 assets/&lt;br /&gt;
 regions/&lt;br /&gt;
   1_1_Arizona/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
   2_1_New_Mexico/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
   1_2_Utah/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
   2_2_Colorado/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
&lt;br /&gt;
The regions' directory names include the region's location (relative to the root region) in order to ensure uniqueness even if regions have duplicate names.&lt;br /&gt;
&lt;br /&gt;
=== archive.xml ===&lt;br /&gt;
&lt;br /&gt;
This is the archive control file. It contains a major and minor version number, to allow compatibility with future format changes.&lt;br /&gt;
&lt;br /&gt;
The boolean element &amp;lt;assets_included&amp;gt; specifies whether the OAR contains assets. If the value is True then the OAR was saved with assets included. If the value is False then the OAR was saved with the --noassets option.&lt;br /&gt;
&lt;br /&gt;
The control file contains a manifest of the included regions. The list of regions always describes a rectangle, with the root region (the region where the &amp;quot;save-oar&amp;quot; command was run) in the SW corner. The regions are listed in the following order: rows from South to North, and within each row regions are listed West-to-East. Missing regions are supported: they're represented by empty elements.&lt;br /&gt;
&lt;br /&gt;
For example:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-16&amp;quot;?&amp;gt;&lt;br /&gt;
 &amp;lt;archive major_version=&amp;quot;1&amp;quot; minor_version=&amp;quot;0&amp;quot;&amp;gt;&lt;br /&gt;
   &amp;lt;creation_info&amp;gt;&lt;br /&gt;
     &amp;lt;datetime&amp;gt;1343204139&amp;lt;/datetime&amp;gt;&lt;br /&gt;
   &amp;lt;/creation_info&amp;gt;&lt;br /&gt;
   &amp;lt;assets_included&amp;gt;True&amp;lt;/assets_included&amp;gt;&lt;br /&gt;
   &amp;lt;regions&amp;gt;&lt;br /&gt;
     &amp;lt;row&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-1111-1111-1111-111111111111&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;1_1_Arizona&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-2222-2222-2222-222222222222&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;2_1_New_Mexico&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
     &amp;lt;/row&amp;gt;&lt;br /&gt;
     &amp;lt;row&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-3333-3333-3333-333333333333&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;1_2_Utah&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-4444-4444-4444-444444444444&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;2_2_Colorado&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
     &amp;lt;/row&amp;gt;&lt;br /&gt;
   &amp;lt;/regions&amp;gt;&lt;br /&gt;
 &amp;lt;/archive&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== assets/ ===&lt;br /&gt;
&lt;br /&gt;
This directory contains all the assets in the archive. The assets for all the regions are stored in the same directory because assets are often shared. Each filename has the following format&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;uuid&amp;gt;_&amp;lt;asset type&amp;gt;.&amp;lt;asset extension&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The ''uuid'' section must always be present and form a valid uuid - it is used directly as the uuid for that asset. The ''asset type'' and ''asset extension'' are used to identify the type of asset and the ''asset extension'' allows the asset to be associated with different editors on platforms such as Windows. For instance, a script will always have the asset type and extension script.lsl. A full list of asset types and extensions can be found in the file &lt;br /&gt;
&lt;br /&gt;
 OpenSim/Region/Environment/Modules/World/Archiver/ArchiveConstants.cs&lt;br /&gt;
&lt;br /&gt;
in the OpenSimulator distribution.&lt;br /&gt;
&lt;br /&gt;
In the future, the format of these files will be described in [[Asset Formats]].&lt;br /&gt;
&lt;br /&gt;
=== landdata/ ===&lt;br /&gt;
&lt;br /&gt;
This directory contains all the parcels in the region. Information for each parcel is stored in a separate file in XML format. Each filename has the form:&lt;br /&gt;
&lt;br /&gt;
  &amp;lt;uuid&amp;gt;.xml&lt;br /&gt;
&lt;br /&gt;
where ''uuid'' is the uuid of the parcel.&lt;br /&gt;
&lt;br /&gt;
=== objects/ ===&lt;br /&gt;
&lt;br /&gt;
Each individual file in here is an object in the region (where an object [linkset] can be composed of many prims). The file format used is OpenSim's XML2 format. Each filename has the following structure by default&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;Object name&amp;gt;_&amp;lt;x&amp;gt;-&amp;lt;y&amp;gt;-&amp;lt;z&amp;gt;__&amp;lt;uuid&amp;gt;.xml&lt;br /&gt;
&lt;br /&gt;
Unlike asset filenames, any component of this name can be changed without affecting any attributes of the object itself - this information is taken from the xml instead. Indeed, this file can have any name - there is no need for any of the sections to be present. An example object file name is&lt;br /&gt;
&lt;br /&gt;
 Primitive_154-121-062__9be68fdd-f740-4a0f-9675-dfbbb536b946.xml&lt;br /&gt;
&lt;br /&gt;
The actual format is described (currently very sketchily) in [[Asset Formats]].&lt;br /&gt;
&lt;br /&gt;
=== settings/ ===&lt;br /&gt;
&lt;br /&gt;
This contains the region settings information for the region in XML format. The filename will be the same as the region name. For example,&lt;br /&gt;
&lt;br /&gt;
 OpenSimulator Test.xml&lt;br /&gt;
&lt;br /&gt;
See an example of an XML region settings file below.&lt;br /&gt;
&lt;br /&gt;
=== terrains/ ===&lt;br /&gt;
&lt;br /&gt;
This contains the terrain file for the region, stored in RAW format. The filename must end with .r32. For example,&lt;br /&gt;
&lt;br /&gt;
 OpenSimulator Test.r32&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OpenSim_Archives</id>
		<title>OpenSim Archives</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OpenSim_Archives"/>
				<updated>2012-09-23T06:19:35Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* OAR Format */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= How do I use the OpenSimulator Archive Function? =&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
The OpenSimulator Archive (OAR) function has existed since OpenSimulator 0.5.9. The facility does a similar job to load-xml2/save-xml2 in that it saves prims so that they can be later reloaded. However, OpenSimulator archives (OAR) go a step further in that they can save all the necessary asset data so that you may fully restore the terrain, region parcel data, the textures of objects and their inventories when loaded onto a completely different system using a different asset database.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
From the region console, one can type &lt;br /&gt;
&lt;br /&gt;
 save oar [--noassets] [-h|--home=&amp;amp;lt;url&amp;amp;gt;] [--publish] [--perm=&amp;amp;lt;permissions&amp;amp;gt;] [--all] [&amp;amp;lt;filename&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
to save an OpenSimulator archive. If no filename is given, then the name region.oar is used in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 save oar&lt;br /&gt;
 save oar my.oar&lt;br /&gt;
 save oar c:/mybackups/filename.oar&lt;br /&gt;
 save oar oars/11nov.oar&lt;br /&gt;
&lt;br /&gt;
To load an archive, type &lt;br /&gt;
&lt;br /&gt;
 load oar [--merge] [--skip-assets] [&amp;amp;lt;location&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
at the console. The location can be a filesystem path (as for &amp;quot;save oar&amp;quot;) or an HTTP address to load an oar directly over the web. If no location is given, then the server looks for a file called region.oar in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 load oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar --merge oars/3rd-party.oar&lt;br /&gt;
 load oar http://path.to/oarfile.oar&lt;br /&gt;
&lt;br /&gt;
By default, loading an archive will delete all the existing objects in the regions and replace them with the archive contents. It's like being in the Matrix (when they swap environments), except much slower (all the scene objects are slowly deleted before the new environment is loaded&amp;amp;nbsp;:-) &lt;br /&gt;
&lt;br /&gt;
When an archive is loaded, owners will be restored if the relevant uuids can be found in the OpenSimulator installation's user database. Otherwise, prim ownership will default to the master avatar for the region. &lt;br /&gt;
&lt;br /&gt;
I recommend that you use filenames with the extension '''.oar'''. The filename extension of the download links on this page is '''.tar.gz''' which illustrates that the '''.oar''' format is actually a zipped tar file.&lt;br /&gt;
&lt;br /&gt;
=== Switches ===&lt;br /&gt;
==== Saving ====&lt;br /&gt;
&lt;br /&gt;
===== --publish =====&lt;br /&gt;
&lt;br /&gt;
If set, then objects in the saved oar are stripped of owner and last owner information, though not of creator information.&lt;br /&gt;
&lt;br /&gt;
This is useful if you are publishing OARs (rather than using them for backup) where those OARs might be loaded to the same grid from which you published.&lt;br /&gt;
&lt;br /&gt;
As of OpenSimulator 0.7.4, this switch will also strip ownership information from land parcels.&lt;br /&gt;
&lt;br /&gt;
===== --noassets =====&lt;br /&gt;
&lt;br /&gt;
If the --noassets option is specified then the oar will be saved without assets. This can be handy if you're backing up the asset database separately and don't want the expense of including all the assets in each OAR.&lt;br /&gt;
&lt;br /&gt;
===== --home =====&lt;br /&gt;
&lt;br /&gt;
(formerly known as --profile up to 0.7.3)&lt;br /&gt;
&lt;br /&gt;
If the --home option is specified then all names of creators from this world will be appended with links to their home world. It is not required that the service be operational; the information will be added and it will be available in all worlds that import this OAR.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;url&amp;gt; is the URL of this world's profile service. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --home=http://mygrid.com my.oar&lt;br /&gt;
&lt;br /&gt;
===== --perm =====&lt;br /&gt;
&lt;br /&gt;
If the --perm option is specified then objects with insufficient permissions will not be saved to the OAR. The user whose permissions are checked is the estate owner. This can be useful for grids that allow their customers to export their regions to OARs, because it ensures that exporting to OAR can't be used to bypass content permissions.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;permissions&amp;gt; specifies which permissions are required. It's a string that contains one or more of these characters:&lt;br /&gt;
* &amp;quot;C&amp;quot; = Copy&lt;br /&gt;
* &amp;quot;T&amp;quot; = Transfer&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --perm=CT my.oar&lt;br /&gt;
&lt;br /&gt;
===== --all =====&lt;br /&gt;
&lt;br /&gt;
If the --all option is specified then the OAR will contain all the regions in the simulator. If this option isn't specified (which is the default) then the OAR will contain only the current region.&lt;br /&gt;
&lt;br /&gt;
==== Loading ====&lt;br /&gt;
&lt;br /&gt;
===== --skip-assets =====&lt;br /&gt;
&lt;br /&gt;
If set, this will not attempt to load any of the assets from the OAR, though all other data will be loaded.  This can be useful if you are loading the OAR back into a grid that you know already contains the assets.&lt;br /&gt;
&lt;br /&gt;
===== --merge =====&lt;br /&gt;
&lt;br /&gt;
If the --merge option is specified then the oar will be merged with the existing region objects rather than replace them. The existing terrain, region settings and parcels will be left in place.&lt;br /&gt;
&lt;br /&gt;
== Example OARs ==&lt;br /&gt;
&lt;br /&gt;
[http://www.secondlifelab.it/downloads/cyberlandia.tar.gz cyberlandia.tar.gz] - cyberlandia landscape designed by the architect Simone Riccardi aka turboy. Contemporary architecture surrounded with a natural/synthetic context [http://www.flickr.com/photos/8905571@N05/3182585775/ image_1] [http://www.flickr.com/photos/8905571@N05/3171070049/ image_2] (work under [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons by attribution]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== OpenVCE 3D Assets OAR ===&lt;br /&gt;
&lt;br /&gt;
The [http://openvce.net OpenVCE.net] virtual worlds assets described at http://openvce.net/vwassets provided by Clever Zebra and the OpenVCE.net team at AIAI in the University of Edinburgh are available as an OAR (Opensim Archive) file.&lt;br /&gt;
&lt;br /&gt;
 http://openvce.net/resources/downloads/&lt;br /&gt;
&lt;br /&gt;
Get file &amp;quot;opensim-openvce.oar&amp;quot; from there (right click on the file in the above directory in your browser, and select download is the easiest way to obtain the materials). A &amp;quot;full&amp;quot; set of the buildings with a large 400 seat amphitheatre intended to be placed on the corner of 4 sims is also available via &amp;quot;opensim-openvce-full.oar&amp;quot;. Images of the buildings in place in Opensim are at:&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-1.jpg Image 1],&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-2.jpg Image 2]&lt;br /&gt;
&lt;br /&gt;
=== Others ===&lt;br /&gt;
&lt;br /&gt;
Please feel free to place links to other environments here, though unfortunately you'll have to host them on some other site. &lt;br /&gt;
&lt;br /&gt;
[http://www.hypergridbusiness.com/2011/06/where-to-get-content-for-opensim/ Where to get content for OpenSim]&amp;amp;nbsp;-- Hypergrid Business page, regularly updated, containing links to major OAR sites. Also has download links to individual OAR files. &lt;br /&gt;
&lt;br /&gt;
[http://www.lindakellie.com/myoars.htm LindaKellie.com] &lt;br /&gt;
&lt;br /&gt;
[http://opensim-creations.com/category/regions/oars/ OpenSimulator Creations] &lt;br /&gt;
&lt;br /&gt;
[http://www.opensimworlds.com/index.php?part=worlds http://www.opensimworlds.com/index.php?part=worlds]&lt;br /&gt;
&lt;br /&gt;
[http://forums.osgrid.org/viewforum.php?f=20 http://forums.osgrid.org/viewforum.php]&lt;br /&gt;
&lt;br /&gt;
== Further Information ==&lt;br /&gt;
&lt;br /&gt;
* [http://justincc.org/blog/category/oars/ http://justincc.org/blog/category/oars/] - various OAR related articles from justincc, including background information and possible future development.&lt;br /&gt;
&lt;br /&gt;
== Use cases ==&lt;br /&gt;
&lt;br /&gt;
Possible current uses are&lt;br /&gt;
&lt;br /&gt;
1. To migrate data from an SQLite region database to one based on MySQL&lt;br /&gt;
&lt;br /&gt;
2. To distribute entire regions to other people.&lt;br /&gt;
&lt;br /&gt;
== Current limitations ==&lt;br /&gt;
&lt;br /&gt;
* Performance is not very good, especially with large archives. This will be addressed in the future&lt;br /&gt;
* Loading large OARs using the default SQLite database plugin will take a very very long time (in the order of many hours). I highly recommend that you switch to MySQL if you want to load large archives.&lt;br /&gt;
&lt;br /&gt;
== OAR Format ==&lt;br /&gt;
&lt;br /&gt;
The region [[OpenSim Archives|OpenSimulator Archive (OAR)]] format is designed with three aims in mind:&lt;br /&gt;
&lt;br /&gt;
# Make it easy for people to read and change individual objects, assets, etc. within an archive.&lt;br /&gt;
# Make it easy to compose two region archives into a single region archive.&lt;br /&gt;
# Make it easy to compose archives from scratch.&lt;br /&gt;
&lt;br /&gt;
Therefore, all the different entities (assets, objects, terrains, etc.) are packaged in individual files (e.g. one for each asset) with human readable filenames and machine readable extensions (e.g. .jp2 for textures, .txt for notecards).&lt;br /&gt;
&lt;br /&gt;
* [[OAR Format 0.1]]&lt;br /&gt;
* [[OAR Format 0.2]]&lt;br /&gt;
* [[OAR Format 0.6]]&lt;br /&gt;
* [[OAR Format 0.7]]&lt;br /&gt;
* [[OAR Format 0.8]]&lt;br /&gt;
* [[OAR Format 1.0]]&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
1. What is this .tar.gz format you are using for the internal OAR format? Why not zip?&lt;br /&gt;
&lt;br /&gt;
.tar.gz is a standard unix way of zipping up files into a single larger compressed file for distribution. Windows users should be able to open these files using freeware programs such as [http://www.7-zip.org/ 7-zip]. &lt;br /&gt;
&lt;br /&gt;
I'm using .tar.gz because all the zip (and tar) libraries for .net are licensed either under the GPL (with exception) or under the MSPL. Unfortunately, not all members of the OpenSimulator development team are comfortable with the MSPL, so these libaries are not currently an option. It is also significantly easier to write code to create and read tar archives than zip archives.&lt;br /&gt;
&lt;br /&gt;
Also, if you're only ever loading and saving oars (rather than pulling them apart and putting them back together), then you don't need to worry about the internal format at all :)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2. Can you load and save multiple regions to an archive?&lt;br /&gt;
&lt;br /&gt;
[[Feature_Proposals/Multi-Region_OARs|Present in development code, will be released in OpenSimulator 0.7.5.  Considered experimental.]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3. Can you load and save parts of a region to an archive?&lt;br /&gt;
&lt;br /&gt;
Not yet.&lt;br /&gt;
&lt;br /&gt;
== Bugs ==&lt;br /&gt;
&lt;br /&gt;
* Due to a possible bug in the Mono 1.2.4 libraries, this feature may cause a debug dump when used (the problem appears to be in writing out a compressed stream). Mono 1.2.6 is okay. Since Mono 1.2.4 is fairly old now, this bug will not be addressed.&lt;br /&gt;
&lt;br /&gt;
== Current Status ==&lt;br /&gt;
&lt;br /&gt;
Operational. Bug reports are appreciated [[User:Justincc|Justincc]] 14:53, 14 September 2009 (UTC)&lt;br /&gt;
&lt;br /&gt;
Though we will strive to maintain compatibilty for old archives with newer OpenSimulator versions, please don't rely on these archives as the only backup for regions.&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OAR_Format_0.8</id>
		<title>OAR Format 0.8</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OAR_Format_0.8"/>
				<updated>2012-09-23T06:17:56Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* What is the OAR 0.8 format? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
= What is the OAR 0.8 format? =&lt;br /&gt;
&lt;br /&gt;
== Changes ==&lt;br /&gt;
&lt;br /&gt;
This format is currently in the development version of OpenSimulator only. Please do not rely on it as the details are subject to change without notice.&lt;br /&gt;
&lt;br /&gt;
OAR format 0.8 is identical to 0.7 except for two changes. First, the region's Telehub (if it exists) is now saved. Second, some OARs with format 0.8 include a &amp;lt;region_info&amp;gt; element in archive.xml.&lt;br /&gt;
&lt;br /&gt;
== Detail ==&lt;br /&gt;
&lt;br /&gt;
At the present time, a region archive is a gzipped tar file (tar.gz) in the the original unix tar format (not USTAR). This can be extracted and created with standard tools ([http://www.7-zip.org/ 7-zip] on Windows). The structure of the archive is as follows&lt;br /&gt;
&lt;br /&gt;
 archive.xml&lt;br /&gt;
 assets/&lt;br /&gt;
 landdata/&lt;br /&gt;
 objects/&lt;br /&gt;
 settings/&lt;br /&gt;
 terrains/&lt;br /&gt;
&lt;br /&gt;
=== archive.xml ===&lt;br /&gt;
&lt;br /&gt;
This is the archive control file. It contains a major and minor version number, to allow compatibility with future format changes.&lt;br /&gt;
It also contains an &amp;lt;assets_included&amp;gt; element which can have the contents True or False. If the string is True, then the OAR was saved with assets included. If the switch is False, then the OAR was saved with the --noassets option.&lt;br /&gt;
&lt;br /&gt;
Here's an example of an existing archive.xml file&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-16&amp;quot;?&amp;gt;&lt;br /&gt;
&amp;lt;archive major_version=&amp;quot;0&amp;quot; minor_version=&amp;quot;8&amp;quot;&amp;gt;&lt;br /&gt;
  &amp;lt;creation_info&amp;gt;&lt;br /&gt;
    &amp;lt;datetime&amp;gt;1345003250&amp;lt;/datetime&amp;gt;&lt;br /&gt;
    &amp;lt;id&amp;gt;47b709da-d64c-4b25-90f2-cb64a5245420&amp;lt;/id&amp;gt;&lt;br /&gt;
  &amp;lt;/creation_info&amp;gt;&lt;br /&gt;
  &amp;lt;assets_included&amp;gt;True&amp;lt;/assets_included&amp;gt;&lt;br /&gt;
  &amp;lt;region_info&amp;gt;&lt;br /&gt;
    &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
    &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
  &amp;lt;/region_info&amp;gt;&lt;br /&gt;
&amp;lt;/archive&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== assets/ ===&lt;br /&gt;
&lt;br /&gt;
This directory contains all the assets in the archive. Each filename has the following format&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;uuid&amp;gt;_&amp;lt;asset type&amp;gt;.&amp;lt;asset extension&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The ''uuid'' section must always be present and form a valid uuid - it is used directly as the uuid for that asset. The ''asset type'' and ''asset extension'' are used to identify the type of asset and the ''asset extension'' allows the asset to be associated with different editors on platforms such as Windows. For instance, a script will always have the asset type and extension script.lsl. A full list of asset types and extensions can be found in the file &lt;br /&gt;
&lt;br /&gt;
 OpenSim/Region/Environment/Modules/World/Archiver/ArchiveConstants.cs&lt;br /&gt;
&lt;br /&gt;
in the OpenSimulator distribution.&lt;br /&gt;
&lt;br /&gt;
In the future, the format of these files will be described in [[Asset Formats]].&lt;br /&gt;
&lt;br /&gt;
=== landdata/ ===&lt;br /&gt;
&lt;br /&gt;
This directory contains all the parcels in the region. Information for each parcel is stored in a separate file in XML format. Each filename has the form:&lt;br /&gt;
&lt;br /&gt;
  &amp;lt;uuid&amp;gt;.xml&lt;br /&gt;
&lt;br /&gt;
where ''uuid'' is the uuid of the parcel.&lt;br /&gt;
&lt;br /&gt;
=== objects/ ===&lt;br /&gt;
&lt;br /&gt;
Each individual file in here is an object in the region (where an object [linkset] can be composed of many prims). The file format used is OpenSim's XML2 format. Each filename has the following structure by default&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;Object name&amp;gt;_&amp;lt;x&amp;gt;-&amp;lt;y&amp;gt;-&amp;lt;z&amp;gt;__&amp;lt;uuid&amp;gt;.xml&lt;br /&gt;
&lt;br /&gt;
Unlike asset filenames, any component of this name can be changed without affecting any attributes of the object itself - this information is taken from the xml instead. Indeed, this file can have any name - there is no need for any of the sections to be present. An example object file name is&lt;br /&gt;
&lt;br /&gt;
 Primitive_154-121-062__9be68fdd-f740-4a0f-9675-dfbbb536b946.xml&lt;br /&gt;
&lt;br /&gt;
The actual format is described (currently very sketchily) in [[Asset Formats]].&lt;br /&gt;
&lt;br /&gt;
=== settings/ ===&lt;br /&gt;
&lt;br /&gt;
This contains the region settings information for the region in XML format. The filename will be the same as the region name. For example,&lt;br /&gt;
&lt;br /&gt;
 OpenSimulator Test.xml&lt;br /&gt;
&lt;br /&gt;
See an example of an XML region settings file below.&lt;br /&gt;
&lt;br /&gt;
=== terrains/ ===&lt;br /&gt;
&lt;br /&gt;
This contains the terrain file for the region, stored in RAW format. The filename must end with .r32. For example,&lt;br /&gt;
&lt;br /&gt;
 OpenSimulator Test.r32&lt;br /&gt;
&lt;br /&gt;
= Region Settings Example =&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-16&amp;quot;?&amp;gt;&lt;br /&gt;
 &amp;lt;RegionSettings&amp;gt;&lt;br /&gt;
   &amp;lt;General&amp;gt;&lt;br /&gt;
     &amp;lt;AllowDamage&amp;gt;False&amp;lt;/AllowDamage&amp;gt;&lt;br /&gt;
     &amp;lt;AllowLandResell&amp;gt;True&amp;lt;/AllowLandResell&amp;gt;&lt;br /&gt;
     &amp;lt;AllowLandJoinDivide&amp;gt;True&amp;lt;/AllowLandJoinDivide&amp;gt;&lt;br /&gt;
     &amp;lt;BlockFly&amp;gt;False&amp;lt;/BlockFly&amp;gt;&lt;br /&gt;
     &amp;lt;BlockLandShowInSearch&amp;gt;False&amp;lt;/BlockLandShowInSearch&amp;gt;&lt;br /&gt;
     &amp;lt;BlockTerraform&amp;gt;False&amp;lt;/BlockTerraform&amp;gt;&lt;br /&gt;
     &amp;lt;DisableCollisions&amp;gt;False&amp;lt;/DisableCollisions&amp;gt;&lt;br /&gt;
     &amp;lt;DisablePhysics&amp;gt;False&amp;lt;/DisablePhysics&amp;gt;&lt;br /&gt;
     &amp;lt;DisableScripts&amp;gt;False&amp;lt;/DisableScripts&amp;gt;&lt;br /&gt;
     &amp;lt;MaturityRating&amp;gt;1&amp;lt;/MaturityRating&amp;gt;&lt;br /&gt;
     &amp;lt;RestrictPushing&amp;gt;False&amp;lt;/RestrictPushing&amp;gt;&lt;br /&gt;
     &amp;lt;AgentLimit&amp;gt;40&amp;lt;/AgentLimit&amp;gt;&lt;br /&gt;
     &amp;lt;ObjectBonus&amp;gt;1&amp;lt;/ObjectBonus&amp;gt;&lt;br /&gt;
   &amp;lt;/General&amp;gt;&lt;br /&gt;
   &amp;lt;GroundTextures&amp;gt;&lt;br /&gt;
     &amp;lt;Texture1&amp;gt;b8d3965a-ad78-bf43-699b-bff8eca6c975&amp;lt;/Texture1&amp;gt;&lt;br /&gt;
     &amp;lt;Texture2&amp;gt;abb783e6-3e93-26c0-248a-247666855da3&amp;lt;/Texture2&amp;gt;&lt;br /&gt;
     &amp;lt;Texture3&amp;gt;179cdabd-398a-9b6b-1391-4dc333ba321f&amp;lt;/Texture3&amp;gt;&lt;br /&gt;
     &amp;lt;Texture4&amp;gt;beb169c7-11ea-fff2-efe5-0f24dc881df2&amp;lt;/Texture4&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationLowSW&amp;gt;10&amp;lt;/ElevationLowSW&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationLowNW&amp;gt;10&amp;lt;/ElevationLowNW&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationLowSE&amp;gt;10&amp;lt;/ElevationLowSE&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationLowNE&amp;gt;10&amp;lt;/ElevationLowNE&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationHighSW&amp;gt;60&amp;lt;/ElevationHighSW&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationHighNW&amp;gt;60&amp;lt;/ElevationHighNW&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationHighSE&amp;gt;60&amp;lt;/ElevationHighSE&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationHighNE&amp;gt;60&amp;lt;/ElevationHighNE&amp;gt;&lt;br /&gt;
   &amp;lt;/GroundTextures&amp;gt;&lt;br /&gt;
   &amp;lt;Terrain&amp;gt;&lt;br /&gt;
     &amp;lt;WaterHeight&amp;gt;20&amp;lt;/WaterHeight&amp;gt;&lt;br /&gt;
     &amp;lt;TerrainRaiseLimit&amp;gt;100&amp;lt;/TerrainRaiseLimit&amp;gt;&lt;br /&gt;
     &amp;lt;TerrainLowerLimit&amp;gt;-100&amp;lt;/TerrainLowerLimit&amp;gt;&lt;br /&gt;
     &amp;lt;UseEstateSun&amp;gt;False&amp;lt;/UseEstateSun&amp;gt;&lt;br /&gt;
     &amp;lt;FixedSun&amp;gt;True&amp;lt;/FixedSun&amp;gt;&lt;br /&gt;
     &amp;lt;SunPosition&amp;gt;8.23999977111816&amp;lt;/SunPosition&amp;gt;&lt;br /&gt;
   &amp;lt;/Terrain&amp;gt;&lt;br /&gt;
   &amp;lt;Telehub&amp;gt;&lt;br /&gt;
     &amp;lt;TelehubObject&amp;gt;614af2ce-cbf7-45f5-906b-715b83bcba82&amp;lt;/TelehubObject&amp;gt;&lt;br /&gt;
     &amp;lt;SpawnPoint&amp;gt;0,0,0&amp;lt;/SpawnPoint&amp;gt;&lt;br /&gt;
     &amp;lt;SpawnPoint&amp;gt;-1.05136,-0.164772,4.29409&amp;lt;/SpawnPoint&amp;gt;&lt;br /&gt;
   &amp;lt;/Telehub&amp;gt;&lt;br /&gt;
 &amp;lt;/RegionSettings&amp;gt;&lt;br /&gt;
&lt;br /&gt;
= See Also =&lt;br /&gt;
&lt;br /&gt;
* [[OpenSim Archives|How to use OpenSimulator Archives (OAR)]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OpenSim_Archives</id>
		<title>OpenSim Archives</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OpenSim_Archives"/>
				<updated>2012-09-23T06:10:42Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* How do I use the OpenSimulator Archive Function? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= How do I use the OpenSimulator Archive Function? =&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
The OpenSimulator Archive (OAR) function has existed since OpenSimulator 0.5.9. The facility does a similar job to load-xml2/save-xml2 in that it saves prims so that they can be later reloaded. However, OpenSimulator archives (OAR) go a step further in that they can save all the necessary asset data so that you may fully restore the terrain, region parcel data, the textures of objects and their inventories when loaded onto a completely different system using a different asset database.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
From the region console, one can type &lt;br /&gt;
&lt;br /&gt;
 save oar [--noassets] [-h|--home=&amp;amp;lt;url&amp;amp;gt;] [--publish] [--perm=&amp;amp;lt;permissions&amp;amp;gt;] [--all] [&amp;amp;lt;filename&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
to save an OpenSimulator archive. If no filename is given, then the name region.oar is used in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 save oar&lt;br /&gt;
 save oar my.oar&lt;br /&gt;
 save oar c:/mybackups/filename.oar&lt;br /&gt;
 save oar oars/11nov.oar&lt;br /&gt;
&lt;br /&gt;
To load an archive, type &lt;br /&gt;
&lt;br /&gt;
 load oar [--merge] [--skip-assets] [&amp;amp;lt;location&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
at the console. The location can be a filesystem path (as for &amp;quot;save oar&amp;quot;) or an HTTP address to load an oar directly over the web. If no location is given, then the server looks for a file called region.oar in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 load oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar --merge oars/3rd-party.oar&lt;br /&gt;
 load oar http://path.to/oarfile.oar&lt;br /&gt;
&lt;br /&gt;
By default, loading an archive will delete all the existing objects in the regions and replace them with the archive contents. It's like being in the Matrix (when they swap environments), except much slower (all the scene objects are slowly deleted before the new environment is loaded&amp;amp;nbsp;:-) &lt;br /&gt;
&lt;br /&gt;
When an archive is loaded, owners will be restored if the relevant uuids can be found in the OpenSimulator installation's user database. Otherwise, prim ownership will default to the master avatar for the region. &lt;br /&gt;
&lt;br /&gt;
I recommend that you use filenames with the extension '''.oar'''. The filename extension of the download links on this page is '''.tar.gz''' which illustrates that the '''.oar''' format is actually a zipped tar file.&lt;br /&gt;
&lt;br /&gt;
=== Switches ===&lt;br /&gt;
==== Saving ====&lt;br /&gt;
&lt;br /&gt;
===== --publish =====&lt;br /&gt;
&lt;br /&gt;
If set, then objects in the saved oar are stripped of owner and last owner information, though not of creator information.&lt;br /&gt;
&lt;br /&gt;
This is useful if you are publishing OARs (rather than using them for backup) where those OARs might be loaded to the same grid from which you published.&lt;br /&gt;
&lt;br /&gt;
As of OpenSimulator 0.7.4, this switch will also strip ownership information from land parcels.&lt;br /&gt;
&lt;br /&gt;
===== --noassets =====&lt;br /&gt;
&lt;br /&gt;
If the --noassets option is specified then the oar will be saved without assets. This can be handy if you're backing up the asset database separately and don't want the expense of including all the assets in each OAR.&lt;br /&gt;
&lt;br /&gt;
===== --home =====&lt;br /&gt;
&lt;br /&gt;
(formerly known as --profile up to 0.7.3)&lt;br /&gt;
&lt;br /&gt;
If the --home option is specified then all names of creators from this world will be appended with links to their home world. It is not required that the service be operational; the information will be added and it will be available in all worlds that import this OAR.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;url&amp;gt; is the URL of this world's profile service. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --home=http://mygrid.com my.oar&lt;br /&gt;
&lt;br /&gt;
===== --perm =====&lt;br /&gt;
&lt;br /&gt;
If the --perm option is specified then objects with insufficient permissions will not be saved to the OAR. The user whose permissions are checked is the estate owner. This can be useful for grids that allow their customers to export their regions to OARs, because it ensures that exporting to OAR can't be used to bypass content permissions.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;permissions&amp;gt; specifies which permissions are required. It's a string that contains one or more of these characters:&lt;br /&gt;
* &amp;quot;C&amp;quot; = Copy&lt;br /&gt;
* &amp;quot;T&amp;quot; = Transfer&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --perm=CT my.oar&lt;br /&gt;
&lt;br /&gt;
===== --all =====&lt;br /&gt;
&lt;br /&gt;
If the --all option is specified then the OAR will contain all the regions in the simulator. If this option isn't specified (which is the default) then the OAR will contain only the current region.&lt;br /&gt;
&lt;br /&gt;
==== Loading ====&lt;br /&gt;
&lt;br /&gt;
===== --skip-assets =====&lt;br /&gt;
&lt;br /&gt;
If set, this will not attempt to load any of the assets from the OAR, though all other data will be loaded.  This can be useful if you are loading the OAR back into a grid that you know already contains the assets.&lt;br /&gt;
&lt;br /&gt;
===== --merge =====&lt;br /&gt;
&lt;br /&gt;
If the --merge option is specified then the oar will be merged with the existing region objects rather than replace them. The existing terrain, region settings and parcels will be left in place.&lt;br /&gt;
&lt;br /&gt;
== Example OARs ==&lt;br /&gt;
&lt;br /&gt;
[http://www.secondlifelab.it/downloads/cyberlandia.tar.gz cyberlandia.tar.gz] - cyberlandia landscape designed by the architect Simone Riccardi aka turboy. Contemporary architecture surrounded with a natural/synthetic context [http://www.flickr.com/photos/8905571@N05/3182585775/ image_1] [http://www.flickr.com/photos/8905571@N05/3171070049/ image_2] (work under [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons by attribution]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== OpenVCE 3D Assets OAR ===&lt;br /&gt;
&lt;br /&gt;
The [http://openvce.net OpenVCE.net] virtual worlds assets described at http://openvce.net/vwassets provided by Clever Zebra and the OpenVCE.net team at AIAI in the University of Edinburgh are available as an OAR (Opensim Archive) file.&lt;br /&gt;
&lt;br /&gt;
 http://openvce.net/resources/downloads/&lt;br /&gt;
&lt;br /&gt;
Get file &amp;quot;opensim-openvce.oar&amp;quot; from there (right click on the file in the above directory in your browser, and select download is the easiest way to obtain the materials). A &amp;quot;full&amp;quot; set of the buildings with a large 400 seat amphitheatre intended to be placed on the corner of 4 sims is also available via &amp;quot;opensim-openvce-full.oar&amp;quot;. Images of the buildings in place in Opensim are at:&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-1.jpg Image 1],&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-2.jpg Image 2]&lt;br /&gt;
&lt;br /&gt;
=== Others ===&lt;br /&gt;
&lt;br /&gt;
Please feel free to place links to other environments here, though unfortunately you'll have to host them on some other site. &lt;br /&gt;
&lt;br /&gt;
[http://www.hypergridbusiness.com/2011/06/where-to-get-content-for-opensim/ Where to get content for OpenSim]&amp;amp;nbsp;-- Hypergrid Business page, regularly updated, containing links to major OAR sites. Also has download links to individual OAR files. &lt;br /&gt;
&lt;br /&gt;
[http://www.lindakellie.com/myoars.htm LindaKellie.com] &lt;br /&gt;
&lt;br /&gt;
[http://opensim-creations.com/category/regions/oars/ OpenSimulator Creations] &lt;br /&gt;
&lt;br /&gt;
[http://www.opensimworlds.com/index.php?part=worlds http://www.opensimworlds.com/index.php?part=worlds]&lt;br /&gt;
&lt;br /&gt;
[http://forums.osgrid.org/viewforum.php?f=20 http://forums.osgrid.org/viewforum.php]&lt;br /&gt;
&lt;br /&gt;
== Further Information ==&lt;br /&gt;
&lt;br /&gt;
* [http://justincc.org/blog/category/oars/ http://justincc.org/blog/category/oars/] - various OAR related articles from justincc, including background information and possible future development.&lt;br /&gt;
&lt;br /&gt;
== Use cases ==&lt;br /&gt;
&lt;br /&gt;
Possible current uses are&lt;br /&gt;
&lt;br /&gt;
1. To migrate data from an SQLite region database to one based on MySQL&lt;br /&gt;
&lt;br /&gt;
2. To distribute entire regions to other people.&lt;br /&gt;
&lt;br /&gt;
== Current limitations ==&lt;br /&gt;
&lt;br /&gt;
* Performance is not very good, especially with large archives. This will be addressed in the future&lt;br /&gt;
* Loading large OARs using the default SQLite database plugin will take a very very long time (in the order of many hours). I highly recommend that you switch to MySQL if you want to load large archives.&lt;br /&gt;
&lt;br /&gt;
== OAR Format ==&lt;br /&gt;
&lt;br /&gt;
The region [[OpenSim Archives|OpenSimulator Archive (OAR)]] format is designed with three aims in mind:&lt;br /&gt;
&lt;br /&gt;
# Make it easy for people to read and change individual objects, assets, etc. within an archive.&lt;br /&gt;
# Make it easy to compose two region archives into a single region archive.&lt;br /&gt;
# Make it easy to compose archives from scratch.&lt;br /&gt;
&lt;br /&gt;
Therefore, all the different entities (assets, objects, terrains, etc.) are packaged in individual files (e.g. one for each asset) with human readable filenames and machine readable extensions (e.g. .jp2 for textures, .txt for notecards).&lt;br /&gt;
&lt;br /&gt;
* [[OAR Format 0.1]]&lt;br /&gt;
* [[OAR Format 0.2]]&lt;br /&gt;
* [[OAR Format 0.6]]&lt;br /&gt;
* [[OAR Format 0.7]]&lt;br /&gt;
* [[OAR Format 0.8]]&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
1. What is this .tar.gz format you are using for the internal OAR format? Why not zip?&lt;br /&gt;
&lt;br /&gt;
.tar.gz is a standard unix way of zipping up files into a single larger compressed file for distribution. Windows users should be able to open these files using freeware programs such as [http://www.7-zip.org/ 7-zip]. &lt;br /&gt;
&lt;br /&gt;
I'm using .tar.gz because all the zip (and tar) libraries for .net are licensed either under the GPL (with exception) or under the MSPL. Unfortunately, not all members of the OpenSimulator development team are comfortable with the MSPL, so these libaries are not currently an option. It is also significantly easier to write code to create and read tar archives than zip archives.&lt;br /&gt;
&lt;br /&gt;
Also, if you're only ever loading and saving oars (rather than pulling them apart and putting them back together), then you don't need to worry about the internal format at all :)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2. Can you load and save multiple regions to an archive?&lt;br /&gt;
&lt;br /&gt;
[[Feature_Proposals/Multi-Region_OARs|Present in development code, will be released in OpenSimulator 0.7.5.  Considered experimental.]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3. Can you load and save parts of a region to an archive?&lt;br /&gt;
&lt;br /&gt;
Not yet.&lt;br /&gt;
&lt;br /&gt;
== Bugs ==&lt;br /&gt;
&lt;br /&gt;
* Due to a possible bug in the Mono 1.2.4 libraries, this feature may cause a debug dump when used (the problem appears to be in writing out a compressed stream). Mono 1.2.6 is okay. Since Mono 1.2.4 is fairly old now, this bug will not be addressed.&lt;br /&gt;
&lt;br /&gt;
== Current Status ==&lt;br /&gt;
&lt;br /&gt;
Operational. Bug reports are appreciated [[User:Justincc|Justincc]] 14:53, 14 September 2009 (UTC)&lt;br /&gt;
&lt;br /&gt;
Though we will strive to maintain compatibilty for old archives with newer OpenSimulator versions, please don't rely on these archives as the only backup for regions.&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OpenSim_Archives</id>
		<title>OpenSim Archives</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OpenSim_Archives"/>
				<updated>2012-09-23T06:07:04Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Usage */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= How do I use the OpenSimulator Archive Function? =&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
The OpenSimulator Archive (OAR) function has existed since OpenSimulator 0.5.9. The facility does a similar job to load-xml2/save-xml2 in that it saves prims so that they can be later reloaded. However, OpenSimulator archives (OAR) go a step further in that they can save all the necessary asset data so that you may fully restore the terrain, region parcel data, the textures of objects and their inventories when loaded onto a completely different system using a different asset database.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
From the region console, one can type &lt;br /&gt;
&lt;br /&gt;
 save oar [--noassets] [-h|--home=&amp;amp;lt;url&amp;amp;gt;] [&amp;amp;lt;filename&amp;amp;gt;] [--all]&lt;br /&gt;
&lt;br /&gt;
to save an OpenSimulator archive. If no filename is given, then the name region.oar is used in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 save oar&lt;br /&gt;
 save oar my.oar&lt;br /&gt;
 save oar c:/mybackups/filename.oar&lt;br /&gt;
 save oar oars/11nov.oar&lt;br /&gt;
&lt;br /&gt;
To load an archive, type &lt;br /&gt;
&lt;br /&gt;
 load oar [--merge] [--skip-assets] [&amp;amp;lt;location&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
at the console. The location can be a filesystem path (as for &amp;quot;save oar&amp;quot;) or an HTTP address to load an oar directly over the web. If no location is given, then the server looks for a file called region.oar in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 load oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar --merge oars/3rd-party.oar&lt;br /&gt;
 load oar http://path.to/oarfile.oar&lt;br /&gt;
&lt;br /&gt;
By default, loading an archive will delete all the existing objects in the regions and replace them with the archive contents. It's like being in the Matrix (when they swap environments), except much slower (all the scene objects are slowly deleted before the new environment is loaded&amp;amp;nbsp;:-) &lt;br /&gt;
&lt;br /&gt;
When an archive is loaded, owners will be restored if the relevant uuids can be found in the OpenSimulator installation's user database. Otherwise, prim ownership will default to the master avatar for the region. &lt;br /&gt;
&lt;br /&gt;
I recommend that you use filenames with the extension '''.oar'''. The filename extension of the download links on this page is '''.tar.gz''' which illustrates that the '''.oar''' format is actually a zipped tar file.&lt;br /&gt;
&lt;br /&gt;
=== Switches ===&lt;br /&gt;
==== Saving ====&lt;br /&gt;
&lt;br /&gt;
===== --publish =====&lt;br /&gt;
&lt;br /&gt;
If set, then objects in the saved oar are stripped of owner and last owner information, though not of creator information.&lt;br /&gt;
&lt;br /&gt;
This is useful if you are publishing OARs (rather than using them for backup) where those OARs might be loaded to the same grid from which you published.&lt;br /&gt;
&lt;br /&gt;
As of OpenSimulator 0.7.4, this switch will also strip ownership information from land parcels.&lt;br /&gt;
&lt;br /&gt;
===== --noassets =====&lt;br /&gt;
&lt;br /&gt;
If the --noassets option is specified then the oar will be saved without assets. This can be handy if you're backing up the asset database separately and don't want the expense of including all the assets in each OAR.&lt;br /&gt;
&lt;br /&gt;
===== --home =====&lt;br /&gt;
&lt;br /&gt;
(formerly known as --profile up to 0.7.3)&lt;br /&gt;
&lt;br /&gt;
If the --home option is specified then all names of creators from this world will be appended with links to their home world. It is not required that the service be operational; the information will be added and it will be available in all worlds that import this OAR.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;url&amp;gt; is the URL of this world's profile service. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --home=http://mygrid.com my.oar&lt;br /&gt;
&lt;br /&gt;
===== --all =====&lt;br /&gt;
&lt;br /&gt;
If the --all option is specified then the OAR will contain all the regions in the simulator. If this option isn't specified (which is the default) then the OAR will contain only the current region.&lt;br /&gt;
&lt;br /&gt;
==== Loading ====&lt;br /&gt;
&lt;br /&gt;
===== --skip-assets =====&lt;br /&gt;
&lt;br /&gt;
If set, this will not attempt to load any of the assets from the OAR, though all other data will be loaded.  This can be useful if you are loading the OAR back into a grid that you know already contains the assets.&lt;br /&gt;
&lt;br /&gt;
===== --merge =====&lt;br /&gt;
&lt;br /&gt;
If the --merge option is specified then the oar will be merged with the existing region objects rather than replace them. The existing terrain, region settings and parcels will be left in place.&lt;br /&gt;
&lt;br /&gt;
== Example OARs ==&lt;br /&gt;
&lt;br /&gt;
[http://www.secondlifelab.it/downloads/cyberlandia.tar.gz cyberlandia.tar.gz] - cyberlandia landscape designed by the architect Simone Riccardi aka turboy. Contemporary architecture surrounded with a natural/synthetic context [http://www.flickr.com/photos/8905571@N05/3182585775/ image_1] [http://www.flickr.com/photos/8905571@N05/3171070049/ image_2] (work under [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons by attribution]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== OpenVCE 3D Assets OAR ===&lt;br /&gt;
&lt;br /&gt;
The [http://openvce.net OpenVCE.net] virtual worlds assets described at http://openvce.net/vwassets provided by Clever Zebra and the OpenVCE.net team at AIAI in the University of Edinburgh are available as an OAR (Opensim Archive) file.&lt;br /&gt;
&lt;br /&gt;
 http://openvce.net/resources/downloads/&lt;br /&gt;
&lt;br /&gt;
Get file &amp;quot;opensim-openvce.oar&amp;quot; from there (right click on the file in the above directory in your browser, and select download is the easiest way to obtain the materials). A &amp;quot;full&amp;quot; set of the buildings with a large 400 seat amphitheatre intended to be placed on the corner of 4 sims is also available via &amp;quot;opensim-openvce-full.oar&amp;quot;. Images of the buildings in place in Opensim are at:&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-1.jpg Image 1],&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-2.jpg Image 2]&lt;br /&gt;
&lt;br /&gt;
=== Others ===&lt;br /&gt;
&lt;br /&gt;
Please feel free to place links to other environments here, though unfortunately you'll have to host them on some other site. &lt;br /&gt;
&lt;br /&gt;
[http://www.hypergridbusiness.com/2011/06/where-to-get-content-for-opensim/ Where to get content for OpenSim]&amp;amp;nbsp;-- Hypergrid Business page, regularly updated, containing links to major OAR sites. Also has download links to individual OAR files. &lt;br /&gt;
&lt;br /&gt;
[http://www.lindakellie.com/myoars.htm LindaKellie.com] &lt;br /&gt;
&lt;br /&gt;
[http://opensim-creations.com/category/regions/oars/ OpenSimulator Creations] &lt;br /&gt;
&lt;br /&gt;
[http://www.opensimworlds.com/index.php?part=worlds http://www.opensimworlds.com/index.php?part=worlds]&lt;br /&gt;
&lt;br /&gt;
[http://forums.osgrid.org/viewforum.php?f=20 http://forums.osgrid.org/viewforum.php]&lt;br /&gt;
&lt;br /&gt;
== Further Information ==&lt;br /&gt;
&lt;br /&gt;
* [http://justincc.org/blog/category/oars/ http://justincc.org/blog/category/oars/] - various OAR related articles from justincc, including background information and possible future development.&lt;br /&gt;
&lt;br /&gt;
== Use cases ==&lt;br /&gt;
&lt;br /&gt;
Possible current uses are&lt;br /&gt;
&lt;br /&gt;
1. To migrate data from an SQLite region database to one based on MySQL&lt;br /&gt;
&lt;br /&gt;
2. To distribute entire regions to other people.&lt;br /&gt;
&lt;br /&gt;
== Current limitations ==&lt;br /&gt;
&lt;br /&gt;
* Performance is not very good, especially with large archives. This will be addressed in the future&lt;br /&gt;
* Loading large OARs using the default SQLite database plugin will take a very very long time (in the order of many hours). I highly recommend that you switch to MySQL if you want to load large archives.&lt;br /&gt;
&lt;br /&gt;
== Upcoming enhancements ==&lt;br /&gt;
&lt;br /&gt;
===== --perm =====&lt;br /&gt;
&lt;br /&gt;
A new option will be added when saving OARs:&lt;br /&gt;
&lt;br /&gt;
 save oar [--perm=&amp;amp;lt;permissions&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
If the --perm option is specified then objects with insufficient permissions will not be saved to the OAR. The user whose permissions are checked is the estate owner. This can be useful for grids that allow their customers to export their regions to OARs, because it ensures that exporting to OAR can't be used to bypass content permissions.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;permissions&amp;gt; specifies which permissions are required. It's a string that contains one or more of these characters:&lt;br /&gt;
* &amp;quot;C&amp;quot; = Copy&lt;br /&gt;
* &amp;quot;T&amp;quot; = Transfer&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --perm=CT my.oar&lt;br /&gt;
&lt;br /&gt;
== OAR Format ==&lt;br /&gt;
&lt;br /&gt;
The region [[OpenSim Archives|OpenSimulator Archive (OAR)]] format is designed with three aims in mind:&lt;br /&gt;
&lt;br /&gt;
# Make it easy for people to read and change individual objects, assets, etc. within an archive.&lt;br /&gt;
# Make it easy to compose two region archives into a single region archive.&lt;br /&gt;
# Make it easy to compose archives from scratch.&lt;br /&gt;
&lt;br /&gt;
Therefore, all the different entities (assets, objects, terrains, etc.) are packaged in individual files (e.g. one for each asset) with human readable filenames and machine readable extensions (e.g. .jp2 for textures, .txt for notecards).&lt;br /&gt;
&lt;br /&gt;
* [[OAR Format 0.1]]&lt;br /&gt;
* [[OAR Format 0.2]]&lt;br /&gt;
* [[OAR Format 0.6]]&lt;br /&gt;
* [[OAR Format 0.7]]&lt;br /&gt;
* [[OAR Format 0.8]]&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
1. What is this .tar.gz format you are using for the internal OAR format? Why not zip?&lt;br /&gt;
&lt;br /&gt;
.tar.gz is a standard unix way of zipping up files into a single larger compressed file for distribution. Windows users should be able to open these files using freeware programs such as [http://www.7-zip.org/ 7-zip]. &lt;br /&gt;
&lt;br /&gt;
I'm using .tar.gz because all the zip (and tar) libraries for .net are licensed either under the GPL (with exception) or under the MSPL. Unfortunately, not all members of the OpenSimulator development team are comfortable with the MSPL, so these libaries are not currently an option. It is also significantly easier to write code to create and read tar archives than zip archives.&lt;br /&gt;
&lt;br /&gt;
Also, if you're only ever loading and saving oars (rather than pulling them apart and putting them back together), then you don't need to worry about the internal format at all :)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2. Can you load and save multiple regions to an archive?&lt;br /&gt;
&lt;br /&gt;
[[Feature_Proposals/Multi-Region_OARs|Present in development code, will be released in OpenSimulator 0.7.5.  Considered experimental.]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3. Can you load and save parts of a region to an archive?&lt;br /&gt;
&lt;br /&gt;
Not yet.&lt;br /&gt;
&lt;br /&gt;
== Bugs ==&lt;br /&gt;
&lt;br /&gt;
* Due to a possible bug in the Mono 1.2.4 libraries, this feature may cause a debug dump when used (the problem appears to be in writing out a compressed stream). Mono 1.2.6 is okay. Since Mono 1.2.4 is fairly old now, this bug will not be addressed.&lt;br /&gt;
&lt;br /&gt;
== Current Status ==&lt;br /&gt;
&lt;br /&gt;
Operational. Bug reports are appreciated [[User:Justincc|Justincc]] 14:53, 14 September 2009 (UTC)&lt;br /&gt;
&lt;br /&gt;
Though we will strive to maintain compatibilty for old archives with newer OpenSimulator versions, please don't rely on these archives as the only backup for regions.&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Talk:Feature_Proposals/Multi-Region_OARs</id>
		<title>Talk:Feature Proposals/Multi-Region OARs</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Talk:Feature_Proposals/Multi-Region_OARs"/>
				<updated>2012-08-27T05:15:19Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Could we have regions starting from position 0, 0 instead of 1, 1, (e.g. 0_0_Arizona)?  I think this would make more sense when loading the parts of a moar.&lt;br /&gt;
&lt;br /&gt;
Is this compatible with a future situation where regions can be of different size (e.g. one of 256x256 and one of 128x128)?&lt;br /&gt;
&lt;br /&gt;
-- [[User:Justincc|Justincc]] 22:02, 20 August 2012 (UTC)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
I chose 1-based numbering because it's more user friendly (for users, not developers), and because that's the convention that was established by Diva for megaregions. See for example http://opensimulator.org/wiki/Megaregions and http://uc.onikenkon.com/.&lt;br /&gt;
&lt;br /&gt;
The file format could work for region sizes other than 256x256 because each region already specifies its size, so when loading the OAR it's possible to calculate the correct location for each piece.&lt;br /&gt;
&lt;br /&gt;
--[[User:Orenh|Orenh]] 05:15, 27 August 2012 (UTC)&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Feature_Proposals/Multi-Region_OARs</id>
		<title>Feature Proposals/Multi-Region OARs</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Feature_Proposals/Multi-Region_OARs"/>
				<updated>2012-08-03T07:22:30Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Created page with &amp;quot;This feature extends the OAR format to allow saving multiple regions in a single file.  The save-oar command still creates single-region OARs by default (OAR version 0.8). It sav...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This feature extends the OAR format to allow saving multiple regions in a single file.&lt;br /&gt;
&lt;br /&gt;
The save-oar command still creates single-region OARs by default (OAR version 0.8). It saves the new format if the &amp;quot;--all&amp;quot; parameter is specified. The new format has version number 1.0 because older versions of OpenSim can't read it.&lt;br /&gt;
&lt;br /&gt;
The load-oar command supports both OAR formats (0.x and 1.x). When it's given a 1.x OAR file it loads all the regions in the OAR into the corresponding regions in the simulator, according to their position relative to the root region. If the simulator doesn't have a region in a location that is present in the OAR then that region isn't loaded.&lt;br /&gt;
&lt;br /&gt;
The layout of the OAR file is as follows. Each region is stored in a separate directory, but the assets are shared:&lt;br /&gt;
&lt;br /&gt;
 archive.xml&lt;br /&gt;
 assets/&lt;br /&gt;
 regions/&lt;br /&gt;
   1_1_Arizona/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
   2_1_New_Mexico/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
   1_2_Utah/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
   2_2_Colorado/&lt;br /&gt;
     landdata/&lt;br /&gt;
     objects/&lt;br /&gt;
     settings/&lt;br /&gt;
     terrain/&lt;br /&gt;
&lt;br /&gt;
The regions' directory names include the region's location (relative to the root region) in order to ensure uniqueness even if regions have duplicate names.&lt;br /&gt;
&lt;br /&gt;
The file archive.xml contains a manifest of the included regions. The list of regions always describes a rectangle, with the root region (the region where the &amp;quot;save-oar&amp;quot; command was run) in the SW corner. The regions are listed in the following order: rows from South to North, and within each row regions are listed West-to-East. Missing regions are supported: they're represented by empty elements.&lt;br /&gt;
&lt;br /&gt;
For example:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-16&amp;quot;?&amp;gt;&lt;br /&gt;
 &amp;lt;archive major_version=&amp;quot;1&amp;quot; minor_version=&amp;quot;0&amp;quot;&amp;gt;&lt;br /&gt;
   &amp;lt;creation_info&amp;gt;&lt;br /&gt;
     &amp;lt;datetime&amp;gt;1343204139&amp;lt;/datetime&amp;gt;&lt;br /&gt;
   &amp;lt;/creation_info&amp;gt;&lt;br /&gt;
   &amp;lt;assets_included&amp;gt;True&amp;lt;/assets_included&amp;gt;&lt;br /&gt;
   &amp;lt;regions&amp;gt;&lt;br /&gt;
     &amp;lt;row&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-1111-1111-1111-111111111111&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;1_1_Arizona&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-2222-2222-2222-222222222222&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;2_1_New_Mexico&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
     &amp;lt;/row&amp;gt;&lt;br /&gt;
     &amp;lt;row&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-3333-3333-3333-333333333333&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;1_2_Utah&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
       &amp;lt;region&amp;gt;&lt;br /&gt;
         &amp;lt;id&amp;gt;12345678-4444-4444-4444-444444444444&amp;lt;/id&amp;gt;&lt;br /&gt;
         &amp;lt;dir&amp;gt;2_2_Colorado&amp;lt;/dir&amp;gt;&lt;br /&gt;
         &amp;lt;is_megaregion&amp;gt;False&amp;lt;/is_megaregion&amp;gt;&lt;br /&gt;
         &amp;lt;size_in_meters&amp;gt;256,256&amp;lt;/size_in_meters&amp;gt;&lt;br /&gt;
       &amp;lt;/region&amp;gt;&lt;br /&gt;
     &amp;lt;/row&amp;gt;&lt;br /&gt;
   &amp;lt;/regions&amp;gt;&lt;br /&gt;
 &amp;lt;/archive&amp;gt;&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Feature_Proposals</id>
		<title>Feature Proposals</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Feature_Proposals"/>
				<updated>2012-08-03T07:11:01Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: /* Feature Proposals */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Feature Proposals==&lt;br /&gt;
If you want to propose a feature, you should do so on the opensim-dev mailing list. If there is interest or if you plan to write the code yourself, you can create a page here. Please do not propose features in the Mantis bug tracker. Please do not propose features if you don't have a clear idea of how they would work on a technical level. Please do not propose features expecting other people to do the implementation work without convincing them first - this will not happen.&lt;br /&gt;
&lt;br /&gt;
If you're adding a proposal here, please do it with a page name of Feature_Proposals/&amp;lt;name of service&amp;gt;. For example Feature_Proposals/AutoBackup.&lt;br /&gt;
&lt;br /&gt;
=== Templates ===&lt;br /&gt;
&lt;br /&gt;
* [[Feature Proposal Template]] - Use this template for your document.&lt;br /&gt;
&lt;br /&gt;
=== Present ===&lt;br /&gt;
&lt;br /&gt;
* [[Feature Proposals/Multi-Region OARs]]&lt;br /&gt;
* [[Feature Proposals/Deduplicating Asset Service]]&lt;br /&gt;
* [[IntegrationService]]&lt;br /&gt;
&lt;br /&gt;
=== Past ===&lt;br /&gt;
&lt;br /&gt;
* [[Feature Proposals/AutoBackup|AutoBackup]]&lt;br /&gt;
* [[Statistics Server]] - Proposal for a statistics server in OpenSimulator.&lt;br /&gt;
* [[OpenID]] - Proposal for using OpenID in OpenSimulator&lt;br /&gt;
* [[AssetServerProposal]] - Proposal for a distributed asset server&lt;br /&gt;
* [[A better SimCrossing]] - A work in progress about implementing a smooth simcrossing&lt;br /&gt;
* [[Creating profiles not used for login]] - RFC for alternative ways of creating profiles that will never be used for login&lt;br /&gt;
* [[OpenSim Profile Anchors]] - a mechanism for retaining creator information for offline item transfers&lt;br /&gt;
* [[Explicit Object Serialization]] - a proposal to explicitly serialize scene objects rather than using automatic .NET XML serialization&lt;br /&gt;
* [[Opensim: 0.5 Release Target Discussion]]&lt;br /&gt;
* [[Opensim: 0.6 Release Target Discussion]]&lt;br /&gt;
* [[Opensim: Future Release Discussion]]&lt;br /&gt;
* [[OpenWiredux: Taking the next step]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;br /&gt;
[[Category:Proposal]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OAR_Format_0.8</id>
		<title>OAR Format 0.8</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OAR_Format_0.8"/>
				<updated>2012-05-16T09:24:45Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: Created page with &amp;quot;{{Quicklinks}} &amp;lt;br /&amp;gt;  = What is the OAR 0.8 format? =  == Changes ==  This format is currently in the development version of OpenSimulator only. Please do not rely on it as the ...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
= What is the OAR 0.8 format? =&lt;br /&gt;
&lt;br /&gt;
== Changes ==&lt;br /&gt;
&lt;br /&gt;
This format is currently in the development version of OpenSimulator only. Please do not rely on it as the details are subject to change without notice.&lt;br /&gt;
&lt;br /&gt;
OAR format 0.8 is identical to 0.7 except that the region's Telehub (if it exists) is now saved.&lt;br /&gt;
&lt;br /&gt;
== Detail ==&lt;br /&gt;
&lt;br /&gt;
At the present time, a region archive is a gzipped tar file (tar.gz) in the the original unix tar format (not USTAR). This can be extracted and created with standard tools ([http://www.7-zip.org/ 7-zip] on Windows). The structure of the archive is as follows&lt;br /&gt;
&lt;br /&gt;
 archive.xml&lt;br /&gt;
 assets/&lt;br /&gt;
 landdata/&lt;br /&gt;
 objects/&lt;br /&gt;
 settings/&lt;br /&gt;
 terrains/&lt;br /&gt;
&lt;br /&gt;
=== archive.xml ===&lt;br /&gt;
&lt;br /&gt;
This is the archive control file. It contains a major and minor version number, to allow compatibility with future format changes.&lt;br /&gt;
It also contains an &amp;lt;assets_included&amp;gt; element which can have the contents True or False. If the string is True, then the OAR was saved with assets included. If the switch is False, then the OAR was saved with the --noassets option.&lt;br /&gt;
&lt;br /&gt;
=== assets/ ===&lt;br /&gt;
&lt;br /&gt;
This directory contains all the assets in the archive. Each filename has the following format&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;uuid&amp;gt;_&amp;lt;asset type&amp;gt;.&amp;lt;asset extension&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The ''uuid'' section must always be present and form a valid uuid - it is used directly as the uuid for that asset. The ''asset type'' and ''asset extension'' are used to identify the type of asset and the ''asset extension'' allows the asset to be associated with different editors on platforms such as Windows. For instance, a script will always have the asset type and extension script.lsl. A full list of asset types and extensions can be found in the file &lt;br /&gt;
&lt;br /&gt;
 OpenSim/Region/Environment/Modules/World/Archiver/ArchiveConstants.cs&lt;br /&gt;
&lt;br /&gt;
in the OpenSimulator distribution.&lt;br /&gt;
&lt;br /&gt;
In the future, the format of these files will be described in [[Asset Formats]].&lt;br /&gt;
&lt;br /&gt;
=== landdata/ ===&lt;br /&gt;
&lt;br /&gt;
This directory contains all the parcels in the region. Information for each parcel is stored in a separate file in XML format. Each filename has the form:&lt;br /&gt;
&lt;br /&gt;
  &amp;lt;uuid&amp;gt;.xml&lt;br /&gt;
&lt;br /&gt;
where ''uuid'' is the uuid of the parcel.&lt;br /&gt;
&lt;br /&gt;
=== objects/ ===&lt;br /&gt;
&lt;br /&gt;
Each individual file in here is an object in the region (where an object [linkset] can be composed of many prims). The file format used is OpenSim's XML2 format. Each filename has the following structure by default&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;Object name&amp;gt;_&amp;lt;x&amp;gt;-&amp;lt;y&amp;gt;-&amp;lt;z&amp;gt;__&amp;lt;uuid&amp;gt;.xml&lt;br /&gt;
&lt;br /&gt;
Unlike asset filenames, any component of this name can be changed without affecting any attributes of the object itself - this information is taken from the xml instead. Indeed, this file can have any name - there is no need for any of the sections to be present. An example object file name is&lt;br /&gt;
&lt;br /&gt;
 Primitive_154-121-062__9be68fdd-f740-4a0f-9675-dfbbb536b946.xml&lt;br /&gt;
&lt;br /&gt;
The actual format is described (currently very sketchily) in [[Asset Formats]].&lt;br /&gt;
&lt;br /&gt;
=== settings/ ===&lt;br /&gt;
&lt;br /&gt;
This contains the region settings information for the region in XML format. The filename will be the same as the region name. For example,&lt;br /&gt;
&lt;br /&gt;
 OpenSimulator Test.xml&lt;br /&gt;
&lt;br /&gt;
See an example of an XML region settings file below.&lt;br /&gt;
&lt;br /&gt;
=== terrains/ ===&lt;br /&gt;
&lt;br /&gt;
This contains the terrain file for the region, stored in RAW format. The filename must end with .r32. For example,&lt;br /&gt;
&lt;br /&gt;
 OpenSimulator Test.r32&lt;br /&gt;
&lt;br /&gt;
= Region Settings Example =&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;utf-16&amp;quot;?&amp;gt;&lt;br /&gt;
 &amp;lt;RegionSettings&amp;gt;&lt;br /&gt;
   &amp;lt;General&amp;gt;&lt;br /&gt;
     &amp;lt;AllowDamage&amp;gt;False&amp;lt;/AllowDamage&amp;gt;&lt;br /&gt;
     &amp;lt;AllowLandResell&amp;gt;True&amp;lt;/AllowLandResell&amp;gt;&lt;br /&gt;
     &amp;lt;AllowLandJoinDivide&amp;gt;True&amp;lt;/AllowLandJoinDivide&amp;gt;&lt;br /&gt;
     &amp;lt;BlockFly&amp;gt;False&amp;lt;/BlockFly&amp;gt;&lt;br /&gt;
     &amp;lt;BlockLandShowInSearch&amp;gt;False&amp;lt;/BlockLandShowInSearch&amp;gt;&lt;br /&gt;
     &amp;lt;BlockTerraform&amp;gt;False&amp;lt;/BlockTerraform&amp;gt;&lt;br /&gt;
     &amp;lt;DisableCollisions&amp;gt;False&amp;lt;/DisableCollisions&amp;gt;&lt;br /&gt;
     &amp;lt;DisablePhysics&amp;gt;False&amp;lt;/DisablePhysics&amp;gt;&lt;br /&gt;
     &amp;lt;DisableScripts&amp;gt;False&amp;lt;/DisableScripts&amp;gt;&lt;br /&gt;
     &amp;lt;MaturityRating&amp;gt;1&amp;lt;/MaturityRating&amp;gt;&lt;br /&gt;
     &amp;lt;RestrictPushing&amp;gt;False&amp;lt;/RestrictPushing&amp;gt;&lt;br /&gt;
     &amp;lt;AgentLimit&amp;gt;40&amp;lt;/AgentLimit&amp;gt;&lt;br /&gt;
     &amp;lt;ObjectBonus&amp;gt;1&amp;lt;/ObjectBonus&amp;gt;&lt;br /&gt;
   &amp;lt;/General&amp;gt;&lt;br /&gt;
   &amp;lt;GroundTextures&amp;gt;&lt;br /&gt;
     &amp;lt;Texture1&amp;gt;b8d3965a-ad78-bf43-699b-bff8eca6c975&amp;lt;/Texture1&amp;gt;&lt;br /&gt;
     &amp;lt;Texture2&amp;gt;abb783e6-3e93-26c0-248a-247666855da3&amp;lt;/Texture2&amp;gt;&lt;br /&gt;
     &amp;lt;Texture3&amp;gt;179cdabd-398a-9b6b-1391-4dc333ba321f&amp;lt;/Texture3&amp;gt;&lt;br /&gt;
     &amp;lt;Texture4&amp;gt;beb169c7-11ea-fff2-efe5-0f24dc881df2&amp;lt;/Texture4&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationLowSW&amp;gt;10&amp;lt;/ElevationLowSW&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationLowNW&amp;gt;10&amp;lt;/ElevationLowNW&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationLowSE&amp;gt;10&amp;lt;/ElevationLowSE&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationLowNE&amp;gt;10&amp;lt;/ElevationLowNE&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationHighSW&amp;gt;60&amp;lt;/ElevationHighSW&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationHighNW&amp;gt;60&amp;lt;/ElevationHighNW&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationHighSE&amp;gt;60&amp;lt;/ElevationHighSE&amp;gt;&lt;br /&gt;
     &amp;lt;ElevationHighNE&amp;gt;60&amp;lt;/ElevationHighNE&amp;gt;&lt;br /&gt;
   &amp;lt;/GroundTextures&amp;gt;&lt;br /&gt;
   &amp;lt;Terrain&amp;gt;&lt;br /&gt;
     &amp;lt;WaterHeight&amp;gt;20&amp;lt;/WaterHeight&amp;gt;&lt;br /&gt;
     &amp;lt;TerrainRaiseLimit&amp;gt;100&amp;lt;/TerrainRaiseLimit&amp;gt;&lt;br /&gt;
     &amp;lt;TerrainLowerLimit&amp;gt;-100&amp;lt;/TerrainLowerLimit&amp;gt;&lt;br /&gt;
     &amp;lt;UseEstateSun&amp;gt;False&amp;lt;/UseEstateSun&amp;gt;&lt;br /&gt;
     &amp;lt;FixedSun&amp;gt;True&amp;lt;/FixedSun&amp;gt;&lt;br /&gt;
     &amp;lt;SunPosition&amp;gt;8.23999977111816&amp;lt;/SunPosition&amp;gt;&lt;br /&gt;
   &amp;lt;/Terrain&amp;gt;&lt;br /&gt;
   &amp;lt;Telehub&amp;gt;&lt;br /&gt;
     &amp;lt;TelehubObject&amp;gt;614af2ce-cbf7-45f5-906b-715b83bcba82&amp;lt;/TelehubObject&amp;gt;&lt;br /&gt;
     &amp;lt;SpawnPoint&amp;gt;0,0,0&amp;lt;/SpawnPoint&amp;gt;&lt;br /&gt;
     &amp;lt;SpawnPoint&amp;gt;-1.05136,-0.164772,4.29409&amp;lt;/SpawnPoint&amp;gt;&lt;br /&gt;
   &amp;lt;/Telehub&amp;gt;&lt;br /&gt;
 &amp;lt;/RegionSettings&amp;gt;&lt;br /&gt;
&lt;br /&gt;
= See Also =&lt;br /&gt;
&lt;br /&gt;
* [[OpenSim Archives|How to use OpenSimulator Archives (OAR)]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/OpenSim_Archives</id>
		<title>OpenSim Archives</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/OpenSim_Archives"/>
				<updated>2012-05-16T09:12:42Z</updated>
		
		<summary type="html">&lt;p&gt;Orenh: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Quicklinks}}&lt;br /&gt;
&lt;br /&gt;
= How do I use the OpenSimulator Archive Function? =&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
The OpenSimulator Archive (OAR) function has existed since OpenSimulator 0.5.9. The facility does a similar job to load-xml2/save-xml2 in that it saves prims so that they can be later reloaded. However, OpenSimulator archives (OAR) go a step further in that they can save all the necessary asset data so that you may fully restore the terrain, region parcel data, the textures of objects and their inventories when loaded onto a completely different system using a different asset database.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
From the region console, one can type &lt;br /&gt;
&lt;br /&gt;
 save oar [--noassets] [-h|--home=&amp;amp;lt;url&amp;amp;gt;] [&amp;amp;lt;filename&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
to save an OpenSimulator archive. If no filename is given, then the name region.oar is used in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 save oar&lt;br /&gt;
 save oar my.oar&lt;br /&gt;
 save oar c:/mybackups/filename.oar&lt;br /&gt;
 save oar oars/11nov.oar&lt;br /&gt;
&lt;br /&gt;
To load an archive, type &lt;br /&gt;
&lt;br /&gt;
 load oar [--merge] [&amp;amp;lt;location&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
at the console. The location can be a filesystem path (as for &amp;quot;save oar&amp;quot;) or an HTTP address to load an oar directly over the web. If no location is given, then the server looks for a file called region.oar in the current directory. &lt;br /&gt;
&lt;br /&gt;
'''EXAMPLES:'''&lt;br /&gt;
 load oar&lt;br /&gt;
 load oar my.oar&lt;br /&gt;
 load oar --merge oars/3rd-party.oar&lt;br /&gt;
 load oar http://path.to/oarfile.oar&lt;br /&gt;
&lt;br /&gt;
By default, loading an archive will delete all the existing objects in the regions and replace them with the archive contents. It's like being in the Matrix (when they swap environments), except much slower (all the scene objects are slowly deleted before the new environment is loaded&amp;amp;nbsp;:-) &lt;br /&gt;
&lt;br /&gt;
When an archive is loaded, owners will be restored if the relevant uuids can be found in the OpenSimulator installation's user database. Otherwise, prim ownership will default to the master avatar for the region. &lt;br /&gt;
&lt;br /&gt;
I recommend that you use filenames with the extension '''.oar'''. The filename extension of the download links on this page is '''.tar.gz''' which illustrates that the '''.oar''' format is actually a zipped tar file.&lt;br /&gt;
&lt;br /&gt;
=== Switches ===&lt;br /&gt;
==== Saving ====&lt;br /&gt;
&lt;br /&gt;
===== --noassets =====&lt;br /&gt;
&lt;br /&gt;
If the --noassets option is specified then the oar will be saved without assets. This can be handy if you're backing up the asset database separately and don't want the expense of including all the assets in each OAR.&lt;br /&gt;
&lt;br /&gt;
===== --home =====&lt;br /&gt;
&lt;br /&gt;
(formerly known as --profile up to 0.7.3)&lt;br /&gt;
&lt;br /&gt;
If the --home option is specified then all names of creators from this world will be appended with links to their home world. It is not required that the service be operational; the information will be added and it will be available in all worlds that import this OAR.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;url&amp;gt; is the URL of this world's profile service. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --home=http://mygrid.com my.oar&lt;br /&gt;
&lt;br /&gt;
==== Loading ====&lt;br /&gt;
&lt;br /&gt;
===== --merge =====&lt;br /&gt;
&lt;br /&gt;
If the --merge option is specified then the oar will be merged with the existing region objects rather than replace them. The existing terrain, region settings and parcels will be left in place.&lt;br /&gt;
&lt;br /&gt;
== Example OARs ==&lt;br /&gt;
&lt;br /&gt;
[http://www.secondlifelab.it/downloads/cyberlandia.tar.gz cyberlandia.tar.gz] - cyberlandia landscape designed by the architect Simone Riccardi aka turboy. Contemporary architecture surrounded with a natural/synthetic context [http://www.flickr.com/photos/8905571@N05/3182585775/ image_1] [http://www.flickr.com/photos/8905571@N05/3171070049/ image_2] (work under [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons by attribution]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== OpenVCE 3D Assets OAR ===&lt;br /&gt;
&lt;br /&gt;
The [http://openvce.net OpenVCE.net] virtual worlds assets described at http://openvce.net/vwassets provided by Clever Zebra and the OpenVCE.net team at AIAI in the University of Edinburgh are available as an OAR (Opensim Archive) file.&lt;br /&gt;
&lt;br /&gt;
 http://openvce.net/resources/downloads/&lt;br /&gt;
&lt;br /&gt;
Get file &amp;quot;opensim-openvce.oar&amp;quot; from there (right click on the file in the above directory in your browser, and select download is the easiest way to obtain the materials). A &amp;quot;full&amp;quot; set of the buildings with a large 400 seat amphitheatre intended to be placed on the corner of 4 sims is also available via &amp;quot;opensim-openvce-full.oar&amp;quot;. Images of the buildings in place in Opensim are at:&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-1.jpg Image 1],&lt;br /&gt;
[http://openvce.net/resources/downloads/opensim-openvce-2.jpg Image 2]&lt;br /&gt;
&lt;br /&gt;
=== Others ===&lt;br /&gt;
&lt;br /&gt;
Please feel free to place links to other environments here, though unfortunately you'll have to host them on some other site. &lt;br /&gt;
&lt;br /&gt;
[http://www.hypergridbusiness.com/2011/06/where-to-get-content-for-opensim/ Where to get content for OpenSim]&amp;amp;nbsp;-- Hypergrid Business page, regularly updated, containing links to major OAR sites. Also has download links to individual OAR files. &lt;br /&gt;
&lt;br /&gt;
[http://www.lindakellie.com/myoars.htm LindaKellie.com] &lt;br /&gt;
&lt;br /&gt;
[http://opensim-creations.com/category/regions/oars/ OpenSimulator Creations] &lt;br /&gt;
&lt;br /&gt;
[http://www.opensimworlds.com/index.php?part=worlds http://www.opensimworlds.com/index.php?part=worlds] &lt;br /&gt;
&lt;br /&gt;
[http://www.rexxed.com/category/sim/ http://www.rexxed.com/category/sim/]&amp;lt;br /&amp;gt; &lt;br /&gt;
&lt;br /&gt;
[http://forums.osgrid.org/viewforum.php?f=20 http://forums.osgrid.org/viewforum.php]&lt;br /&gt;
&lt;br /&gt;
== Further Information ==&lt;br /&gt;
&lt;br /&gt;
* [http://justincc.org/blog/category/oars/ http://justincc.org/blog/category/oars/] - various OAR related articles from justincc, including background information and possible future development.&lt;br /&gt;
&lt;br /&gt;
== Use cases ==&lt;br /&gt;
&lt;br /&gt;
Possible current uses are&lt;br /&gt;
&lt;br /&gt;
1. To migrate data from an SQLite region database to one based on MySQL&lt;br /&gt;
&lt;br /&gt;
2. To distribute entire regions to other people.&lt;br /&gt;
&lt;br /&gt;
== Current limitations ==&lt;br /&gt;
&lt;br /&gt;
* Performance is not very good, especially with large archives. This will be addressed in the future&lt;br /&gt;
* Loading large OARs using the default SQLite database plugin will take a very very long time (in the order of many hours). I highly recommend that you switch to MySQL if you want to load large archives.&lt;br /&gt;
&lt;br /&gt;
== Upcoming enhancements ==&lt;br /&gt;
&lt;br /&gt;
===== --perm =====&lt;br /&gt;
&lt;br /&gt;
A new option will be added when saving OARs:&lt;br /&gt;
&lt;br /&gt;
 save oar [--perm=&amp;amp;lt;permissions&amp;amp;gt;]&lt;br /&gt;
&lt;br /&gt;
If the --perm option is specified then objects with insufficient permissions will not be saved to the OAR. The user whose permissions are checked is the estate owner. This can be useful for grids that allow their customers to export their regions to OARs, because it ensures that exporting to OAR can't be used to bypass content permissions.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;permissions&amp;gt; specifies which permissions are required. It's a string that contains one or more of these characters:&lt;br /&gt;
* &amp;quot;C&amp;quot; = Copy&lt;br /&gt;
* &amp;quot;T&amp;quot; = Transfer&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  save oar --perm=CT my.oar&lt;br /&gt;
&lt;br /&gt;
== OAR Format ==&lt;br /&gt;
&lt;br /&gt;
The region [[OpenSim Archives|OpenSimulator Archive (OAR)]] format is designed with three aims in mind:&lt;br /&gt;
&lt;br /&gt;
# Make it easy for people to read and change individual objects, assets, etc. within an archive.&lt;br /&gt;
# Make it easy to compose two region archives into a single region archive.&lt;br /&gt;
# Make it easy to compose archives from scratch.&lt;br /&gt;
&lt;br /&gt;
Therefore, all the different entities (assets, objects, terrains, etc.) are packaged in individual files (e.g. one for each asset) with human readable filenames and machine readable extensions (e.g. .jp2 for textures, .txt for notecards).&lt;br /&gt;
&lt;br /&gt;
* [[OAR Format 0.1]]&lt;br /&gt;
* [[OAR Format 0.2]]&lt;br /&gt;
* [[OAR Format 0.6]]&lt;br /&gt;
* [[OAR Format 0.7]]&lt;br /&gt;
* [[OAR Format 0.8]]&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
1. What is this .tar.gz format you are using for the internal OAR format? Why not zip?&lt;br /&gt;
&lt;br /&gt;
.tar.gz is a standard unix way of zipping up files into a single larger compressed file for distribution. Windows users should be able to open these files using freeware programs such as [http://www.7-zip.org/ 7-zip]. &lt;br /&gt;
&lt;br /&gt;
I'm using .tar.gz because all the zip (and tar) libraries for .net are licensed either under the GPL (with exception) or under the MSPL. Unfortunately, not all members of the OpenSimulator development team are comfortable with the MSPL, so these libaries are not currently an option. It is also significantly easier to write code to create and read tar archives than zip archives.&lt;br /&gt;
&lt;br /&gt;
Also, if you're only ever loading and saving oars (rather than pulling them apart and putting them back together), then you don't need to worry about the internal format at all :)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2. Can you load and save multiple regions to an archive?&lt;br /&gt;
&lt;br /&gt;
Not yet.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3. Can you load and save parts of a region to an archive?&lt;br /&gt;
&lt;br /&gt;
Not yet.&lt;br /&gt;
&lt;br /&gt;
== Bugs ==&lt;br /&gt;
&lt;br /&gt;
* Due to a possible bug in the Mono 1.2.4 libraries, this feature may cause a debug dump when used (the problem appears to be in writing out a compressed stream). Mono 1.2.6 is okay. Since Mono 1.2.4 is fairly old now, this bug will not be addressed.&lt;br /&gt;
&lt;br /&gt;
== Current Status ==&lt;br /&gt;
&lt;br /&gt;
Operational. Bug reports are appreciated [[User:Justincc|Justincc]] 14:53, 14 September 2009 (UTC)&lt;br /&gt;
&lt;br /&gt;
Though we will strive to maintain compatibilty for old archives with newer OpenSimulator versions, please don't rely on these archives as the only backup for regions.&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Support]]&lt;br /&gt;
[[Category:Tech Reference]]&lt;br /&gt;
[[Category:Help]]&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Orenh</name></author>	</entry>

	</feed>