OpenSimulator - User contributions [en]

OsRevokeScriptPermissions

2015-02-27T20:12:58Z

BlueWall:

{{osslfunc
|threat_level=Severe '''(Pending Peer Review)'''
|function_syntax=void osRevokeScriptPermissions(key revoked_key, string function)
|ossl_example=<source lang="lsl">
list functions = ["osNpcCreate", "osNpcGetPos", "osNpcLoadAppearance", "osNpcGetRot", "osNpcMoveTo",
"osNpcRemove", "osNpcSaveAppearance", "osNpcSay", "osNpcSetRot","osNpcSit", "osNpcStand",
"osNpcPlayAnimation", "osNpcStopAnimation","osNpcMoveToTarget", "osNpcStopMoveToTarget",
"osOwnerSaveAppearance", "osAgentSaveAppearance"];

default
{
state_entry()
{
llSetColor(<1,0,0>,ALL_SIDES);
}

touch_start(integer det)
{
llSay(0, "Enable");

osGrantScriptPermissions(llGetOwner(), functions);
state enabled;
}
}

state enabled
{
state_entry()
{
llSetColor(<0,1,0>,ALL_SIDES);
llSay(0, "ossl functions enabled");
}

touch_start(integer det)
{
osRevokeScriptPermissions(llGetOwner(), functions);
state default;
}
}
</source>
This example will allow the owner of this object to create and manipulate NPCs. To allow other possibilities, change the llGetOwner() to any key for another avatar or group. The osRevokeScriptPermissions uses the same syntax to remove previuosly granted permissions.
|description=Dynamically allow/disallow ossl execution to owner/creator/group by function name.
|
}}

OsGrantScriptPermissions

2015-02-27T20:10:33Z

BlueWall:

{{osslfunc
|threat_level=Severe '''(Pending Peer Review)'''
|function_syntax=void osGrantScriptPermissions(key allowed_key, string function)
|ossl_example=<source lang="lsl">
list functions = ["osNpcCreate", "osNpcGetPos", "osNpcLoadAppearance", "osNpcGetRot", "osNpcMoveTo",
"osNpcRemove", "osNpcSaveAppearance", "osNpcSay", "osNpcSetRot","osNpcSit", "osNpcStand",
"osNpcPlayAnimation", "osNpcStopAnimation","osNpcMoveToTarget", "osNpcStopMoveToTarget",
"osOwnerSaveAppearance", "osAgentSaveAppearance"];

default
{
state_entry()
{
llSetColor(<1,0,0>,ALL_SIDES);
}

touch_start(integer det)
{
llSay(0, "Enable");

osGrantScriptPermissions(llGetOwner(), functions);
state enabled;
}
}

state enabled
{
state_entry()
{
llSetColor(<0,1,0>,ALL_SIDES);
llSay(0, "ossl functions enabled");
}

touch_start(integer det)
{
osRevokeScriptPermissions(llGetOwner(), functions);
state default;
}
}
</source>
This example will allow the owner of this object to create and manipulate NPCs. To allow other possibilities, change the llGetOwner() to any key for another avatar or group.
|description=Dynamically allow ossl execution to owner/creator/group by function name.
|
}}

Category:OSSL Functions

2015-02-27T20:08:50Z

BlueWall: /* Script Permissions */

== Current OSSL Functions Implemented ==

Updated OSSL Functions as of OpenSim DEV 0.7.4 r/21068 17th November, 2012
<br /><br />
'''!''' 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.

Special Note: Some Functions as shown use '''"double"''' as a Value instead of '''"float" '''these vary for purposes of accuracy as shown Below.

(Float is short for "floating point", and just means a number with a point something on the end.)

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 )

Note that some function takes doubles as arguments but may be internally down-casted to floats.

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.

=== Avatars ===
{{multicol}}
*[[osGetAgentIP]]
*[[osGetAgents]]
*[[osGetAvatarList]]
*[[osAvatarName2Key]]
*[[osAvatarPlayAnimation]]
*[[osAvatarStopAnimation]]
*[[osAgentSaveAppearance]]
*[[osOwnerSaveAppearance]]
*[[osTeleportAgent]]
*[[osTeleportOwner]]
*[[osKickAvatar]]
*[[osCauseDamage]]
*[[osCauseHealing]]
*[[osGetHealth]]
{{multicol-break}}
*[[osSetSpeed]]
*[[osInviteToGroup]]
*[[osEjectFromGroup]]
*[[osForceAttachToAvatar]]
*[[osForceAttachToAvatarFromInventory]]
*[[osForceAttachToOtherAvatarFromInventory]]
*[[osForceDetachFromAvatar]]
*[[osForceOtherSit]]
*[[osGetNumberOfAttachments]]
*[[osDropAttachment]]
*[[osDropAttachmentAt]]
*[[osForceDropAttachment]]
*[[osForceDropAttachmentAt]]
{{multicol-end}}

=== NPCs ===
{{multicol}}
*[[osNpcCreate]]
*[[osNpcGetPos]]
*[[osNpcGetRot]]
*[[osNpcGetOwner]]
*[[osNpcLoadAppearance]]
*[[osNpcMoveTo]]
*[[osNpcMoveToTarget]]
*[[osNpcRemove]]
*[[osNpcSaveAppearance]]
*[[osNpcSay]]
*[[osNpcSay (with channel)]]
{{multicol-break}}
*[[osNpcSetRot]]
*[[osNpcShout]]
*[[osNpcSit]]
*[[osNpcStand]]
*[[osNpcStopMoveToTarget]]
*[[osIsNpc]]
*[[osNpcPlayAnimation]]
*[[osNpcStopAnimation]]
*[[osNpcTouch]]
*[[osNpcWhisper]]
{{multicol-end}}

=== Prim Manipulations ===
*[[osGetPrimitiveParams]]
*[[osGetLinkPrimitiveParams]]
*[[osSetPrimitiveParams]]
*[[osSetProjectionParams]]
*[[osForceCreateLink]]
*[[osForceBreakLink]]
*[[osForceBreakAllLinks]]
*[[osSetSpeed]]
*[[osMessageObject]]
*[[osGetInventoryDesc]]
*[[osGetRezzingObject]]
*[[osIsUUID]]
*[[osListenRegex]]
*[[osMessageAttachments]]

=== Prim Drawings ===
{{multicol}}
*[[osMovePen]]
*[[osDrawLine]]
*[[osDrawText]]
*[[osDrawEllipse]]
*[[osDrawRectangle]]
*[[osDrawFilledRectangle]]
*[[osDrawPolygon]]
*[[osDrawFilledPolygon]]
*[[osDrawImage]]
{{multicol-break}}
*[[osGetDrawStringSize]]
*[[osSetFontName]]
*[[osSetFontSize]]
*[[osSetPenSize]]
*[[osSetPenColor]]
*[[osSetPenCap]]
{{multicol-end}}

=== Dynamic Textures ===
*[[osSetDynamicTextureData]]
*[[osSetDynamicTextureDataBlend]]
*[[osSetDynamicTextureDataBlendFace]]
*[[osSetDynamicTextureURL]]
*[[osSetDynamicTextureURLBlend]]
*[[osSetDynamicTextureURLBlendFace]]

=== Notecards ===
*[[osMakeNotecard]]
*[[osGetNotecard]]
*[[osGetNotecardLine]]
*[[osGetNumberOfNotecardLines]]

=== Parcels ===
*[[osParcelJoin]]
*[[osParcelSubdivide]]
*[[osSetParcelDetails]]

=== Terrains ===
*[[osGetTerrainHeight]]
*[[osSetTerrainHeight]]
*[[osTerrainFlush]]
*[[osSetTerrainTexture]]
*[[osSetTerrainTextureHeight]]

=== WindLights ===
{{multicol}}
*[[osSetRegionWaterHeight]]
*[[osSetRegionSunSettings]]
*[[osSetEstateSunSettings]]
*[[osGetCurrentSunHour]]
*[[osGetSunParam]]
*[[osSetSunParam]]
{{multicol-break}}
*[[osWindActiveModelPluginName]]
*[[osGetWindParam]]
*[[osSetWindParam]]
{{multicol-end}}

=== Grid Information ===
{{multicol}}
*[[osGetGridName]]
*[[osGetGridNick]]
*[[osGetGridLoginURI]]
*[[osGetGridHomeURI]]
*[[osGetGridGatekeeperURI]]
*[[osGetGridCustom]]
*[[osGetScriptEngineName]]
*[[osGetSimulatorVersion]]
*[[osGetSimulatorMemory]]
{{multicol-break}}
*[[osGetMapTexture]]
*[[osGetRegionMapTexture]]
*[[osGetRegionSize]]
*[[osGetRegionStats]]
*[[osLoadedCreationDate]]
*[[osLoadedCreationTime]]
*[[osLoadedCreationID]]
*[[osGetPhysicsEngineType]]
{{multicol-end}}

=== Administration ===
*[[osRegionNotice]]
*[[osRegionRestart]]
*[[osConsoleCommand]]
*[[osSetParcelMediaURL]]
*[[osSetPrimFloatOnWater]]
*[[osSetParcelSIPAddress]]

=== Script Permissions (Pending Peer Review)===
*[[osGrantScriptPermissions]]
*[[osRevokeScriptPermissions]]

=== Misc ===
{{multicol}}
*[[osSetStateEvents]]
*[[osList2Double]]
*[[osKey2Name]]
*[[osFormatString]]
*[[osMatchString]]
*[[osUnixTimeToTimestamp]]
*[[osParseJSON]]
{{multicol-break}}
*[[osParseJSONNew]]
*[[osMax]]
*[[osMin]]
*[[osRegexIsMatch]]
*[[osReplaceString]]
*[[osSetContentType]]
{{multicol-end}}

=== Deprecated ===
*[[osParcelSetDetails|<strike>osParcelSetDetails</strike>]] - Use [[osSetParcelDetails]]
*[[osSetPenColour|<strike>osSetPenColour</strike>]] - Use [[osSetPenColor]]
*[[osSunGetParam|<strike>osSunGetParam</strike>]] - Use [[osGetSunParam]]
*[[osSunSetParam|<strike>osSunSetParam</strike>]] - Use [[osSetSunParam]]
*[[osTerrainGetHeight|<strike>osTerrainGetHeight</strike>]] - Use [[osGetTerrainHeight]]
*[[osTerrainSetHeight|<strike>osTerrainSetHeight</strike>]] - Use [[osSetTerrainHeight]]

== See Also ==

*[[LSL Status|LSL/OSSL Status Page]]
*OSSL
**[[OSSL_Implemented|OSSL Implemented Functions]]
**[[OSSL Constants|OSSL Constants]]
**[[OSSL Status/Types|OSSL Types Status Page]]
**[[OSSL Status/Events|OSSL Events Status Page]]

**[[Dynamic_textures|OSSL osDynamicTextures Functions Index Page]]
**[[OSSL TextureDrawing|OSSL TextureDrawing Extended Information]]
**[[OSSLNPC|OSSL functions for working with NPCs]]

**[[OSSL Proposals|OSSL Proposed Functions]]
**[[OSSL Enabling Functions]]
**[[OSSL Standards|OSSL Standards]]

* LS
** [[LightShare#LightShare Scripting|LightShare Functions]]

* MOD
** [[OSSL Script Library/ModSendCommand|modSendCommand()]]
** [[OSSL Script Library/ModInvoke|Custom functions using modInvoke()]]

* NPC
** [[Appearance_Formats|Appearance Notecard Format]]

[[Category:OSSL]]

Category:OSSL Functions

2015-02-27T17:22:26Z

BlueWall: /* Current OSSL Functions Implemented */

== Current OSSL Functions Implemented ==

Updated OSSL Functions as of OpenSim DEV 0.7.4 r/21068 17th November, 2012
<br /><br />
'''!''' 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.

Special Note: Some Functions as shown use '''"double"''' as a Value instead of '''"float" '''these vary for purposes of accuracy as shown Below.

(Float is short for "floating point", and just means a number with a point something on the end.)

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 )

Note that some function takes doubles as arguments but may be internally down-casted to floats.

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.

=== Avatars ===
{{multicol}}
*[[osGetAgentIP]]
*[[osGetAgents]]
*[[osGetAvatarList]]
*[[osAvatarName2Key]]
*[[osAvatarPlayAnimation]]
*[[osAvatarStopAnimation]]
*[[osAgentSaveAppearance]]
*[[osOwnerSaveAppearance]]
*[[osTeleportAgent]]
*[[osTeleportOwner]]
*[[osKickAvatar]]
*[[osCauseDamage]]
*[[osCauseHealing]]
*[[osGetHealth]]
{{multicol-break}}
*[[osSetSpeed]]
*[[osInviteToGroup]]
*[[osEjectFromGroup]]
*[[osForceAttachToAvatar]]
*[[osForceAttachToAvatarFromInventory]]
*[[osForceAttachToOtherAvatarFromInventory]]
*[[osForceDetachFromAvatar]]
*[[osForceOtherSit]]
*[[osGetNumberOfAttachments]]
*[[osDropAttachment]]
*[[osDropAttachmentAt]]
*[[osForceDropAttachment]]
*[[osForceDropAttachmentAt]]
{{multicol-end}}

=== NPCs ===
{{multicol}}
*[[osNpcCreate]]
*[[osNpcGetPos]]
*[[osNpcGetRot]]
*[[osNpcGetOwner]]
*[[osNpcLoadAppearance]]
*[[osNpcMoveTo]]
*[[osNpcMoveToTarget]]
*[[osNpcRemove]]
*[[osNpcSaveAppearance]]
*[[osNpcSay]]
*[[osNpcSay (with channel)]]
{{multicol-break}}
*[[osNpcSetRot]]
*[[osNpcShout]]
*[[osNpcSit]]
*[[osNpcStand]]
*[[osNpcStopMoveToTarget]]
*[[osIsNpc]]
*[[osNpcPlayAnimation]]
*[[osNpcStopAnimation]]
*[[osNpcTouch]]
*[[osNpcWhisper]]
{{multicol-end}}

=== Prim Manipulations ===
*[[osGetPrimitiveParams]]
*[[osGetLinkPrimitiveParams]]
*[[osSetPrimitiveParams]]
*[[osSetProjectionParams]]
*[[osForceCreateLink]]
*[[osForceBreakLink]]
*[[osForceBreakAllLinks]]
*[[osSetSpeed]]
*[[osMessageObject]]
*[[osGetInventoryDesc]]
*[[osGetRezzingObject]]
*[[osIsUUID]]
*[[osListenRegex]]
*[[osMessageAttachments]]

=== Prim Drawings ===
{{multicol}}
*[[osMovePen]]
*[[osDrawLine]]
*[[osDrawText]]
*[[osDrawEllipse]]
*[[osDrawRectangle]]
*[[osDrawFilledRectangle]]
*[[osDrawPolygon]]
*[[osDrawFilledPolygon]]
*[[osDrawImage]]
{{multicol-break}}
*[[osGetDrawStringSize]]
*[[osSetFontName]]
*[[osSetFontSize]]
*[[osSetPenSize]]
*[[osSetPenColor]]
*[[osSetPenCap]]
{{multicol-end}}

=== Dynamic Textures ===
*[[osSetDynamicTextureData]]
*[[osSetDynamicTextureDataBlend]]
*[[osSetDynamicTextureDataBlendFace]]
*[[osSetDynamicTextureURL]]
*[[osSetDynamicTextureURLBlend]]
*[[osSetDynamicTextureURLBlendFace]]

=== Notecards ===
*[[osMakeNotecard]]
*[[osGetNotecard]]
*[[osGetNotecardLine]]
*[[osGetNumberOfNotecardLines]]

=== Parcels ===
*[[osParcelJoin]]
*[[osParcelSubdivide]]
*[[osSetParcelDetails]]

=== Terrains ===
*[[osGetTerrainHeight]]
*[[osSetTerrainHeight]]
*[[osTerrainFlush]]
*[[osSetTerrainTexture]]
*[[osSetTerrainTextureHeight]]

=== WindLights ===
{{multicol}}
*[[osSetRegionWaterHeight]]
*[[osSetRegionSunSettings]]
*[[osSetEstateSunSettings]]
*[[osGetCurrentSunHour]]
*[[osGetSunParam]]
*[[osSetSunParam]]
{{multicol-break}}
*[[osWindActiveModelPluginName]]
*[[osGetWindParam]]
*[[osSetWindParam]]
{{multicol-end}}

=== Grid Information ===
{{multicol}}
*[[osGetGridName]]
*[[osGetGridNick]]
*[[osGetGridLoginURI]]
*[[osGetGridHomeURI]]
*[[osGetGridGatekeeperURI]]
*[[osGetGridCustom]]
*[[osGetScriptEngineName]]
*[[osGetSimulatorVersion]]
*[[osGetSimulatorMemory]]
{{multicol-break}}
*[[osGetMapTexture]]
*[[osGetRegionMapTexture]]
*[[osGetRegionSize]]
*[[osGetRegionStats]]
*[[osLoadedCreationDate]]
*[[osLoadedCreationTime]]
*[[osLoadedCreationID]]
*[[osGetPhysicsEngineType]]
{{multicol-end}}

=== Administration ===
*[[osRegionNotice]]
*[[osRegionRestart]]
*[[osConsoleCommand]]
*[[osSetParcelMediaURL]]
*[[osSetPrimFloatOnWater]]
*[[osSetParcelSIPAddress]]

=== Script Permissions ===
*[[osGrantScriptPermissions]]
*[[osRevokeScriptPermissions]]

=== Misc ===
{{multicol}}
*[[osSetStateEvents]]
*[[osList2Double]]
*[[osKey2Name]]
*[[osFormatString]]
*[[osMatchString]]
*[[osUnixTimeToTimestamp]]
*[[osParseJSON]]
{{multicol-break}}
*[[osParseJSONNew]]
*[[osMax]]
*[[osMin]]
*[[osRegexIsMatch]]
*[[osReplaceString]]
*[[osSetContentType]]
{{multicol-end}}

=== Deprecated ===
*[[osParcelSetDetails|<strike>osParcelSetDetails</strike>]] - Use [[osSetParcelDetails]]
*[[osSetPenColour|<strike>osSetPenColour</strike>]] - Use [[osSetPenColor]]
*[[osSunGetParam|<strike>osSunGetParam</strike>]] - Use [[osGetSunParam]]
*[[osSunSetParam|<strike>osSunSetParam</strike>]] - Use [[osSetSunParam]]
*[[osTerrainGetHeight|<strike>osTerrainGetHeight</strike>]] - Use [[osGetTerrainHeight]]
*[[osTerrainSetHeight|<strike>osTerrainSetHeight</strike>]] - Use [[osSetTerrainHeight]]

== See Also ==

*[[LSL Status|LSL/OSSL Status Page]]
*OSSL
**[[OSSL_Implemented|OSSL Implemented Functions]]
**[[OSSL Constants|OSSL Constants]]
**[[OSSL Status/Types|OSSL Types Status Page]]
**[[OSSL Status/Events|OSSL Events Status Page]]

**[[Dynamic_textures|OSSL osDynamicTextures Functions Index Page]]
**[[OSSL TextureDrawing|OSSL TextureDrawing Extended Information]]
**[[OSSLNPC|OSSL functions for working with NPCs]]

**[[OSSL Proposals|OSSL Proposed Functions]]
**[[OSSL Enabling Functions]]
**[[OSSL Standards|OSSL Standards]]

* LS
** [[LightShare#LightShare Scripting|LightShare Functions]]

* MOD
** [[OSSL Script Library/ModSendCommand|modSendCommand()]]
** [[OSSL Script Library/ModInvoke|Custom functions using modInvoke()]]

* NPC
** [[Appearance_Formats|Appearance Notecard Format]]

[[Category:OSSL]]

OsRevokeScriptPermissions

2015-02-27T17:22:12Z

BlueWall: Created page with "{{osslfunc |threat_level=Severe |function_syntax=void osRevokeScriptPermissions(key revoked_key, string function) |ossl_example=<source lang="lsl"> list functions = ["osNpcCre..."

{{osslfunc
|threat_level=Severe
|function_syntax=void osRevokeScriptPermissions(key revoked_key, string function)
|ossl_example=<source lang="lsl">
list functions = ["osNpcCreate", "osNpcGetPos", "osNpcLoadAppearance", "osNpcGetRot", "osNpcMoveTo",
"osNpcRemove", "osNpcSaveAppearance", "osNpcSay", "osNpcSetRot","osNpcSit", "osNpcStand",
"osNpcPlayAnimation", "osNpcStopAnimation","osNpcMoveToTarget", "osNpcStopMoveToTarget",
"osOwnerSaveAppearance", "osAgentSaveAppearance"];

default
{
state_entry()
{
llSetColor(<1,0,0>,ALL_SIDES);
}

touch_start(integer det)
{
llSay(0, "Enable");

osGrantScriptPermissions(llGetOwner(), functions);
state enabled;
}
}

state enabled
{
state_entry()
{
llSetColor(<0,1,0>,ALL_SIDES);
llSay(0, "ossl functions enabled");
}

touch_start(integer det)
{
osRevokeScriptPermissions(llGetOwner(), functions);
state default;
}
}
</source>
This example will allow the owner of this object to create and manipulate NPCs. To allow other possibilities, change the llGetOwner() to any key for another avatar or group. The osRevokeScriptPermissions uses the same syntax to remove previuosly granted permissions.
|description=Dynamically allow/disallow ossl execution to owner/creator/group by function name.
|
}}

OsGrantScriptPermissions

2015-02-27T17:15:36Z

BlueWall: Created page with "{{osslfunc |threat_level=Severe |function_syntax=void osGrantScriptPermissions(key allowed_key, string function) |ossl_example=<source lang="lsl"> list functions = ["osNpcCrea..."

{{osslfunc
|threat_level=Severe
|function_syntax=void osGrantScriptPermissions(key allowed_key, string function)
|ossl_example=<source lang="lsl">
list functions = ["osNpcCreate", "osNpcGetPos", "osNpcLoadAppearance", "osNpcGetRot", "osNpcMoveTo",
"osNpcRemove", "osNpcSaveAppearance", "osNpcSay", "osNpcSetRot","osNpcSit", "osNpcStand",
"osNpcPlayAnimation", "osNpcStopAnimation","osNpcMoveToTarget", "osNpcStopMoveToTarget",
"osOwnerSaveAppearance", "osAgentSaveAppearance"];

default
{
state_entry()
{
llSetColor(<1,0,0>,ALL_SIDES);
}

touch_start(integer det)
{
llSay(0, "Enable");

osGrantScriptPermissions(llGetOwner(), functions);
state enabled;
}
}

state enabled
{
state_entry()
{
llSetColor(<0,1,0>,ALL_SIDES);
llSay(0, "ossl functions enabled");
}

touch_start(integer det)
{
osRevokeScriptPermissions(llGetOwner(), functions);
state default;
}
}
</source>
This example will allow the owner of this object to create and manipulate NPCs. To allow other possibilities, change the llGetOwner() to any key for another avatar or group.
|description=Dynamically allow ossl execution to owner/creator/group by function name.
|
}}

Configuring Simulator Parameters

2015-01-31T16:38:42Z

BlueWall:

{{Quicklinks}}

= Structure =

'''Please note that the cascading configuration file system described below does not apply to Robust instances at this time.'''

OpenSimulator has a fairly complicated configuration structure based on Windows style INI files. This is to accomodate its many different uses and possible architectures.

Configuration files can include other configuration files. For instance, a standard standalone configuration will read the following INI files (you can see this order early on in the log and on the console).

OpenSimDefaults.ini (OpenSimulator 0.7.1 and onwards)
OpenSim.ini
config-include/Standalone.ini
config-include/StandaloneCommon.ini
config-include/CenomeCache.ini (not found on a default setup)
config-include/storage/SQLiteStandalone.ini

OpenSimDefaults.ini (on OpenSimulator 0.7.1 and later) and OpenSim.ini are always checked for on startup. However, the other INI files are loaded as a result of include directives within the preceding INI files.

For instance, at the bottom of the OpenSim.ini file in the [Architecture] section, there are a number of possible architectural includes. For example, a default OpenSimulator 0.7.1 standalone setup will have

[Architecture]
Include-Architecture = "config-include/Standalone.ini"
; Include-Architecture = "config-include/StandaloneHypergrid.ini"
; Include-Architecture = "config-include/Grid.ini"
; Include-Architecture = "config-include/GridHypergrid.ini"
; Include-Architecture = "config-include/SimianGrid.ini"
; Include-Architecture = "config-include/HyperSimianGrid.ini"

Lines that start with at least one semicolon (;) are commented out and are not active in the configuration. In this case, when OpenSimulator reads OpenSim.ini it will then go on to read config-include/Standalone.ini, which in turn includes config-include/StandaloneCommon.ini and so on.

If a config file isn't found then it is ignored and it's non-existence is logged.

The OpenSim.ini and OpenSimDefaults.ini files in bin/ concern simulator parameters (chat distance, physics, etc.). The parameters in config-include control the location and parameters of data services (e.g. region database, asset service, inventory service).

= Changing Simulator Settings =

A configuration file consists of a number of sections, each starting with the name of that section in brackets ([]). For instance, in OpenSim.ini.example you have (ignore the descriptive text)

[Startup]
; save_crashes = false
; crash_dir = "crashes"
...

[SMTP]
; enabled = false
...

[Chat]
; whisper_distance = 10

The config parameters follow each section. Each has the structure <parameter> = <value> (e.g. whisper_distance = 10).

In OpenSim.ini.example, if a parameter is commented out with a preceding semicolon (;), then the value in OpenSimDefaults.ini is used instead (in OpenSimulator 0.7.1 and later) or a default value within OpenSimulator itself.

To change a parameter, one would uncomment it and edit the value. For instance, if I wanted whisper distance to be 50 meters in my sim, I would change OpenSim.ini so that it had.

[Chat]
whisper_distance = 50

When the sim was next started up, the whisper distance would be 50m, overriding any value in OpenSimDefaults.ini if it exists.

In OpenSimulator 0.7.1 and later, we recommend that parameters are changed in OpenSim.ini and not in OpenSimDefaults.ini. This is because various parameters are added or can change name between releases. Common parameters to change are already in OpenSim.ini.example - OpenSimDefaults.ini contains both defaults for these parameters and more obscure ones. If you want override a parameter that is in OpenSimDefaults.ini but not OpenSim.ini.example then we recommend that you copy the relevant section to OpenSim.ini and change it there.

= Aggregation and Overriding =

As we saw above, when multiple config files have the same section, the settings are aggregated. If a later setting has the same name as an earlier setting, then the later setting overrides the earlier setting.

You cannot have multiple sections with the same name (e.g. [DatabaseService]) in the same file (e.g. bin/config-include/GridCommon.ini). The second section will completely replace the first. To merge sections with the same name they must be situated in different .ini files.

= Getting information about parameters =

On the simulator's console command line, you can get information about what parameters it's actually using from the all the .ini files with the "config show" command. This is handy if you want to check that the simulator has loaded the parameters that you want. The "config save <path>" command will save this aggregated config.

= Using Key Expansion to simplify configuration =

We use the same information in many places throughout the files that configure our servers. To help simplify the configuration process, we leverage "Key Expansion". With Key Expansion we are able to define these values in one place to be used anywhere in the set of configuration files. The configuration system uses the common syntax for parameter expansion: ${VARIABLE}. But, our configuration files have many sections, so our syntax adds the ability to address keys within the various sections of the set of configuration files using the pipe "|" to separate the two. Then, our syntax becomes: ${SECTION|KEY}. In the set of example configuration files distributed with OpenSimulator, we are using this feature to ease the definition of ports and urls in the file set, as these keys are used in many places. We set them in a newly added section ...

<source lang="ini">
[Const]

BaseURL = http://127.0.0.1
PublicPort = 8002
PrivatePort = 8003
</source>

Then we are able to use them in the many places they are needed by using our Key Expansion Syntax instead of the Key = Value seen elsewhere...

<source lang="ini">
[Startup]

HomeURI = ${Const|BaseURL}:${Const|PublicPort}
</source>

And when OpenSimulator starts and reads the set of configuration files, the end-result will be ...

<source lang="ini">
[Startup]

HomeURL = http://127.0.0.1:8002
</source>

And while it may not be quite so useful in our case, we may use the syntax to use keys defined in the same sections by omitting the section and pipe - ${KEY}.

= Using shell environment variables in OpenSimulator configuration =

We will need to use two new things in our configurations: a section [Environment] to tell us what variables we need to look at in the shell and we will need to use the Nini key expansion. Nini, can have keys that look like ${SECTION|VARIABLE} and can expand those to the variables we assign.

In your shell you will export your values and check the ones you want to use that are predefined by your system ...

<source lang="bash">
export RT_ZONE=Zone_00
</source>

<source lang="bash">
# You can see your HOSTNAME (It will be set by the system)...
echo $HOSTNAME
OSERV_00
</source>

In the ini you will include an [Environment] section...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSimulator on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/${Environment|RT_ZONE}/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "${Environment|HOSTNAME}:${Environment|RT_ZONE} "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=${Environment|RT_ZONE};User ID=username;Password=userpass;" ; Here too
</source>

When OpenSimulator picks up the variables in your shell and processes all the configurations, the variable keys will be filled in with the variables picked up from the shell ...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSimulator on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/Zone_00/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "OSERV_00:Zone_09 "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=Zone_00;User ID=username;Password=userpass;" ; Here too
</source>

UXSimStatus/fr

2015-01-02T01:22:42Z

BlueWall:

{{Quicklinks}}

Depuis OpenSimulator svn 9529 les statistiques étendues retournent un appel jsonp pour autoriser les outils javascript populaires à utiliser les données retournées pour créer une application de monitoring AJAX dans le navigateur. Ceci est un avantage car une fois que la page est chargée le navigateur va inter agir directement avec la région en éliminant le trafic par le site web (en sondant la région et nourissant le navigateur). Elles permettent aussi la création d'outils permettant de créer des applications dans d'autres pages.

Pour activer vos reports de données, définissez ceci dans votre OpenSim.ini...

; Simulator Stats URI
; Enable JSON simulator data by setting a URI name (case sensitive)
Stats_URI = "jsonSimStats"

...l'URI peut être ce que vous voulez et est sensible à la casse. Vous pouvez questionner directement l'URI pour retourner une chaîne JSON à utiliser dans php, python, java, etc ou bien vous pouvez utiliser un des outils populaires javascript afin qu'OpenSimulator génère un callback pour jsonp. La sérialisation JSON transporte les données suivantes...

{"AssetsInCache":5.0,"TimeAfterCacheMiss":0.0,"BlockedMissingTextureRequests":0.0,"AssetServiceRequestFailures":0.0,
"abnormalClientThreadTerminations":0.0,"InventoryServiceRetrievalFailures":0.0,"Dilatn":0.967380821704865,"SimFPS":55.0,
"PhyFPS":47.1628913879395,"AgntUp":0.0,"RootAg":0.0,"ChldAg":0.0,"Prims":0.0,"AtvPrm":0.0,"AtvScr":0.0,"ScrLPS":0.0,
"PktsIn":0.0,"PktOut":0.0,"PendDl":0.0,"PendUl":0.0,"UnackB":0.0,"TotlFt":0.0,"NetFt":0.0,"PhysFt":0.0,"OthrFt":0.0,
"AgntFt":0.0,"ImgsFt":0.0,"Memory":"8","Uptime":"05:12:19.0365590","Version":"OpenSimulator Server 0.6.4.9533 "}

<source lang="html4strict">

<!DOCTYPE HTML>
<html>
<head>
<title>JSON Test</title>
<script src="https://code.jquery.com/jquery-2.1.3.min.js"></script>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript" language="JavaScript">

SimFPS = 0;
PhyFPS = 0;
Memory = 0;
RootAg = 0;
ChldAg = 0;
Uptime = "";
Version = "";

setInterval(function(){
$.getJSON(
"http://ascent.bluewallgroup.com:9100/jsonSimStats/?callback=?",
function(data){
SimFPS = Math.round(data.SimFPS);
PhyFPS = Math.round(data.PhyFPS);
Memory = Math.round(data.Memory);
ChldAg = data.ChldAg;
RootAg = data.RootAg;
Uptime = data.Uptime;
Version = data.Version;
drawChart();
setTags();
})}, 3000
);

google.load("visualization", "1", {packages:["gauge"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var cdata = new google.visualization.DataTable();
cdata.addColumn('string', 'Label');
cdata.addColumn('number', 'Value');
cdata.addRows(3);
cdata.setValue(0, 0, 'SimFPS');
cdata.setValue(0, 1, SimFPS);
cdata.setValue(1, 0, 'PhyFPS');
cdata.setValue(1, 1, PhyFPS);
cdata.setValue(2, 0, 'Memory');
cdata.setValue(2, 1, Memory);

var chart = new
google.visualization.Gauge(document.getElementById('chart_div'));
var options = {width: 400, height: 120, redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90, minorTicks: 5};
chart.draw(cdata, options);
}

$(function() {
timer.start(100);
});

function setTags() {
$("#par-uptime").text("Uptime: " + Uptime);
$("#par-ragent").text("Root Agent: " + RootAg);
$("#par-version").text("Version: " + Version);
$("#par-cagent").text("Child Agent: " + ChldAg);
}
</script>

</head>
<body>
= BlueWall Development Region =
<table>
<tr><td>
<div id="par-version">version</div>
</td><td>
<div id="par-ragent">root agent</div>
</td></tr><tr><td>
<div id="par-uptime">uptime</div>
</td><td>
<div id="par-cagent">child agent</div>
</td></tr>
</table>
<div id="chart_div"></div>
</body>
</html>

</source>

== JSON Grid Simstats ==

Exemple python pour obtenir les données de région depuis un service de grille - devrait fonctionner mais cette version n'a pas été testée -
*reference material*

<source lang="python">

import hashlib
import urllib2

''' la valeur montrée est un exemple, récupérez ceci depuis votre base de donnée de la grille à chaque fois - regions.regionSecret '''
regionsecret = 'fe21314b-6267-44f7-aa1e-6047e1c3f94a'

''' Ma region host '''
hostName = myregion.host.net

''' Ma region port '''
hostPort = 9000

''' crée un SHA1 en majuscules depuis le regionSecret '''
resourceName = str(hashlib.sha1(regionsecret).hexdigest()).upper()

regionuri = hostName + ":" + hostPort + "/" + resourceName + "/"

''' les données incluent TimeZoneName , TimeZoneOffs, UxTime, Memory, Version et OSStatsURI '''
regiondata = simplejson.load(urllib2.urlopen(regionuri))

''' OSStatsURI est l'uri de requete de l'instance OpenSimulator. Retourne les même données avec l'uri fournie par l'utilisateur '''
simuri = regiondata['OSStatsURI']

simdata = simplejson.load(urllib2.urlopen(simuri))

</source>

UXSimStatus

2015-01-02T01:20:53Z

BlueWall:

{{Quicklinks}}

As of OpenSimulator svn 9529 the xtended stats reporting will return a jsonp
callback to allow popular javascript toolkits to use the returned data to
create ajax monitoring applications in the browser. This is an advantage
because after the page is loaded, the browser will interact directly with
the region, eliminating traffic through the website (polling the region and
servicing the browser). It also allows the creation of mashups to create
mini-monitor apps in other pages.

To enable your stats reporting, set the following in your OpenSim.ini...

; Simulator Stats URI
; Enable JSON simulator data by setting a URI name (case sensitive)
Stats_URI = "jsonSimStats"

...the URI can be anything you want, and is case sensitive. You can query
the URI directly to return a json string to use in php, python, java, etc.
or you may use one of the popular javascript toolkits to have OpenSimulator
generate a callback for jsonp. The json serialization carries the following
data...

{"AssetsInCache":5.0,"TimeAfterCacheMiss":0.0,"BlockedMissingTextureRequests":0.0,"AssetServiceRequestFailures":0.0,
"abnormalClientThreadTerminations":0.0,"InventoryServiceRetrievalFailures":0.0,"Dilatn":0.967380821704865,"SimFPS":55.0,
"PhyFPS":47.1628913879395,"AgntUp":0.0,"RootAg":0.0,"ChldAg":0.0,"Prims":0.0,"AtvPrm":0.0,"AtvScr":0.0,"ScrLPS":0.0,
"PktsIn":0.0,"PktOut":0.0,"PendDl":0.0,"PendUl":0.0,"UnackB":0.0,"TotlFt":0.0,"NetFt":0.0,"PhysFt":0.0,"OthrFt":0.0,
"AgntFt":0.0,"ImgsFt":0.0,"Memory":"8","Uptime":"05:12:19.0365590","Version":"OpenSimulator Server 0.6.4.9533 "}

<source lang="html4strict">

<!DOCTYPE HTML>
<html>
<head>
<title>JSON Test</title>
<script src="https://code.jquery.com/jquery-2.1.3.min.js"></script>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript" language="JavaScript">

SimFPS = 0;
PhyFPS = 0;
Memory = 0;
RootAg = 0;
ChldAg = 0;
Uptime = "";
Version = "";

setInterval(function(){
$.getJSON(
"http://ascent.bluewallgroup.com:9100/jsonSimStats/?callback=?",
function(data){
SimFPS = Math.round(data.SimFPS);
PhyFPS = Math.round(data.PhyFPS);
Memory = Math.round(data.Memory);
ChldAg = data.ChldAg;
RootAg = data.RootAg;
Uptime = data.Uptime;
Version = data.Version;
drawChart();
setTags();
})}, 3000
);

google.load("visualization", "1", {packages:["gauge"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var cdata = new google.visualization.DataTable();
cdata.addColumn('string', 'Label');
cdata.addColumn('number', 'Value');
cdata.addRows(3);
cdata.setValue(0, 0, 'SimFPS');
cdata.setValue(0, 1, SimFPS);
cdata.setValue(1, 0, 'PhyFPS');
cdata.setValue(1, 1, PhyFPS);
cdata.setValue(2, 0, 'Memory');
cdata.setValue(2, 1, Memory);

var chart = new
google.visualization.Gauge(document.getElementById('chart_div'));
var options = {width: 400, height: 120, redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90, minorTicks: 5};
chart.draw(cdata, options);
}

$(function() {
timer.start(100);
});

function setTags() {
$("#par-uptime").text("Uptime: " + Uptime);
$("#par-ragent").text("Root Agent: " + RootAg);
$("#par-version").text("Version: " + Version);
$("#par-cagent").text("Child Agent: " + ChldAg);
}
</script>

</head>
<body>
= BlueWall Development Region =
<table>
<tr><td>
<div id="par-version">version</div>
</td><td>
<div id="par-ragent">root agent</div>
</td></tr><tr><td>
<div id="par-uptime">uptime</div>
</td><td>
<div id="par-cagent">child agent</div>
</td></tr>
</table>
<div id="chart_div"></div>
</body>
</html>

</source>

[[SSL in OpenSim]]

== JSON Grid Simstats ==

Python example to gain the region data from a grid service
- should work but this version not tested -
*reference material*

<source lang="python">

import hashlib
import urllib2

''' value shown is an example, get this from your grid database each time - regions.regionSecret '''
regionsecret = 'fe21314b-6267-44f7-aa1e-6047e1c3f94a'

''' My region host '''
hostName = myregion.host.net

''' My region port '''
hostPort = 9000

''' create an *UPPERCASE* SHA1 hash from the regionSecret '''
resourceName = str(hashlib.sha1(regionsecret).hexdigest()).upper()

regionuri = hostName + ":" + hostPort + "/" + resourceName + "/"

''' data includes TimeZoneName , TimeZoneOffs, UxTime, Memory, Version and OSStatsURI '''
regiondata = simplejson.load(urllib2.urlopen(regionuri))

''' OSStatsURI is the uri to query the OpenSimulator instance. return same data as the user set uri '''
simuri = regiondata['OSStatsURI']

simdata = simplejson.load(urllib2.urlopen(simuri))

</source>

Test Page

2015-01-02T01:17:24Z

BlueWall: /* JSON User SimStats */

'''As of 2011-10-10 I copy/pasted this over to the linked [[UXSimStatus]] for further change/editing -- [[User:Justincc|Justincc]] 20:22, 10 October 2011 (UTC)'''

== JSON User SimStats ==

As of OpenSim svn 9529 the xtended stats reporting will return a jsonp
callback to allow popular javascript toolkits to use the returned data to
create ajax monitoring applications in the browser. This is an advantage
because after the page is loaded, the browser will interact directly with
the region, eliminating traffic through the website (polling the region and
servicing the browser). It also allows the creation of mashups to create
mini-monitor apps in other pages.

To enable your stats reporting, set the following in your OpenSim.ini...

; Simulator Stats URI
; Enable JSON simulator data by setting a URI name (case sensitive)
Stats_URI = "jsonSimStats"

...the URI can be anything you want, and is case sensitive. You can query
the URI directly to return a json string to use in php, python, java, etc.
or you may use one of the popular javascript toolkits to have OpenSim
generate a callback for jsonp. The json serialization carries the following
data...

{"AssetsInCache":5.0,"TimeAfterCacheMiss":0.0,"BlockedMissingTextureRequests":0.0,"AssetServiceRequestFailures":0.0,
"abnormalClientThreadTerminations":0.0,"InventoryServiceRetrievalFailures":0.0,"Dilatn":0.967380821704865,"SimFPS":55.0,
"PhyFPS":47.1628913879395,"AgntUp":0.0,"RootAg":0.0,"ChldAg":0.0,"Prims":0.0,"AtvPrm":0.0,"AtvScr":0.0,"ScrLPS":0.0,
"PktsIn":0.0,"PktOut":0.0,"PendDl":0.0,"PendUl":0.0,"UnackB":0.0,"TotlFt":0.0,"NetFt":0.0,"PhysFt":0.0,"OthrFt":0.0,
"AgntFt":0.0,"ImgsFt":0.0,"Memory":"8","Uptime":"05:12:19.0365590","Version":"OpenSimulator Server 0.6.4.9533 "}

<source lang="html4strict">

<!DOCTYPE HTML>
<html>
<head>
<title>JSON Test</title>
<script src="https://code.jquery.com/jquery-2.1.3.min.js"></script>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript" language="JavaScript">

SimFPS = 0;
PhyFPS = 0;
Memory = 0;
RootAg = 0;
ChldAg = 0;
Uptime = "";
Version = "";

setInterval(function(){
$.getJSON(
"http://ascent.bluewallgroup.com:9100/jsonSimStats/?callback=?",
function(data){
SimFPS = Math.round(data.SimFPS);
PhyFPS = Math.round(data.PhyFPS);
Memory = Math.round(data.Memory);
ChldAg = data.ChldAg;
RootAg = data.RootAg;
Uptime = data.Uptime;
Version = data.Version;
drawChart();
setTags();
})}, 3000
);

google.load("visualization", "1", {packages:["gauge"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var cdata = new google.visualization.DataTable();
cdata.addColumn('string', 'Label');
cdata.addColumn('number', 'Value');
cdata.addRows(3);
cdata.setValue(0, 0, 'SimFPS');
cdata.setValue(0, 1, SimFPS);
cdata.setValue(1, 0, 'PhyFPS');
cdata.setValue(1, 1, PhyFPS);
cdata.setValue(2, 0, 'Memory');
cdata.setValue(2, 1, Memory);

var chart = new
google.visualization.Gauge(document.getElementById('chart_div'));
var options = {width: 400, height: 120, redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90, minorTicks: 5};
chart.draw(cdata, options);
}

$(function() {
timer.start(100);
});

function setTags() {
$("#par-uptime").text("Uptime: " + Uptime);
$("#par-ragent").text("Root Agent: " + RootAg);
$("#par-version").text("Version: " + Version);
$("#par-cagent").text("Child Agent: " + ChldAg);
}
</script>

</head>
<body>
= BlueWall Development Region =
<table>
<tr><td>
<div id="par-version">version</div>
</td><td>
<div id="par-ragent">root agent</div>
</td></tr><tr><td>
<div id="par-uptime">uptime</div>
</td><td>
<div id="par-cagent">child agent</div>
</td></tr>
</table>
<div id="chart_div"></div>
</body>
</html>

</source>

[[SSL in OpenSim]]

== JSON Grid Simstats ==

Python example to gain the region data from a grid service
- should work but this version not tested -
*reference material*

<source lang="python">

import hashlib
import urllib2

''' value shown is an example, get this from your grid database each time - regions.regionSecret '''
regionsecret = 'fe21314b-6267-44f7-aa1e-6047e1c3f94a'

''' My region host '''
hostName = myregion.host.net

''' My region port '''
hostPort = 9000

''' create an *UPPERCASE* SHA1 hash from the regionSecret '''
resourceName = str(hashlib.sha1(regionsecret).hexdigest()).upper()

regionuri = hostName + ":" + hostPort + "/" + resourceName + "/"

''' data includes TimeZoneName , TimeZoneOffs, UxTime, Memory, Version and OSStatsURI '''
regiondata = simplejson.load(urllib2.urlopen(regionuri))

''' OSStatsURI is the uri to query the OpenSim instance. return same data as the user set uri '''
simuri = regiondata['OSStatsURI']

simdata = simplejson.load(urllib2.urlopen(simuri))

</source>

== Using shell environment variables in OpenSim configuration ==

We will need to use two new things in our configurations: a section [Environment] to tell us what variables we need to look at in the shell and we will need to use the Nini key expansion. Nini, can have keys that look like ${SECTION|VARIABLE} and can expand those to the variables we assign.

In your shell you will export your values and check the ones you want to use that are predefined by your system ...

<source lang="bash">
export RT_ZONE=Zone_00
</source>

<source lang="bash">
# You can see your HOSTNAME (It will be set by the system)...
echo $HOSTNAME
OSERV_00
</source>

In the ini you will include an [Environment] section...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSim on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/${Environment|RT_ZONE}/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "${Environment|HOSTNAME}:${Environment|RT_ZONE} "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=${Environment|RT_ZONE};User ID=username;Password=userpass;" ; Here too
</source>

When OpenSim picks up the variables in your shell and processes all the configurations, the variable keys will be filled in with the variables picked up from the shell ...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSim on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/Zone_00/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "OSERV_00:Zone_09 "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=Zone_00;User ID=username;Password=userpass;" ; Here too
</source>

This is a pretty good start. I think there will be a couple of places we might be able to use this to help us setup really flexible configuration systems for OpenSim.

Have Fun!

== TESTING ==

This is a test

UXSimStatus/fr

2014-12-30T23:28:41Z

BlueWall:

{{Quicklinks}}

Depuis OpenSimulator svn 9529 les statistiques étendues retournent un appel jsonp pour autoriser les outils javascript populaires à utiliser les données retournées pour créer une application de monitoring AJAX dans le navigateur. Ceci est un avantage car une fois que la page est chargée le navigateur va inter agir directement avec la région en éliminant le trafic par le site web (en sondant la région et nourissant le navigateur). Elles permettent aussi la création d'outils permettant de créer des applications dans d'autres pages.

Pour activer vos reports de données, définissez ceci dans votre OpenSim.ini...

; Simulator Stats URI
; Enable JSON simulator data by setting a URI name (case sensitive)
Stats_URI = "jsonSimStats"

...l'URI peut être ce que vous voulez et est sensible à la casse. Vous pouvez questionner directement l'URI pour retourner une chaîne JSON à utiliser dans php, python, java, etc ou bien vous pouvez utiliser un des outils populaires javascript afin qu'OpenSimulator génère un callback pour jsonp. La sérialisation JSON transporte les données suivantes...

{"AssetsInCache":5.0,"TimeAfterCacheMiss":0.0,"BlockedMissingTextureRequests":0.0,"AssetServiceRequestFailures":0.0,
"abnormalClientThreadTerminations":0.0,"InventoryServiceRetrievalFailures":0.0,"Dilatn":0.967380821704865,"SimFPS":55.0,
"PhyFPS":47.1628913879395,"AgntUp":0.0,"RootAg":0.0,"ChldAg":0.0,"Prims":0.0,"AtvPrm":0.0,"AtvScr":0.0,"ScrLPS":0.0,
"PktsIn":0.0,"PktOut":0.0,"PendDl":0.0,"PendUl":0.0,"UnackB":0.0,"TotlFt":0.0,"NetFt":0.0,"PhysFt":0.0,"OthrFt":0.0,
"AgntFt":0.0,"ImgsFt":0.0,"Memory":"8","Uptime":"05:12:19.0365590","Version":"OpenSimulator Server 0.6.4.9533 "}

<source lang="html4strict">
<!DOCTYPE HTML>
<html>
<head>
<title>JSON Test</title>
<script src="https://code.jquery.com/jquery-2.1.3.min.js"></script>
<script src="http://husa.github.io/timer.js/dist/timer.js"></script>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript" language="JavaScript">
SimFPS = 0;
PhyFPS = 0;
Memory = 0;
RootAg = 0;
ChldAg = 0;
Uptime = "";
Version = "";

var timer = new Timer({
tick : 1,
ontick : function (sec) {
$.getJSON(
"http://ascent.bluewallgroup.com:9100/jsonSimStats/?callback=?",
function(data){
SimFPS = Math.round(data.SimFPS);
PhyFPS = Math.round(data.PhyFPS);
Memory = Math.round(data.Memory);
ChldAg = data.ChldAg;
RootAg = data.RootAg;
Uptime = data.Uptime;
Version = data.Version;
drawChart();
setTags();
});
},
onstart : function() {
console.log('timer started');
},
onend : function() {
console.log("Timer stopped");
this.start(100);
}
});

google.load("visualization", "1", {packages:["gauge"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var cdata = new google.visualization.DataTable();
cdata.addColumn('string', 'Label');
cdata.addColumn('number', 'Value');
cdata.addRows(3);
cdata.setValue(0, 0, 'SimFPS');
cdata.setValue(0, 1, SimFPS);
cdata.setValue(1, 0, 'PhyFPS');
cdata.setValue(1, 1, PhyFPS);
cdata.setValue(2, 0, 'Memory');
cdata.setValue(2, 1, Memory);

var chart = new
google.visualization.Gauge(document.getElementById('chart_div'));
var options = {width: 400, height: 120, redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90, minorTicks: 5};
chart.draw(cdata, options);
}

$(function() {
timer.start(100);
});

function setTags() {
$("#par-uptime").text("Uptime: " + Uptime);
$("#par-ragent").text("Root Agent: " + RootAg);
$("#par-version").text("Version: " + Version);
$("#par-cagent").text("Child Agent: " + ChldAg);
}
</script>

</head>
<body>
= BlueWall Development Region =
<table>
<tr><td>
<div id="par-version">version</div>
</td><td>
<div id="par-ragent">root agent</div>
</td></tr><tr><td>
<div id="par-uptime">uptime</div>
</td><td>
<div id="par-cagent">child agent</div>
</td></tr>
</table>
<div id="chart_div"></div>
</body>
</html>
</source>

== JSON Grid Simstats ==

Exemple python pour obtenir les données de région depuis un service de grille - devrait fonctionner mais cette version n'a pas été testée -
*reference material*

<source lang="python">

import hashlib
import urllib2

''' la valeur montrée est un exemple, récupérez ceci depuis votre base de donnée de la grille à chaque fois - regions.regionSecret '''
regionsecret = 'fe21314b-6267-44f7-aa1e-6047e1c3f94a'

''' Ma region host '''
hostName = myregion.host.net

''' Ma region port '''
hostPort = 9000

''' crée un SHA1 en majuscules depuis le regionSecret '''
resourceName = str(hashlib.sha1(regionsecret).hexdigest()).upper()

regionuri = hostName + ":" + hostPort + "/" + resourceName + "/"

''' les données incluent TimeZoneName , TimeZoneOffs, UxTime, Memory, Version et OSStatsURI '''
regiondata = simplejson.load(urllib2.urlopen(regionuri))

''' OSStatsURI est l'uri de requete de l'instance OpenSimulator. Retourne les même données avec l'uri fournie par l'utilisateur '''
simuri = regiondata['OSStatsURI']

simdata = simplejson.load(urllib2.urlopen(simuri))

</source>

Test Page

2014-12-30T21:27:54Z

BlueWall: /* JSON User SimStats */

'''As of 2011-10-10 I copy/pasted this over to the linked [[UXSimStatus]] for further change/editing -- [[User:Justincc|Justincc]] 20:22, 10 October 2011 (UTC)'''

== JSON User SimStats ==

As of OpenSim svn 9529 the xtended stats reporting will return a jsonp
callback to allow popular javascript toolkits to use the returned data to
create ajax monitoring applications in the browser. This is an advantage
because after the page is loaded, the browser will interact directly with
the region, eliminating traffic through the website (polling the region and
servicing the browser). It also allows the creation of mashups to create
mini-monitor apps in other pages.

To enable your stats reporting, set the following in your OpenSim.ini...

; Simulator Stats URI
; Enable JSON simulator data by setting a URI name (case sensitive)
Stats_URI = "jsonSimStats"

...the URI can be anything you want, and is case sensitive. You can query
the URI directly to return a json string to use in php, python, java, etc.
or you may use one of the popular javascript toolkits to have OpenSim
generate a callback for jsonp. The json serialization carries the following
data...

{"AssetsInCache":5.0,"TimeAfterCacheMiss":0.0,"BlockedMissingTextureRequests":0.0,"AssetServiceRequestFailures":0.0,
"abnormalClientThreadTerminations":0.0,"InventoryServiceRetrievalFailures":0.0,"Dilatn":0.967380821704865,"SimFPS":55.0,
"PhyFPS":47.1628913879395,"AgntUp":0.0,"RootAg":0.0,"ChldAg":0.0,"Prims":0.0,"AtvPrm":0.0,"AtvScr":0.0,"ScrLPS":0.0,
"PktsIn":0.0,"PktOut":0.0,"PendDl":0.0,"PendUl":0.0,"UnackB":0.0,"TotlFt":0.0,"NetFt":0.0,"PhysFt":0.0,"OthrFt":0.0,
"AgntFt":0.0,"ImgsFt":0.0,"Memory":"8","Uptime":"05:12:19.0365590","Version":"OpenSimulator Server 0.6.4.9533 "}

<source lang="html4strict">
<!DOCTYPE HTML>
<html>
<head>
<title>JSON Test</title>
<script src="https://code.jquery.com/jquery-2.1.3.min.js"></script>
<script src="http://husa.github.io/timer.js/dist/timer.js"></script>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript" language="JavaScript">
SimFPS = 0;
PhyFPS = 0;
Memory = 0;
RootAg = 0;
ChldAg = 0;
Uptime = "";
Version = "";

var timer = new Timer({
tick : 1,
ontick : function (sec) {
$.getJSON(
"http://ascent.bluewallgroup.com:9100/jsonSimStats/?callback=?",
function(data){
SimFPS = Math.round(data.SimFPS);
PhyFPS = Math.round(data.PhyFPS);
Memory = Math.round(data.Memory);
ChldAg = data.ChldAg;
RootAg = data.RootAg;
Uptime = data.Uptime;
Version = data.Version;
drawChart();
setTags();
});
},
onstart : function() {
console.log('timer started');
},
onend : function() {
console.log("Timer stopped");
this.start(100);
}
});

google.load("visualization", "1", {packages:["gauge"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var cdata = new google.visualization.DataTable();
cdata.addColumn('string', 'Label');
cdata.addColumn('number', 'Value');
cdata.addRows(3);
cdata.setValue(0, 0, 'SimFPS');
cdata.setValue(0, 1, SimFPS);
cdata.setValue(1, 0, 'PhyFPS');
cdata.setValue(1, 1, PhyFPS);
cdata.setValue(2, 0, 'Memory');
cdata.setValue(2, 1, Memory);

var chart = new
google.visualization.Gauge(document.getElementById('chart_div'));
var options = {width: 400, height: 120, redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90, minorTicks: 5};
chart.draw(cdata, options);
}

$(function() {
timer.start(100);
});

function setTags() {
$("#par-uptime").text("Uptime: " + Uptime);
$("#par-ragent").text("Root Agent: " + RootAg);
$("#par-version").text("Version: " + Version);
$("#par-cagent").text("Child Agent: " + ChldAg);
}
</script>

</head>
<body>
= BlueWall Development Region =
<table>
<tr><td>
<div id="par-version">version</div>
</td><td>
<div id="par-ragent">root agent</div>
</td></tr><tr><td>
<div id="par-uptime">uptime</div>
</td><td>
<div id="par-cagent">child agent</div>
</td></tr>
</table>
<div id="chart_div"></div>
</body>
</html>

</source>

[[SSL in OpenSim]]

== JSON Grid Simstats ==

Python example to gain the region data from a grid service
- should work but this version not tested -
*reference material*

<source lang="python">

import hashlib
import urllib2

''' value shown is an example, get this from your grid database each time - regions.regionSecret '''
regionsecret = 'fe21314b-6267-44f7-aa1e-6047e1c3f94a'

''' My region host '''
hostName = myregion.host.net

''' My region port '''
hostPort = 9000

''' create an *UPPERCASE* SHA1 hash from the regionSecret '''
resourceName = str(hashlib.sha1(regionsecret).hexdigest()).upper()

regionuri = hostName + ":" + hostPort + "/" + resourceName + "/"

''' data includes TimeZoneName , TimeZoneOffs, UxTime, Memory, Version and OSStatsURI '''
regiondata = simplejson.load(urllib2.urlopen(regionuri))

''' OSStatsURI is the uri to query the OpenSim instance. return same data as the user set uri '''
simuri = regiondata['OSStatsURI']

simdata = simplejson.load(urllib2.urlopen(simuri))

</source>

== Using shell environment variables in OpenSim configuration ==

We will need to use two new things in our configurations: a section [Environment] to tell us what variables we need to look at in the shell and we will need to use the Nini key expansion. Nini, can have keys that look like ${SECTION|VARIABLE} and can expand those to the variables we assign.

In your shell you will export your values and check the ones you want to use that are predefined by your system ...

<source lang="bash">
export RT_ZONE=Zone_00
</source>

<source lang="bash">
# You can see your HOSTNAME (It will be set by the system)...
echo $HOSTNAME
OSERV_00
</source>

In the ini you will include an [Environment] section...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSim on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/${Environment|RT_ZONE}/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "${Environment|HOSTNAME}:${Environment|RT_ZONE} "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=${Environment|RT_ZONE};User ID=username;Password=userpass;" ; Here too
</source>

When OpenSim picks up the variables in your shell and processes all the configurations, the variable keys will be filled in with the variables picked up from the shell ...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSim on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/Zone_00/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "OSERV_00:Zone_09 "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=Zone_00;User ID=username;Password=userpass;" ; Here too
</source>

This is a pretty good start. I think there will be a couple of places we might be able to use this to help us setup really flexible configuration systems for OpenSim.

Have Fun!

== TESTING ==

This is a test

UXSimStatus

2014-12-25T22:53:51Z

BlueWall:

{{Quicklinks}}

As of OpenSimulator svn 9529 the xtended stats reporting will return a jsonp
callback to allow popular javascript toolkits to use the returned data to
create ajax monitoring applications in the browser. This is an advantage
because after the page is loaded, the browser will interact directly with
the region, eliminating traffic through the website (polling the region and
servicing the browser). It also allows the creation of mashups to create
mini-monitor apps in other pages.

To enable your stats reporting, set the following in your OpenSim.ini...

; Simulator Stats URI
; Enable JSON simulator data by setting a URI name (case sensitive)
Stats_URI = "jsonSimStats"

...the URI can be anything you want, and is case sensitive. You can query
the URI directly to return a json string to use in php, python, java, etc.
or you may use one of the popular javascript toolkits to have OpenSimulator
generate a callback for jsonp. The json serialization carries the following
data...

{"AssetsInCache":5.0,"TimeAfterCacheMiss":0.0,"BlockedMissingTextureRequests":0.0,"AssetServiceRequestFailures":0.0,
"abnormalClientThreadTerminations":0.0,"InventoryServiceRetrievalFailures":0.0,"Dilatn":0.967380821704865,"SimFPS":55.0,
"PhyFPS":47.1628913879395,"AgntUp":0.0,"RootAg":0.0,"ChldAg":0.0,"Prims":0.0,"AtvPrm":0.0,"AtvScr":0.0,"ScrLPS":0.0,
"PktsIn":0.0,"PktOut":0.0,"PendDl":0.0,"PendUl":0.0,"UnackB":0.0,"TotlFt":0.0,"NetFt":0.0,"PhysFt":0.0,"OthrFt":0.0,
"AgntFt":0.0,"ImgsFt":0.0,"Memory":"8","Uptime":"05:12:19.0365590","Version":"OpenSimulator Server 0.6.4.9533 "}

<source lang="html4strict">
<!DOCTYPE HTML>
<html>
<head>
<title>JSON Test</title>
<script src="https://code.jquery.com/jquery-2.1.3.min.js"></script>
<script src="http://husa.github.io/timer.js/dist/timer.js"></script>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript" language="JavaScript">
SimFPS = 0;
PhyFPS = 0;
Memory = 0;
RootAg = 0;
ChldAg = 0;
Uptime = "";
Version = "";

var timer = new Timer({
tick : 1,
ontick : function (sec) {
$.getJSON(
"http://ascent.bluewallgroup.com:9100/jsonSimStats/?callback=?",
function(data){
SimFPS = Math.round(data.SimFPS);
PhyFPS = Math.round(data.PhyFPS);
Memory = Math.round(data.Memory);
ChldAg = data.ChldAg;
RootAg = data.RootAg;
Uptime = data.Uptime;
Version = data.Version;
drawChart();
setTags();
});
},
onstart : function() {
console.log('timer started');
},
onend : function() {
console.log("Timer stopped");
this.start(100);
}
});

google.load("visualization", "1", {packages:["gauge"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var cdata = new google.visualization.DataTable();
cdata.addColumn('string', 'Label');
cdata.addColumn('number', 'Value');
cdata.addRows(3);
cdata.setValue(0, 0, 'SimFPS');
cdata.setValue(0, 1, SimFPS);
cdata.setValue(1, 0, 'PhyFPS');
cdata.setValue(1, 1, PhyFPS);
cdata.setValue(2, 0, 'Memory');
cdata.setValue(2, 1, Memory);

var chart = new
google.visualization.Gauge(document.getElementById('chart_div'));
var options = {width: 400, height: 120, redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90, minorTicks: 5};
chart.draw(cdata, options);
}

$(function() {
timer.start(100);
});

function setTags() {
$("#par-uptime").text("Uptime: " + Uptime);
$("#par-ragent").text("Root Agent: " + RootAg);
$("#par-version").text("Version: " + Version);
$("#par-cagent").text("Child Agent: " + ChldAg);
}
</script>

</head>
<body>
= BlueWall Development Region =
<table>
<tr><td>
<div id="par-version">version</div>
</td><td>
<div id="par-ragent">root agent</div>
</td></tr><tr><td>
<div id="par-uptime">uptime</div>
</td><td>
<div id="par-cagent">child agent</div>
</td></tr>
</table>
<div id="chart_div"></div>
</body>
</html>

</source>

[[SSL in OpenSim]]

== JSON Grid Simstats ==

Python example to gain the region data from a grid service
- should work but this version not tested -
*reference material*

<source lang="python">

import hashlib
import urllib2

''' value shown is an example, get this from your grid database each time - regions.regionSecret '''
regionsecret = 'fe21314b-6267-44f7-aa1e-6047e1c3f94a'

''' My region host '''
hostName = myregion.host.net

''' My region port '''
hostPort = 9000

''' create an *UPPERCASE* SHA1 hash from the regionSecret '''
resourceName = str(hashlib.sha1(regionsecret).hexdigest()).upper()

regionuri = hostName + ":" + hostPort + "/" + resourceName + "/"

''' data includes TimeZoneName , TimeZoneOffs, UxTime, Memory, Version and OSStatsURI '''
regiondata = simplejson.load(urllib2.urlopen(regionuri))

''' OSStatsURI is the uri to query the OpenSimulator instance. return same data as the user set uri '''
simuri = regiondata['OSStatsURI']

simdata = simplejson.load(urllib2.urlopen(simuri))

</source>

Configuration

2014-09-03T17:18:04Z

BlueWall: /* Running OpenSimulator 0.6.7 to 0.7.6.1 in 64 bit Windows */

{{Quicklinks}}
<br />
== OpenSimulator simulator configuration file ==
The region simulator configuration is managed using a file called OpenSim.ini. This file is used regardless of whether the sim is running in standalone or grid mode. This file references some additional configuration information from the config-include/ directory. Information about the various settings is contained in the OpenSim.ini file itself (or OpenSim.ini.example for reference).

Please note, that the name OpenSim.ini can be changed via [[OpenSim.exe Command Line Options|command line arguments]].

It is also possible to distribute the inifile settings over two files. This is useful if you want to run several OpenSimulator processes where most of your settings are identical except for a few. The master file is read first, then the inifile is read. Settings given in the inifile overrule settings given in the master file. The master file has the same format and the same keywords as the inifile, so the same documentation applies.

== Database ==

Opensim supports the following database-engines. Information about setting these up can be found in the OpenSim.ini.example file and the other various example files in bin/config-include. '''If you do not want to use the default SQLite configuration then you will need to setup your database before proceeding further'''. SQLite does not require further configuration. See [[Database Settings]] for the detailed settings.

* '''SQLite''' (default) - a lightweight database that comes bundled with OpenSimulator and can be used without requiring any extra configuration. It is mostly intended to get you up and running quickly, not for production use. It is significantly slower than MySQL. A few features here (such as attachment persistence) have not yet been fully implemented.

* '''MySQL''' (fully supported) - This is the recommended database for any use beyond experimentation or small standalone applications. The minimum MySQL version is 5.1.
::* '''Windows x64 systems:'''  There is currently an unresolved [http://opensimulator.org/mantis/bug_view_advanced_page.php?bug_id=5294 bug_id=5294] found when running OpenSimulator with MySQL 5.5 on Windows x64 systems.
::* '''Opensim 0.7.0.2:'''  Some users have reported problems with MySQL 5.1.55 and up with Opensim 0.7.0.2, see [http://opensim-users.2152040.n2.nabble.com/OpenSim-1-7-0-2-and-MySQL-Versions-td6155064.html this thread] for more information. The issue can be resolved by using an updated version of MySql.Data.dll OR installing an older version of MySQL such as [http://downloads.mysql.com/archives.php?p=mysql-5.1&v=5.1.52 MySQL 5.1.52] with Opensim version 0.7.0.2.  

* '''MSSQL''' (fairly supported) - persistence support for some recent OpenSimulator features may not yet be implemented though the vast majority of them are supported.

== Standalone vs. Grid ==
We recommend that you first get OpenSimulator running in standalone mode before you attempt to connect it to a grid or run your own grid. OpenSimulator will start up in standalone mode out-of-the-box on the binary distributions.

An OpenSimulator configuration consists of regions (run by region simulators) and backend data services (such as user, assets and inventory management).

A system running in '''standalone mode''' runs both the region simulator and all the data services in a single process when you run OpenSim.exe. In this mode you can run as many regions as you like but only on a single machine.

[[Image:Opensim-standalone.png|frame|center|OpenSimulator running in standalone mode. Both simulator and services run in the same process (OpenSim.exe).]]

In '''grid mode''', the data services are not part of the region server process. Instead, they are run in a separate executable called Robust.exe. A Robust shell can run all the services or they can be split amongst any number of Robust instances. This allows them to be run on entirely separate machines if necessary. In this mode, the OpenSim.exe acts solely as the region server, serving one or more regions that communicate with the separate data services. At this point you can run multiple OpenSim.exe region simulators on different machines.

[[Image:Opensim-grid-simple.png|frame|center|OpenSimulator running in grid mode. In this case, all the services are being run within a Robust.exe process. Multiple copies of OpenSim.exe (usually running on different machines) all use the same set of common services.]]

Running in grid mode is more complicated than running in standalone mode. It requires an understanding of UUID, X,Y location, server handshake passwords, estates and estate owners, and a couple of other settings. These require more care and patience to set up. We strongly recommend that you don't attempt this unless you are extremely patient and very technically proficient.

= Running OpenSimulator in Standalone mode =

Binary distributions of OpenSimulator are by default configured to run in standalone mode.

However, if you build OpenSimulator from the source distribution or from the git repository then you will need to:

# Change into the '''''bin''''' folder
# Copy the file '''''OpenSim.ini.example''''' to '''''OpenSim.ini'''''. This configures the 3D simulator itself.
# Change into the '''''bin/config-include''''' folder
# Copy the file '''''StandaloneCommon.ini.example''''' to '''''StandaloneCommon.ini'''''. This configures the in-process data services used by the standalone configuration.
# In the '''[Architecture]''' section of '''''OpenSim.ini''''', near the bottom of the file, uncomment the ''Standalone.ini'' line. To uncomment a line of code, remove the semi-colon (;) comment symbol preceding the line so that it says:

Include-Architecture = "config-include/Standalone.ini"

Running OpenSimulator is then a matter of launching OpenSim.exe. However, you need to have installed all dependencies before that. See [[Dependencies]] for details. After that, open a command prompt (for Windows users, Start menu > Run > cmd) and navigate to the Opensim /bin directory.

On a '''Windows 32-bit''' command prompt:
OpenSim.exe
Under '''Windows 64-bit''', ODE cannot yet be compiled for 64 bit mode, so if using the default ODE physics plugin run:
OpenSim.32BitLaunch.exe
On '''Linux''' run:
mono OpenSim.exe
This can be done under both 32 and 64 bit modes with the ODE physics engine.

== Running for the first time ==

If you're running OpenSimulator for the first time, it will ask you several questions at the console that will set up a single region for you. The configuration options you enter will be written to the bin/Regions/Regions.ini file, which you can then edit at a later date if you need to make changes.

Many of the questions have defaults. Here are some explanations of the questions asked:

* '''New region name'''
::The name for your region. Don't leave this blank!
* '''Region UUID'''
::The unique ID of your region. In pretty much all cases you will want to accept the randomly generated default in the square brackets. The only time when you wouldn't is if you were trying to set up a configuration to point to pre-existing region data. But in this case you are probably better off editing the Regions.ini file directly anyway
* '''Region Location'''
::This is the location of the region on the grid. In standalone mode you can safely leave these as the default (1000,1000). If you were to set up additional regions later on in Regions.ini then they would need different grid co-ordinates (e.g. 1000,1001). OpenSimulator regions can be placed anywhere on a 65536 by 65536 grid, but [[Hypergrid]] enabled regions may need special consideration for region location. See [[Installing and Running Hypergrid#The 4096 Regions Limit]] for more information.
* '''Internal IP address'''
::In virtually all cases this can be left as 0.0.0.0 (this is a wildcard that allows OpenSimulator to listen for UDP connections on any of the server's network interfaces). If you want to restrict UDP connections to only one network interface then you can specify an explicit IP address. This address is only used internally - the '''External host name''' is the one that is actually passed to the viewer (and hence is the important one).
* '''Internal port'''
::This is the IP port for all incoming client connections. The name is a bit misleading since it will be used externally (by a Second Life viewer, for instance) as well as internally. You can make this any port you want, but it is safe to leave at the default 9000. Each region on your server must have a unique port.
* '''Allow alternate ports'''
::This is currently experimental. Please leave it at the default of False.
* '''External host name'''
::If you leave this at the default 'SYSTEMIP' then this will become the LAN network address of the machine (e.g. 192.168.1.2). This is fine if you are connecting only from within your LAN. If you want to connect to it from a client on the internet, this should be the External IP Address of your router. Fully Qualified Domain Names (FQDNs) can also be used though they will be converted to a numeric IP address before being sent to the viewer.

The following details are also asked in OpenSimulator 0.6.9 and earlier.

* '''Master Avatar UUID'''
::This is a legacy OpenSimulator feature and can be left at the default of 00000000-0000-0000-0000-000000000000. Later on, you may want to change this to your own avatar's UUID in Regions.ini if you have problems editing terrain.
* '''Master Avatar first name'''
::This is an alternative way of specifying the master avatar by avatar name rather than UUID. If you press enter here then both this field and the last name field will be left blank. Accepting the blank default is fine - this can always be changed later in Regions.ini file.
* '''Master Avatar last name'''
::The last name of the master avatar.
* '''Master Avatar sandbox password'''
::The password of the master avatar.

In OpenSimulator 0.7 and later, OpenSimulator will ask you to assign each region to an estate during the setup process. If an estate needs to be created then it will also ask you to assign an estate manager. In standalone mode, an estate manager can also be created during the setup process.

Don't forget the account details you use to set up the master avatar (in 0.6.9) or the estate manager (in 0.7 and later). Only this user will initially be able to configure the in-world settings for your region. This is also a user account that you can use to perform your initial login test.

See [[Configuring Regions]] for more information about the Regions.ini file that these questions generate.

If you want to create a user other than the estate manager, then in the server console type:

create user

This will ask you a series of questions for creating a user (such as first name, last name and password).

== Network access for the standalone installation ==
In standalone mode, a viewer connecting to your installation needs the following network access to your installation machine.

1. TCP over the http_listener_port as used in your simulator. This is set in the [Network] section of your OpenSim.ini.

<source lang="ini">
[Network]
http_listener_port = 9000
</source>

This will be the default of 9000 if you have not explicitly changed it.

2. UDP over each region's InternalPort as configured in your region files (such as Regions.ini). For instance, if you have configured

<source lang="ini">
[test]
RegionUUID = dd5b77f8-bf88-45ac-aace-35bd76426c81
Location = 1000,1000
InternalAddress = 0.0.0.0
InternalPort = 9000
AllowAlternatePorts = False
ExternalHostName = mygrid.com

[test2]
RegionUUID = dd5b77f8-bf88-45ac-aace-35bd76426c82
Location = 1000,1001
InternalAddress = 0.0.0.0
InternalPort = 9001
AllowAlternatePorts = False
ExternalHostName = mygrid.com
</source>

then you will need to open ports 9000 and 9001 to UDP traffic.

3. The network address of the machine hosting the OpenSimulator installation must be accessible to connecting viewers. In the example above, the installation machine is reachable from the Internet via the domain name "mygrid.com". If the same installation needs to be accessed by viewers on the same network, it must be possible for them to also successfully resolve that domain name (not all routers, especially home routers, have this "loopback capability").

If the installation only needed to be accessed on the same LAN, then one could you the local IP address of the server (e.g. 192.168.1.2).

== Connecting to a standalone installation ==

To connect to your new sim with your user, start up a Second Life viewer with the following command line switches:

'''Client on same machine as OpenSim:'''
-loginuri http://127.0.0.1:9000

'''Client on same LAN as OpenSim:'''
-loginuri http://lan_ip:9000

'''Client on different machine or internet:'''
-loginuri http://external_ip:9000

Then enter the user name and password you set up in the previous step and your new user should login.

Be aware of [http://osgrid.org/forums/viewtopic.php?f=5&t=400&start=0&st=0&sk=t&sd=a loopback] problems when Running viewer & server(s) on the same machine (LAN) by using the "external" configuration. (<u>'''You might notice endless waiting for region handshake'''</u>.) See also [[Troubleshooting|troubleshoot hints]]. If you're having Connectivity problems, [[Network Settings|be sure to read the Network Configuration Page]]. This is important if you see Region handshake issue.

[[Image:Exclamation.png|left]]
== IMPORTANT NOTE, DIVA DISTRO - 4 Apr. 2012 - ==

'''If you download the latest version of diva-r18611.tar.bz''', it is necessary to first launch the setup program ''configure.exe''
*In Linux or MacOSX : open a terminal and enter "mono /diva-r18611/bin/Configure.exe" (assuming that you have placed the Diva distro in /diva-r18611)
*In Windows, assuming they extracted Diva in My Documents, one would open "Run => cmd" and enter '''cd "%USERPROFILE%\My Documents\diva-r18611\"'', followed by "Configure.exe".
After issuing the command, you can set your sim's domain name, and carefully answer the program's questions, then start the program as instructed in above paragraphs.

The program will install the optimum configuration for OpenSim, example: '''<nowiki>http://<your_IP>:9000</nowiki>''' and WiFi '''<nowiki>http:<your_IP>:9000/wifi</nowiki>'''
In the standalone version, four regions will be set up. You can optionally add other regions later on, so make sure to use the same first name with the addition of a number
(ex: "region 5", "region 6", "region 7", etc. otherwise you can't enter the region and you'd be placed in the nearest free location.

If you wish to enter a different region name, make sure that the "distance" between the island created by the Wifi configuration program and the next,
will be at least 40 positions away from the first installed region)
(command console: create region Johnnyland RegionConfigure.ini)

= Running OpenSimulator in Grid mode =
{|
| style="background:LavenderBlush; color:black" |
[[Image:Exclamation.png|left]]
NOTE: 0.7 is the first OpenSimulator release that fully migrates all services to the ROBUST server shell. OpenSim.Grid.UserServer.exe and MessageServer.exe from OpenSimulator 0.6.9 are no longer necessary. Please see the [[0.7 Release|0.7 release notes]] for more details. For details on how to set up grid services in OpenSimulator 0.6.9 and earlier please see [[OpenSim 0.6.9 Grid Mode Configuration]]
|}

Running OpenSimulator in grid mode is considerably more complicated than running a standalone instance. Instead of running everything in the same process, backend data services (asset, inventory, etc.) run in one or more separate processes, often on a different machine. This allows multiple OpenSim.exe simulator instances to use the same asset and inventory data.

== Step 1: Set up a ROBUST services instance ==

1. In the bin directory, copy Robust.ini.example to Robust.ini. The example file is configured to run all the services in a single ROBUST instance.

2. Configure the [[Database Settings]] in Robust.ini to use your MySQL database. Only MySQL is supported for running grid services.

3. Start up Robust.exe.

mono Robust.exe (Linux, BSD, Mac OS X)

or

Robust.exe (Windows)

If you don't see any errors (in red) on the console then you can move on to the next step.

4. Every region must belong to an estate, and every estate must have an owner which is a valid user account in OpenSim's user account service. Create a user on the ROBUST command console with the following command.

create user

This will ask you for the user's name, password and an optional e-mail. Remember this name since you will need it when you start up the simulator for the first time.

== Step 2: Configure an OpenSim.exe to use the ROBUST services ==

In grid mode, as in standalone mode, you need to configure OpenSim.ini which controls the 3D simulator itself.

However, instead of using and configuring the file config-include/StandaloneCommon.ini, a simulator connecting to a grid needs to use and configure the config-include/GridCommon.ini file, in order to connect to the ROBUST hosted remote data services rather than in-process local ones.

The steps for both these operations are as follows.

1. Copy bin/OpenSim.ini.example to OpenSim.ini

2. Find the [Architecture] section at the very bottom of OpenSim.ini. Make sure that one of the following lines is uncommented:

Include-Architecture = "config-include/Grid.ini" (in OpenSimulator 0.7.1 and later)

or

Include-Grid = "config-include/Grid.ini" (in OpenSimulator 0.7.0.2 and earlier)

The others should remain commented.

3. Go to bin/config-include and copy GridCommon.ini.example to GridCommon.ini.

4. Open GridCommon.ini in a text editor. You will see lots of URL entries, each of which have dummy defaults of http://myassetserver.com:8003, http://myinventoryserver.com:8003, etc. You will need to change each of these to point towards the address of your ROBUST instance. For instance, if you're running ROBUST on a machine with a local IP address of 192.168.1.2, you will need to change AssetServerURI to the setting

AssetServerURI = "http://192.168.1.2:8003"

5. Run OpenSim.exe. If you're running OpenSim.exe for the first time you will get the same questions about setting up the region that occur on a first-run in standalone mode. Please see the standalone section for instructions on how to answer these, or read more information about the Regions.ini file on the [[Configuring Regions]] page.

If everything is set up correctly, when starting up OpenSim.exe you shouldn't see any errors. You should also see the ROBUST console display log lines saying that the region has registered with the grid service. For example,

21:43:45 - [GRID SERVICE]: Region t1 (176cc95e-f693-4b02-8e08-af86e2372faa) registered successfully at 256000-256000
21:43:47 - [GRID SERVICE]: region t1 has 0 neighbours

== Network access for a grid installation ==
In standalone mode, a viewer connecting to your installation needs to access

# The login service over TCP and other configured public services (e.g. grid info, map).
# The http_server_port of each configured simulator over TCP.
# The InternalPort and ExternalHostName of each configured region.

The last two requirements are the same as for standalone installations, except that they apply to each server that hosts a simulator. Please see the standalone section above for more details.

The login service is a little different. Whereas in standalone this uses the same http_server_port as the simulator itself, in grid mode it's running in a separate ROBUST service.

The default port for the login service is 8002. You can see this used in the [ServiceList] section of Robust.ini.example.

<source lang="ini">
[ServiceList]
AssetServiceConnector = "8003/OpenSim.Server.Handlers.dll:AssetServiceConnector"
InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector"
GridServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridServiceConnector"
GridInfoServerInConnector = "8002/OpenSim.Server.Handlers.dll:GridInfoServerInConnector"
AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector"
OpenIdServerConnector = "8002/OpenSim.Server.Handlers.dll:OpenIdServerConnector"
AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector"
LLLoginServiceInConnector = "8002/OpenSim.Server.Handlers.dll:LLLoginServiceInConnector"
PresenceServiceConnector = "8003/OpenSim.Server.Handlers.dll:PresenceServiceConnector"
UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector"
GridUserServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridUserServiceConnector"
FriendsServiceConnector = "8003/OpenSim.Server.Handlers.dll:FriendsServiceConnector"
MapAddServiceConnector = "8003/OpenSim.Server.Handlers.dll:MapAddServiceConnector"
MapGetServiceConnector = "8002/OpenSim.Server.Handlers.dll:MapGetServiceConnector"
</source>

Here all the public services (those where the viewer connects directly to the service) are served on port 8002, with internal services on 8003. So you need to make sure that the viewer can access port 8002 over TCP but you do not want to expose port 8003. Only simulators need to be able to connect to port 8003.

== Connecting to a grid installation ==

Your client startup line will look something like

-loginuri http://mygrid.com:8002

The loginuri needs to be the address to the login service. In standalone mode, this was the same address as the region simulator and the port was 9000 by default. However, in grid mode it will be the address to login service hosted on the ROBUST instance. In this case, the address will be 192.168.1.2. The port number of 8002 is the traditional one for the grid login service and is the default in Robust.ini.example.

If the login is successful, you will see log lines on the ROBUST console (for the login itself) and then log lines on the region simulator console (as the login process tells the simulator to expect the avatar, tells the viewer the address of the region simulator and then when the viewer starts talking to the simulator directly).

= Running multiple ROBUST service instances =

If you are operating a grid, then you can run different services (e.g. asset, inventory) in different ROBUST instances, in order to spread the load. To do this, you will need to edit the ServiceConnectors parameter in the [Startup] section of Robust.ini (or Robust.HG.ini if you're running Hypergrid). The default ServiceConnectors parameter looks something like this

<source lang="ini">
[ServiceList]
AssetServiceConnector = "8003/OpenSim.Server.Handlers.dll:AssetServiceConnector"
InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector"
GridServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridServiceConnector"
GridInfoServerInConnector = "8002/OpenSim.Server.Handlers.dll:GridInfoServerInConnector"
AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector"
OpenIdServerConnector = "8002/OpenSim.Server.Handlers.dll:OpenIdServerConnector"
AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector"
LLLoginServiceInConnector = "8002/OpenSim.Server.Handlers.dll:LLLoginServiceInConnector"
PresenceServiceConnector = "8003/OpenSim.Server.Handlers.dll:PresenceServiceConnector"
UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector"
GridUserServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridUserServiceConnector"
FriendsServiceConnector = "8003/OpenSim.Server.Handlers.dll:FriendsServiceConnector"
MapAddServiceConnector = "8003/OpenSim.Server.Handlers.dll:MapAddServiceConnector"
MapGetServiceConnector = "8002/OpenSim.Server.Handlers.dll:MapGetServiceConnector"
</source>

Each entry has the form

<port-number>/<dll>:<connector-class-name>

For instance, the first entry above

8003/OpenSim.Server.Handlers.dll:AssetServiceConnector

says to start an AssetServiceConnector (and hence an asset service) from the OpenSim.Server.Handlers.dll and to server that from port 8003.

By default, Robust.exe loads a configuration file with the same name but with .ini appended instead of .exe. So Robust.exe will look for an inifile called Robust.ini. You can change this by giving the parameter on the commandline. For instance, to start Robust with HG parameters, one would use

Robust.exe -inifile=Robust.HG.ini

So if you wanted to run every connector apart from assets in one instance of ROBUST and the asset connector in another instance, you would have two ini files. One could remain Robust.ini and have

<source lang="ini">
[ServiceList]
InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector"
GridServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridServiceConnector"
GridInfoServerInConnector = "8002/OpenSim.Server.Handlers.dll:GridInfoServerInConnector"
AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector"
OpenIdServerConnector = "8002/OpenSim.Server.Handlers.dll:OpenIdServerConnector"
AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector"
LLLoginServiceInConnector = "8002/OpenSim.Server.Handlers.dll:LLLoginServiceInConnector"
PresenceServiceConnector = "8003/OpenSim.Server.Handlers.dll:PresenceServiceConnector"
UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector"
GridUserServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridUserServiceConnector"
FriendsServiceConnector = "8003/OpenSim.Server.Handlers.dll:FriendsServiceConnector"
MapAddServiceConnector = "8003/OpenSim.Server.Handlers.dll:MapAddServiceConnector"
MapGetServiceConnector = "8002/OpenSim.Server.Handlers.dll:MapGetServiceConnector"
</source>

The other could be called Robust.Assets.ini and have

<source lang="ini">
[ServiceList]
AssetServiceConnector = "8004/OpenSim.Server.Handlers.dll:AssetServiceConnector"
</source>

Note that this is using port 8004 instead of port 8003. This is necessary since only one executable can use each port at a time. You will need to make sure your simulator configuration files use port 8004 for the asset service as well.

You will also need to change the default network port to 8004 for this second copy of Robust.exe

<pre>
[Network]
port = 8004
</pre>

Once you've created the two ROBUST configuration files (Robust.ini containing all services apart from asset and Robust.Assets.ini containing only the asset service), then you could start the first Robust.exe as usual.

Robust.exe

This will load Robust.ini, as we haven't specified a Robust.ini. Also, the logfile it will use will be Robust.log as we haven't manually specified one.

The second ROBUST instance we would start with

Robust.exe -inifile=Robust.Assets.ini -logfile=Robust.Assets.log

The -inifile switch tells the second Robust instance to load it's configuration from Robust.Assets.ini rather than Robust.ini. The -logfile switch tells Robust.exe to use Robust.Assets.log as its logfile rather than the default Robust.log. If you don't specify this switch then you may see errors on the console about a locked log file.

At this point you should have two running Robust.exe instances.

If you put the ROBUST instances on different machines then don't forget to change the relevant service URIs in each simulator to match.

Since OpenSimulator services are stateless (e.g. every request is unconnected with other requests as long as they affect the same persistent data where necessary), you can also load balance by starting more than one ROBUST instance with a copy of the same service (e.g. multiple asset services using the same database). Requests would be round-robined between the service copies using an HTTP reverse proxy implementation (e.g. nginx). See [[Performance#Services]] for more details.

== Notes ==
[http://opensimulator.org/pipermail/opensim-users/2012-October/011099.html Useful discussion about separating Robust instances]

= Attaching your sim to someone else's grid =

To set up the region server (i.e., <tt>OpenSim.exe</tt>) to connect to an external grid, follow the [[Configuration#Step 2: Configure an OpenSim.exe to use the ROBUST services]] instructions above.

The grid will have already provided with the required services. In step 2 you will need to use the provided URLs for their services.

In your bin/Regions.ini file (or other region config file) you will also need to set the grid co-ordinates to your regions provided from the grid operator. See [[Configuring Regions]] for more information.

= Running an OpenSimulator standalone or grid installation with Hypergrid enabled =
[[Hypergrid]] is an emerging architecture supported by OpenSimulator that allows a user with an account on one standalone or grid to visit other Hypergrid-enabled standalones or grids, and for users from those grids to visit the home grid. This does not require the two installations to share a central set of data services (assets, inventory, etc.). Please see [[Installing and Running Hypergrid]] for more details.

= Further notes =

== Troubleshooting ==

See [[Troubleshooting]]

== Running OpenSimulator 0.6.7 to 0.7.6.1 in 64 bit Windows ==
[[Image:Exclamation.png|left]]

'''NOTE:''' ''Commits 3e5bc75 and e8ca900 move these to the directory ./share/32BitLaunch as they should no longer be needed and are slated for removal from the project'

As of OpenSimulator 0.6.7 and up to release 0.7.6.1, the default physics engine for OpenSimulator was changed to the ODE engine. This is because ODE was the most advanced physics engine plugin at the time in OpenSimulator. Unfortunately, it has the drawback in that its library is not compilable under 64-bit in Windows.

Therefore, in order to launch the region simulator under 64-bit Windows for versions 0.6.7 to 0.7.6.1 using ODE, users may need to run:

OpenSim.32BitLaunch.exe

instead of:

OpenSim.exe

An alternative is to use the basicphysics engine instead or one of the other alternative physics engines bundled with OpenSim, though all these were less functional than the ODE plugin.

From OpenSim 0.8 the default physics engine is BulletSim.
'

== Note About Mono ==

Mono and .NET have a built in threadpool. By default, OpenSimulator is instead configured to use a third-party threadpool called SmartThreadPool for many tasks, partly because of issues with early implementations of the Mono threadpool.

However, even with this setting, some other operations are carried out with the built-in threadpool. At least in some versions of Mono (chiefly prior to 2.6), the default configuration for this can cause issues with OpenSimulator - [http://www.mono-project.com/ThreadPool_DeadLocks ThreadPool_Deadlocks at the mono-project website].

If this is an issue or if the threadpool runs out of available threads, then the operation of your sim will start to break in all sorts of different ways. A common symptom is the freezing of all activity upon login of a new avatar.

The MONO_THREADS_PER_CPU parameter affects the number of existing built-in threadpool worker threads below which Mono will always spawn a new thread when OpenSimulator adds a new task. This is MONO_THREADS_PER_CPU * 4. So if set to 50, the minimum number of worker threads will be 200.

Above this number, Mono will make an internal decision whether to spawn a new thread or wait for an existing thread to complete its task.

The effect of this parameter is extremely implementation dependent, and so dependent upon the version of Mono that you are using. Before 2.6 for instance, it was definitely worth setting a high MONO_THREADS_PER_CPU due to issues with the Mono thread pool. In theory, later versions of Mono should not be susceptible to this issue. Mono 2.10.8.1, for instance, has a default MONO_THREADS_PER_CPU of 1 (despite what the incorrect Mono manpage says).

However, people still report a benefit from setting MONO_THREADS_PER_CPU higher than default. The exact number depends on many factors including: the number of CPUs in your machine, what else you use that machine for, how many regions you have in your sim, how many of them are adjacent, how many scripts you have, and how many avatars you expect to serve at the same time. As a reference, Wright Plaza in OSGrid, which is running as a single region on a sim and routinely hosts meetings with 20 avatars, uses the value 125.

For example: $ export MONO_THREADS_PER_CPU=125

So if you are having problems with avatars freezing and you're hardware meets or exceeds recommended [[Performance]] requirements, then you may want to setting this environment variable.

There is a very basic program for displaying current threadpool configuration settings at https://github.com/justincc/opensimulator-tools/tree/master/analysis/threadpool-info.

All this applies to the min threadpool numbers, not the max thread numbers. OpenSimulator itself will attempt to adjust the max numbers. You can see the output from this very near the top of the OpenSim.log file.

== Increasing the stack reserve level when using OpenDynamicsEngine on *nix ==

If you have problems using the OpenDynamicsEngine on *nix, try setting your stack reserve level higher than the default with the following command;
<tt>ulimit -s 262144</tt> Or, run the opensim-ode.sh to start up OpenSimulator.

== Firewalls ==
Some operation systems or distributions run their own firewall by default. If you can't access to OpenSimulator from remote client, you'll need to check their settings. See [[Firewall Settings]] for details.

== Legacy Configuration Information ==
These are some pages containing some legacy configuration information of unknown accuracy.

[[OpenSim 0.6.6 legacy configuration information]]

== Additional Optional Configuration Tasks ==

=== Further configure OpenSimulator ===
If you've looked through OpenSim.ini.example or any other of the config files, you'll see that there's a very large number of configurable parameters spread across multiple files. See [[Configuring Simulator Parameters]] for more details about the configuration infrastructure and how settings in identically named sections (e.g. [XEngine]) are merged by OpenSimulator on loading.

=== Set up a second region to run on the same simulator ===
See [[Configuring Regions]].

=== Run Multiple Standalone Instances of OpenSimulator on the Same Server ===
For each subsequent instance of OpenSim, change the 'http_listener_port' in OpenSim.ini to the value excluding 9000, and 'InternalPort' in Regions.ini to the value excluding 9000. Also, make sure your regions are using different ports, as explained in [[Configuring Regions]].

=== Load region content ===
You can load content onto regions by using the [[OpenSim Archives|load oar command]]. To load individual OAR files into each region, use the 'change region [regionname]' command and then 'load oar [oar-location]'.

=== OpenSim.exe command line options ===
OpenSim.exe has command line options which allow you to perform actions such as reading configuration files from a different directory. See [[OpenSim.exe Command Line Options]] for more details.

=== Script engine ===
OpenSimulator supports multiple script engines. See [[ScriptEngines]] for details. If you don't know what this means then the default script engine will be fine. In fact, recent versions of OpenSimulator only ship with one script engine, the XEngine.

=== Permissions Configuration ===
OpenSimulator has a quite elaborate set of permissions. See [[Permissions (Server)]] for details. By default, permissions are active on region simulators.

=== Logging ===
By default, OpenSimulator logs information to a file called OpenSim.log in the bin directory. See [[Logging]] for details on how to further configure this if required.

=== Set up other optional modules ===
* [[IRCBridgeModule]]
* [[Freeswitch Module]]
* [[Offline Messaging]]
* [[Enabling Groups]]
* See also [[User_Documentation#Setup]]

=== Configuration of Web Server and Pages ===
OpenSimulator contains a web server that can serve up a variety of pages. Some which come from external files and some are generated internally.
* [[External Files]]
* [[Internally Generated]]

= Where to go from here =

* [[NAT Loopback Routers]] Router and Nat Loopback Information

* [[Upgrading]] from an old OpenSimulator version to a newer one.

* [[Server Commands]] for creating users and controlling the system.

* Fix the bent knees bug: [[FAQ#Why are my knees bent when I stand idle.3F]]

= References =

* [http://dist.opensimulator.org/wiki/opensim-standalone.odg OpenOffice draw file for OpenSimulator standalone diagram]
* [http://dist.opensimulator.org/wiki/opensim-grid-simple.odg OpenOffice draw file for OpenSimulator grid diagram]

[[Category:Configuration]]

Configuration

2014-09-03T17:17:21Z

BlueWall: /* Running OpenSimulator 0.6.7 to 0.7.6.1 in 64 bit Windows */

{{Quicklinks}}
<br />
== OpenSimulator simulator configuration file ==
The region simulator configuration is managed using a file called OpenSim.ini. This file is used regardless of whether the sim is running in standalone or grid mode. This file references some additional configuration information from the config-include/ directory. Information about the various settings is contained in the OpenSim.ini file itself (or OpenSim.ini.example for reference).

Please note, that the name OpenSim.ini can be changed via [[OpenSim.exe Command Line Options|command line arguments]].

It is also possible to distribute the inifile settings over two files. This is useful if you want to run several OpenSimulator processes where most of your settings are identical except for a few. The master file is read first, then the inifile is read. Settings given in the inifile overrule settings given in the master file. The master file has the same format and the same keywords as the inifile, so the same documentation applies.

== Database ==

Opensim supports the following database-engines. Information about setting these up can be found in the OpenSim.ini.example file and the other various example files in bin/config-include. '''If you do not want to use the default SQLite configuration then you will need to setup your database before proceeding further'''. SQLite does not require further configuration. See [[Database Settings]] for the detailed settings.

* '''SQLite''' (default) - a lightweight database that comes bundled with OpenSimulator and can be used without requiring any extra configuration. It is mostly intended to get you up and running quickly, not for production use. It is significantly slower than MySQL. A few features here (such as attachment persistence) have not yet been fully implemented.

* '''MySQL''' (fully supported) - This is the recommended database for any use beyond experimentation or small standalone applications. The minimum MySQL version is 5.1.
::* '''Windows x64 systems:'''  There is currently an unresolved [http://opensimulator.org/mantis/bug_view_advanced_page.php?bug_id=5294 bug_id=5294] found when running OpenSimulator with MySQL 5.5 on Windows x64 systems.
::* '''Opensim 0.7.0.2:'''  Some users have reported problems with MySQL 5.1.55 and up with Opensim 0.7.0.2, see [http://opensim-users.2152040.n2.nabble.com/OpenSim-1-7-0-2-and-MySQL-Versions-td6155064.html this thread] for more information. The issue can be resolved by using an updated version of MySql.Data.dll OR installing an older version of MySQL such as [http://downloads.mysql.com/archives.php?p=mysql-5.1&v=5.1.52 MySQL 5.1.52] with Opensim version 0.7.0.2.  

* '''MSSQL''' (fairly supported) - persistence support for some recent OpenSimulator features may not yet be implemented though the vast majority of them are supported.

== Standalone vs. Grid ==
We recommend that you first get OpenSimulator running in standalone mode before you attempt to connect it to a grid or run your own grid. OpenSimulator will start up in standalone mode out-of-the-box on the binary distributions.

An OpenSimulator configuration consists of regions (run by region simulators) and backend data services (such as user, assets and inventory management).

A system running in '''standalone mode''' runs both the region simulator and all the data services in a single process when you run OpenSim.exe. In this mode you can run as many regions as you like but only on a single machine.

[[Image:Opensim-standalone.png|frame|center|OpenSimulator running in standalone mode. Both simulator and services run in the same process (OpenSim.exe).]]

In '''grid mode''', the data services are not part of the region server process. Instead, they are run in a separate executable called Robust.exe. A Robust shell can run all the services or they can be split amongst any number of Robust instances. This allows them to be run on entirely separate machines if necessary. In this mode, the OpenSim.exe acts solely as the region server, serving one or more regions that communicate with the separate data services. At this point you can run multiple OpenSim.exe region simulators on different machines.

[[Image:Opensim-grid-simple.png|frame|center|OpenSimulator running in grid mode. In this case, all the services are being run within a Robust.exe process. Multiple copies of OpenSim.exe (usually running on different machines) all use the same set of common services.]]

Running in grid mode is more complicated than running in standalone mode. It requires an understanding of UUID, X,Y location, server handshake passwords, estates and estate owners, and a couple of other settings. These require more care and patience to set up. We strongly recommend that you don't attempt this unless you are extremely patient and very technically proficient.

= Running OpenSimulator in Standalone mode =

Binary distributions of OpenSimulator are by default configured to run in standalone mode.

However, if you build OpenSimulator from the source distribution or from the git repository then you will need to:

# Change into the '''''bin''''' folder
# Copy the file '''''OpenSim.ini.example''''' to '''''OpenSim.ini'''''. This configures the 3D simulator itself.
# Change into the '''''bin/config-include''''' folder
# Copy the file '''''StandaloneCommon.ini.example''''' to '''''StandaloneCommon.ini'''''. This configures the in-process data services used by the standalone configuration.
# In the '''[Architecture]''' section of '''''OpenSim.ini''''', near the bottom of the file, uncomment the ''Standalone.ini'' line. To uncomment a line of code, remove the semi-colon (;) comment symbol preceding the line so that it says:

Include-Architecture = "config-include/Standalone.ini"

Running OpenSimulator is then a matter of launching OpenSim.exe. However, you need to have installed all dependencies before that. See [[Dependencies]] for details. After that, open a command prompt (for Windows users, Start menu > Run > cmd) and navigate to the Opensim /bin directory.

On a '''Windows 32-bit''' command prompt:
OpenSim.exe
Under '''Windows 64-bit''', ODE cannot yet be compiled for 64 bit mode, so if using the default ODE physics plugin run:
OpenSim.32BitLaunch.exe
On '''Linux''' run:
mono OpenSim.exe
This can be done under both 32 and 64 bit modes with the ODE physics engine.

== Running for the first time ==

If you're running OpenSimulator for the first time, it will ask you several questions at the console that will set up a single region for you. The configuration options you enter will be written to the bin/Regions/Regions.ini file, which you can then edit at a later date if you need to make changes.

Many of the questions have defaults. Here are some explanations of the questions asked:

* '''New region name'''
::The name for your region. Don't leave this blank!
* '''Region UUID'''
::The unique ID of your region. In pretty much all cases you will want to accept the randomly generated default in the square brackets. The only time when you wouldn't is if you were trying to set up a configuration to point to pre-existing region data. But in this case you are probably better off editing the Regions.ini file directly anyway
* '''Region Location'''
::This is the location of the region on the grid. In standalone mode you can safely leave these as the default (1000,1000). If you were to set up additional regions later on in Regions.ini then they would need different grid co-ordinates (e.g. 1000,1001). OpenSimulator regions can be placed anywhere on a 65536 by 65536 grid, but [[Hypergrid]] enabled regions may need special consideration for region location. See [[Installing and Running Hypergrid#The 4096 Regions Limit]] for more information.
* '''Internal IP address'''
::In virtually all cases this can be left as 0.0.0.0 (this is a wildcard that allows OpenSimulator to listen for UDP connections on any of the server's network interfaces). If you want to restrict UDP connections to only one network interface then you can specify an explicit IP address. This address is only used internally - the '''External host name''' is the one that is actually passed to the viewer (and hence is the important one).
* '''Internal port'''
::This is the IP port for all incoming client connections. The name is a bit misleading since it will be used externally (by a Second Life viewer, for instance) as well as internally. You can make this any port you want, but it is safe to leave at the default 9000. Each region on your server must have a unique port.
* '''Allow alternate ports'''
::This is currently experimental. Please leave it at the default of False.
* '''External host name'''
::If you leave this at the default 'SYSTEMIP' then this will become the LAN network address of the machine (e.g. 192.168.1.2). This is fine if you are connecting only from within your LAN. If you want to connect to it from a client on the internet, this should be the External IP Address of your router. Fully Qualified Domain Names (FQDNs) can also be used though they will be converted to a numeric IP address before being sent to the viewer.

The following details are also asked in OpenSimulator 0.6.9 and earlier.

* '''Master Avatar UUID'''
::This is a legacy OpenSimulator feature and can be left at the default of 00000000-0000-0000-0000-000000000000. Later on, you may want to change this to your own avatar's UUID in Regions.ini if you have problems editing terrain.
* '''Master Avatar first name'''
::This is an alternative way of specifying the master avatar by avatar name rather than UUID. If you press enter here then both this field and the last name field will be left blank. Accepting the blank default is fine - this can always be changed later in Regions.ini file.
* '''Master Avatar last name'''
::The last name of the master avatar.
* '''Master Avatar sandbox password'''
::The password of the master avatar.

In OpenSimulator 0.7 and later, OpenSimulator will ask you to assign each region to an estate during the setup process. If an estate needs to be created then it will also ask you to assign an estate manager. In standalone mode, an estate manager can also be created during the setup process.

Don't forget the account details you use to set up the master avatar (in 0.6.9) or the estate manager (in 0.7 and later). Only this user will initially be able to configure the in-world settings for your region. This is also a user account that you can use to perform your initial login test.

See [[Configuring Regions]] for more information about the Regions.ini file that these questions generate.

If you want to create a user other than the estate manager, then in the server console type:

create user

This will ask you a series of questions for creating a user (such as first name, last name and password).

== Network access for the standalone installation ==
In standalone mode, a viewer connecting to your installation needs the following network access to your installation machine.

1. TCP over the http_listener_port as used in your simulator. This is set in the [Network] section of your OpenSim.ini.

<source lang="ini">
[Network]
http_listener_port = 9000
</source>

This will be the default of 9000 if you have not explicitly changed it.

2. UDP over each region's InternalPort as configured in your region files (such as Regions.ini). For instance, if you have configured

<source lang="ini">
[test]
RegionUUID = dd5b77f8-bf88-45ac-aace-35bd76426c81
Location = 1000,1000
InternalAddress = 0.0.0.0
InternalPort = 9000
AllowAlternatePorts = False
ExternalHostName = mygrid.com

[test2]
RegionUUID = dd5b77f8-bf88-45ac-aace-35bd76426c82
Location = 1000,1001
InternalAddress = 0.0.0.0
InternalPort = 9001
AllowAlternatePorts = False
ExternalHostName = mygrid.com
</source>

then you will need to open ports 9000 and 9001 to UDP traffic.

3. The network address of the machine hosting the OpenSimulator installation must be accessible to connecting viewers. In the example above, the installation machine is reachable from the Internet via the domain name "mygrid.com". If the same installation needs to be accessed by viewers on the same network, it must be possible for them to also successfully resolve that domain name (not all routers, especially home routers, have this "loopback capability").

If the installation only needed to be accessed on the same LAN, then one could you the local IP address of the server (e.g. 192.168.1.2).

== Connecting to a standalone installation ==

To connect to your new sim with your user, start up a Second Life viewer with the following command line switches:

'''Client on same machine as OpenSim:'''
-loginuri http://127.0.0.1:9000

'''Client on same LAN as OpenSim:'''
-loginuri http://lan_ip:9000

'''Client on different machine or internet:'''
-loginuri http://external_ip:9000

Then enter the user name and password you set up in the previous step and your new user should login.

Be aware of [http://osgrid.org/forums/viewtopic.php?f=5&t=400&start=0&st=0&sk=t&sd=a loopback] problems when Running viewer & server(s) on the same machine (LAN) by using the "external" configuration. (<u>'''You might notice endless waiting for region handshake'''</u>.) See also [[Troubleshooting|troubleshoot hints]]. If you're having Connectivity problems, [[Network Settings|be sure to read the Network Configuration Page]]. This is important if you see Region handshake issue.

[[Image:Exclamation.png|left]]
== IMPORTANT NOTE, DIVA DISTRO - 4 Apr. 2012 - ==

'''If you download the latest version of diva-r18611.tar.bz''', it is necessary to first launch the setup program ''configure.exe''
*In Linux or MacOSX : open a terminal and enter "mono /diva-r18611/bin/Configure.exe" (assuming that you have placed the Diva distro in /diva-r18611)
*In Windows, assuming they extracted Diva in My Documents, one would open "Run => cmd" and enter '''cd "%USERPROFILE%\My Documents\diva-r18611\"'', followed by "Configure.exe".
After issuing the command, you can set your sim's domain name, and carefully answer the program's questions, then start the program as instructed in above paragraphs.

The program will install the optimum configuration for OpenSim, example: '''<nowiki>http://<your_IP>:9000</nowiki>''' and WiFi '''<nowiki>http:<your_IP>:9000/wifi</nowiki>'''
In the standalone version, four regions will be set up. You can optionally add other regions later on, so make sure to use the same first name with the addition of a number
(ex: "region 5", "region 6", "region 7", etc. otherwise you can't enter the region and you'd be placed in the nearest free location.

If you wish to enter a different region name, make sure that the "distance" between the island created by the Wifi configuration program and the next,
will be at least 40 positions away from the first installed region)
(command console: create region Johnnyland RegionConfigure.ini)

= Running OpenSimulator in Grid mode =
{|
| style="background:LavenderBlush; color:black" |
[[Image:Exclamation.png|left]]
NOTE: 0.7 is the first OpenSimulator release that fully migrates all services to the ROBUST server shell. OpenSim.Grid.UserServer.exe and MessageServer.exe from OpenSimulator 0.6.9 are no longer necessary. Please see the [[0.7 Release|0.7 release notes]] for more details. For details on how to set up grid services in OpenSimulator 0.6.9 and earlier please see [[OpenSim 0.6.9 Grid Mode Configuration]]
|}

Running OpenSimulator in grid mode is considerably more complicated than running a standalone instance. Instead of running everything in the same process, backend data services (asset, inventory, etc.) run in one or more separate processes, often on a different machine. This allows multiple OpenSim.exe simulator instances to use the same asset and inventory data.

== Step 1: Set up a ROBUST services instance ==

1. In the bin directory, copy Robust.ini.example to Robust.ini. The example file is configured to run all the services in a single ROBUST instance.

2. Configure the [[Database Settings]] in Robust.ini to use your MySQL database. Only MySQL is supported for running grid services.

3. Start up Robust.exe.

mono Robust.exe (Linux, BSD, Mac OS X)

or

Robust.exe (Windows)

If you don't see any errors (in red) on the console then you can move on to the next step.

4. Every region must belong to an estate, and every estate must have an owner which is a valid user account in OpenSim's user account service. Create a user on the ROBUST command console with the following command.

create user

This will ask you for the user's name, password and an optional e-mail. Remember this name since you will need it when you start up the simulator for the first time.

== Step 2: Configure an OpenSim.exe to use the ROBUST services ==

In grid mode, as in standalone mode, you need to configure OpenSim.ini which controls the 3D simulator itself.

However, instead of using and configuring the file config-include/StandaloneCommon.ini, a simulator connecting to a grid needs to use and configure the config-include/GridCommon.ini file, in order to connect to the ROBUST hosted remote data services rather than in-process local ones.

The steps for both these operations are as follows.

1. Copy bin/OpenSim.ini.example to OpenSim.ini

2. Find the [Architecture] section at the very bottom of OpenSim.ini. Make sure that one of the following lines is uncommented:

Include-Architecture = "config-include/Grid.ini" (in OpenSimulator 0.7.1 and later)

or

Include-Grid = "config-include/Grid.ini" (in OpenSimulator 0.7.0.2 and earlier)

The others should remain commented.

3. Go to bin/config-include and copy GridCommon.ini.example to GridCommon.ini.

4. Open GridCommon.ini in a text editor. You will see lots of URL entries, each of which have dummy defaults of http://myassetserver.com:8003, http://myinventoryserver.com:8003, etc. You will need to change each of these to point towards the address of your ROBUST instance. For instance, if you're running ROBUST on a machine with a local IP address of 192.168.1.2, you will need to change AssetServerURI to the setting

AssetServerURI = "http://192.168.1.2:8003"

5. Run OpenSim.exe. If you're running OpenSim.exe for the first time you will get the same questions about setting up the region that occur on a first-run in standalone mode. Please see the standalone section for instructions on how to answer these, or read more information about the Regions.ini file on the [[Configuring Regions]] page.

If everything is set up correctly, when starting up OpenSim.exe you shouldn't see any errors. You should also see the ROBUST console display log lines saying that the region has registered with the grid service. For example,

21:43:45 - [GRID SERVICE]: Region t1 (176cc95e-f693-4b02-8e08-af86e2372faa) registered successfully at 256000-256000
21:43:47 - [GRID SERVICE]: region t1 has 0 neighbours

== Network access for a grid installation ==
In standalone mode, a viewer connecting to your installation needs to access

# The login service over TCP and other configured public services (e.g. grid info, map).
# The http_server_port of each configured simulator over TCP.
# The InternalPort and ExternalHostName of each configured region.

The last two requirements are the same as for standalone installations, except that they apply to each server that hosts a simulator. Please see the standalone section above for more details.

The login service is a little different. Whereas in standalone this uses the same http_server_port as the simulator itself, in grid mode it's running in a separate ROBUST service.

The default port for the login service is 8002. You can see this used in the [ServiceList] section of Robust.ini.example.

<source lang="ini">
[ServiceList]
AssetServiceConnector = "8003/OpenSim.Server.Handlers.dll:AssetServiceConnector"
InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector"
GridServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridServiceConnector"
GridInfoServerInConnector = "8002/OpenSim.Server.Handlers.dll:GridInfoServerInConnector"
AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector"
OpenIdServerConnector = "8002/OpenSim.Server.Handlers.dll:OpenIdServerConnector"
AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector"
LLLoginServiceInConnector = "8002/OpenSim.Server.Handlers.dll:LLLoginServiceInConnector"
PresenceServiceConnector = "8003/OpenSim.Server.Handlers.dll:PresenceServiceConnector"
UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector"
GridUserServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridUserServiceConnector"
FriendsServiceConnector = "8003/OpenSim.Server.Handlers.dll:FriendsServiceConnector"
MapAddServiceConnector = "8003/OpenSim.Server.Handlers.dll:MapAddServiceConnector"
MapGetServiceConnector = "8002/OpenSim.Server.Handlers.dll:MapGetServiceConnector"
</source>

Here all the public services (those where the viewer connects directly to the service) are served on port 8002, with internal services on 8003. So you need to make sure that the viewer can access port 8002 over TCP but you do not want to expose port 8003. Only simulators need to be able to connect to port 8003.

== Connecting to a grid installation ==

Your client startup line will look something like

-loginuri http://mygrid.com:8002

The loginuri needs to be the address to the login service. In standalone mode, this was the same address as the region simulator and the port was 9000 by default. However, in grid mode it will be the address to login service hosted on the ROBUST instance. In this case, the address will be 192.168.1.2. The port number of 8002 is the traditional one for the grid login service and is the default in Robust.ini.example.

If the login is successful, you will see log lines on the ROBUST console (for the login itself) and then log lines on the region simulator console (as the login process tells the simulator to expect the avatar, tells the viewer the address of the region simulator and then when the viewer starts talking to the simulator directly).

= Running multiple ROBUST service instances =

If you are operating a grid, then you can run different services (e.g. asset, inventory) in different ROBUST instances, in order to spread the load. To do this, you will need to edit the ServiceConnectors parameter in the [Startup] section of Robust.ini (or Robust.HG.ini if you're running Hypergrid). The default ServiceConnectors parameter looks something like this

<source lang="ini">
[ServiceList]
AssetServiceConnector = "8003/OpenSim.Server.Handlers.dll:AssetServiceConnector"
InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector"
GridServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridServiceConnector"
GridInfoServerInConnector = "8002/OpenSim.Server.Handlers.dll:GridInfoServerInConnector"
AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector"
OpenIdServerConnector = "8002/OpenSim.Server.Handlers.dll:OpenIdServerConnector"
AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector"
LLLoginServiceInConnector = "8002/OpenSim.Server.Handlers.dll:LLLoginServiceInConnector"
PresenceServiceConnector = "8003/OpenSim.Server.Handlers.dll:PresenceServiceConnector"
UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector"
GridUserServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridUserServiceConnector"
FriendsServiceConnector = "8003/OpenSim.Server.Handlers.dll:FriendsServiceConnector"
MapAddServiceConnector = "8003/OpenSim.Server.Handlers.dll:MapAddServiceConnector"
MapGetServiceConnector = "8002/OpenSim.Server.Handlers.dll:MapGetServiceConnector"
</source>

Each entry has the form

<port-number>/<dll>:<connector-class-name>

For instance, the first entry above

8003/OpenSim.Server.Handlers.dll:AssetServiceConnector

says to start an AssetServiceConnector (and hence an asset service) from the OpenSim.Server.Handlers.dll and to server that from port 8003.

By default, Robust.exe loads a configuration file with the same name but with .ini appended instead of .exe. So Robust.exe will look for an inifile called Robust.ini. You can change this by giving the parameter on the commandline. For instance, to start Robust with HG parameters, one would use

Robust.exe -inifile=Robust.HG.ini

So if you wanted to run every connector apart from assets in one instance of ROBUST and the asset connector in another instance, you would have two ini files. One could remain Robust.ini and have

<source lang="ini">
[ServiceList]
InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector"
GridServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridServiceConnector"
GridInfoServerInConnector = "8002/OpenSim.Server.Handlers.dll:GridInfoServerInConnector"
AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector"
OpenIdServerConnector = "8002/OpenSim.Server.Handlers.dll:OpenIdServerConnector"
AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector"
LLLoginServiceInConnector = "8002/OpenSim.Server.Handlers.dll:LLLoginServiceInConnector"
PresenceServiceConnector = "8003/OpenSim.Server.Handlers.dll:PresenceServiceConnector"
UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector"
GridUserServiceConnector = "8003/OpenSim.Server.Handlers.dll:GridUserServiceConnector"
FriendsServiceConnector = "8003/OpenSim.Server.Handlers.dll:FriendsServiceConnector"
MapAddServiceConnector = "8003/OpenSim.Server.Handlers.dll:MapAddServiceConnector"
MapGetServiceConnector = "8002/OpenSim.Server.Handlers.dll:MapGetServiceConnector"
</source>

The other could be called Robust.Assets.ini and have

<source lang="ini">
[ServiceList]
AssetServiceConnector = "8004/OpenSim.Server.Handlers.dll:AssetServiceConnector"
</source>

Note that this is using port 8004 instead of port 8003. This is necessary since only one executable can use each port at a time. You will need to make sure your simulator configuration files use port 8004 for the asset service as well.

You will also need to change the default network port to 8004 for this second copy of Robust.exe

<pre>
[Network]
port = 8004
</pre>

Once you've created the two ROBUST configuration files (Robust.ini containing all services apart from asset and Robust.Assets.ini containing only the asset service), then you could start the first Robust.exe as usual.

Robust.exe

This will load Robust.ini, as we haven't specified a Robust.ini. Also, the logfile it will use will be Robust.log as we haven't manually specified one.

The second ROBUST instance we would start with

Robust.exe -inifile=Robust.Assets.ini -logfile=Robust.Assets.log

The -inifile switch tells the second Robust instance to load it's configuration from Robust.Assets.ini rather than Robust.ini. The -logfile switch tells Robust.exe to use Robust.Assets.log as its logfile rather than the default Robust.log. If you don't specify this switch then you may see errors on the console about a locked log file.

At this point you should have two running Robust.exe instances.

If you put the ROBUST instances on different machines then don't forget to change the relevant service URIs in each simulator to match.

Since OpenSimulator services are stateless (e.g. every request is unconnected with other requests as long as they affect the same persistent data where necessary), you can also load balance by starting more than one ROBUST instance with a copy of the same service (e.g. multiple asset services using the same database). Requests would be round-robined between the service copies using an HTTP reverse proxy implementation (e.g. nginx). See [[Performance#Services]] for more details.

== Notes ==
[http://opensimulator.org/pipermail/opensim-users/2012-October/011099.html Useful discussion about separating Robust instances]

= Attaching your sim to someone else's grid =

To set up the region server (i.e., <tt>OpenSim.exe</tt>) to connect to an external grid, follow the [[Configuration#Step 2: Configure an OpenSim.exe to use the ROBUST services]] instructions above.

The grid will have already provided with the required services. In step 2 you will need to use the provided URLs for their services.

In your bin/Regions.ini file (or other region config file) you will also need to set the grid co-ordinates to your regions provided from the grid operator. See [[Configuring Regions]] for more information.

= Running an OpenSimulator standalone or grid installation with Hypergrid enabled =
[[Hypergrid]] is an emerging architecture supported by OpenSimulator that allows a user with an account on one standalone or grid to visit other Hypergrid-enabled standalones or grids, and for users from those grids to visit the home grid. This does not require the two installations to share a central set of data services (assets, inventory, etc.). Please see [[Installing and Running Hypergrid]] for more details.

= Further notes =

== Troubleshooting ==

See [[Troubleshooting]]

== Running OpenSimulator 0.6.7 to 0.7.6.1 in 64 bit Windows ==
[[Image:Exclamation.png|left]]
As of OpenSimulator 0.6.7 and up to release 0.7.6.1, the default physics engine for OpenSimulator was changed to the ODE engine. This is because ODE was the most advanced physics engine plugin at the time in OpenSimulator. Unfortunately, it has the drawback in that its library is not compilable under 64-bit in Windows.

Therefore, in order to launch the region simulator under 64-bit Windows for versions 0.6.7 to 0.7.6.1 using ODE, users may need to run:

OpenSim.32BitLaunch.exe

instead of:

OpenSim.exe

An alternative is to use the basicphysics engine instead or one of the other alternative physics engines bundled with OpenSim, though all these were less functional than the ODE plugin.

From OpenSim 0.8 the default physics engine is BulletSim.

'''NOTE:''' ''Commits 3e5bc75 and e8ca900 move these to the directory ./share/32BitLaunch as they should no longer be needed and are slated for removal from the project''

== Note About Mono ==

Mono and .NET have a built in threadpool. By default, OpenSimulator is instead configured to use a third-party threadpool called SmartThreadPool for many tasks, partly because of issues with early implementations of the Mono threadpool.

However, even with this setting, some other operations are carried out with the built-in threadpool. At least in some versions of Mono (chiefly prior to 2.6), the default configuration for this can cause issues with OpenSimulator - [http://www.mono-project.com/ThreadPool_DeadLocks ThreadPool_Deadlocks at the mono-project website].

If this is an issue or if the threadpool runs out of available threads, then the operation of your sim will start to break in all sorts of different ways. A common symptom is the freezing of all activity upon login of a new avatar.

The MONO_THREADS_PER_CPU parameter affects the number of existing built-in threadpool worker threads below which Mono will always spawn a new thread when OpenSimulator adds a new task. This is MONO_THREADS_PER_CPU * 4. So if set to 50, the minimum number of worker threads will be 200.

Above this number, Mono will make an internal decision whether to spawn a new thread or wait for an existing thread to complete its task.

The effect of this parameter is extremely implementation dependent, and so dependent upon the version of Mono that you are using. Before 2.6 for instance, it was definitely worth setting a high MONO_THREADS_PER_CPU due to issues with the Mono thread pool. In theory, later versions of Mono should not be susceptible to this issue. Mono 2.10.8.1, for instance, has a default MONO_THREADS_PER_CPU of 1 (despite what the incorrect Mono manpage says).

However, people still report a benefit from setting MONO_THREADS_PER_CPU higher than default. The exact number depends on many factors including: the number of CPUs in your machine, what else you use that machine for, how many regions you have in your sim, how many of them are adjacent, how many scripts you have, and how many avatars you expect to serve at the same time. As a reference, Wright Plaza in OSGrid, which is running as a single region on a sim and routinely hosts meetings with 20 avatars, uses the value 125.

For example: $ export MONO_THREADS_PER_CPU=125

So if you are having problems with avatars freezing and you're hardware meets or exceeds recommended [[Performance]] requirements, then you may want to setting this environment variable.

There is a very basic program for displaying current threadpool configuration settings at https://github.com/justincc/opensimulator-tools/tree/master/analysis/threadpool-info.

All this applies to the min threadpool numbers, not the max thread numbers. OpenSimulator itself will attempt to adjust the max numbers. You can see the output from this very near the top of the OpenSim.log file.

== Increasing the stack reserve level when using OpenDynamicsEngine on *nix ==

If you have problems using the OpenDynamicsEngine on *nix, try setting your stack reserve level higher than the default with the following command;
<tt>ulimit -s 262144</tt> Or, run the opensim-ode.sh to start up OpenSimulator.

== Firewalls ==
Some operation systems or distributions run their own firewall by default. If you can't access to OpenSimulator from remote client, you'll need to check their settings. See [[Firewall Settings]] for details.

== Legacy Configuration Information ==
These are some pages containing some legacy configuration information of unknown accuracy.

[[OpenSim 0.6.6 legacy configuration information]]

== Additional Optional Configuration Tasks ==

=== Further configure OpenSimulator ===
If you've looked through OpenSim.ini.example or any other of the config files, you'll see that there's a very large number of configurable parameters spread across multiple files. See [[Configuring Simulator Parameters]] for more details about the configuration infrastructure and how settings in identically named sections (e.g. [XEngine]) are merged by OpenSimulator on loading.

=== Set up a second region to run on the same simulator ===
See [[Configuring Regions]].

=== Run Multiple Standalone Instances of OpenSimulator on the Same Server ===
For each subsequent instance of OpenSim, change the 'http_listener_port' in OpenSim.ini to the value excluding 9000, and 'InternalPort' in Regions.ini to the value excluding 9000. Also, make sure your regions are using different ports, as explained in [[Configuring Regions]].

=== Load region content ===
You can load content onto regions by using the [[OpenSim Archives|load oar command]]. To load individual OAR files into each region, use the 'change region [regionname]' command and then 'load oar [oar-location]'.

=== OpenSim.exe command line options ===
OpenSim.exe has command line options which allow you to perform actions such as reading configuration files from a different directory. See [[OpenSim.exe Command Line Options]] for more details.

=== Script engine ===
OpenSimulator supports multiple script engines. See [[ScriptEngines]] for details. If you don't know what this means then the default script engine will be fine. In fact, recent versions of OpenSimulator only ship with one script engine, the XEngine.

=== Permissions Configuration ===
OpenSimulator has a quite elaborate set of permissions. See [[Permissions (Server)]] for details. By default, permissions are active on region simulators.

=== Logging ===
By default, OpenSimulator logs information to a file called OpenSim.log in the bin directory. See [[Logging]] for details on how to further configure this if required.

=== Set up other optional modules ===
* [[IRCBridgeModule]]
* [[Freeswitch Module]]
* [[Offline Messaging]]
* [[Enabling Groups]]
* See also [[User_Documentation#Setup]]

=== Configuration of Web Server and Pages ===
OpenSimulator contains a web server that can serve up a variety of pages. Some which come from external files and some are generated internally.
* [[External Files]]
* [[Internally Generated]]

= Where to go from here =

* [[NAT Loopback Routers]] Router and Nat Loopback Information

* [[Upgrading]] from an old OpenSimulator version to a newer one.

* [[Server Commands]] for creating users and controlling the system.

* Fix the bent knees bug: [[FAQ#Why are my knees bent when I stand idle.3F]]

= References =

* [http://dist.opensimulator.org/wiki/opensim-standalone.odg OpenOffice draw file for OpenSimulator standalone diagram]
* [http://dist.opensimulator.org/wiki/opensim-grid-simple.odg OpenOffice draw file for OpenSimulator grid diagram]

[[Category:Configuration]]

SimulatorFeatures

2014-08-07T01:10:52Z

BlueWall: /* Robust */

= SimulatorFeaturesModule =
from dev-master hash/commit time 10a8d28_1407360312
== Overview ==
The SimulatorFeaturesModule is the mechanism used to inform the viewer about a region's ability to handle mesh model objects. This information is sent when the presence is created in the region so the viewer will be able to determine the region's mesh capabilities. There are no configurable items for the features. But, many OpenSim capable viewers support extended use of the simulator features to pass other parameters that the viewer can use to dynamically refresh values needed to properly operate components for the grid containing the region. This is particularly useful for Hypergrid since several viewer components receive parameters upon login and are specific to that grid. Unless the parameters are dynamically refreshed, the components will not work when visiting new grids. We pass the parameters inside a data structure named "OpenSimExtras" along with the simulator features.

== Configuration ==
The region sends this data to the viewer, and we support the setting of these extras in the configuration of the simulator. But, we use the Robust GridService to push default values to the regions when they startup. The values we send are identical to the parameters we send in our home grid's login service when the user logs into the grid.
=== Robust ===
We currently (dev-master hash/commit time 10a8d28_1407360312 forward) support the configuration of several parameters via the Robust ini.
<source lang=ini>
[GridService]
; Support viewer export of content
ExportSupported = true

[LoginService]

; Grid Search service url
SearchURL = "url to search service"

; Grid Map Service
MapTileURL = "http://127.0.0.1:8002"

; Grid destination guide url
DestinationGuide = "url to destination guide (grid favorite locations)"
</source>

=== OpenSim ===

OpenSimExtras are configured in several places through the code and the best way to track them is to search for modules that watch the OnSimulatorFeaturesRequest event. We support the override of the grid defaults in the SimulatorFeaturesModule, but the defaults should be set at the grid level to ensure that the services required to operate the viewer components will be correct when users login or enter regions via Hypergrid.

<source lang=ini>
[SimulatorFeatures]

; Grid search service url
SearchServerURI = "url to grid search service"

; Grid destination guide url
DestinationGuideURI = "url to grid search service"

; Grid map service url
;(this may be set in one of several other locations, but we can use this to be consistent)
MapTileURL = "url to grid map service"

</source>

Extra information sent to the viewer over the SimulatorFeatures capability:

The OpenSimulator specific proportion of this is as follows (TODO: Really need to document the surrounding SimulatorFeatures structure as well!).

OpenSimExtras (OSDMap)
map-server-url (string)
search-server-url (string)
destination-guide-url (string)
ExportSupported (Boolean)
say-range (integer)
whisper-range (integer)
shout-range (integer)

Any of these is optional -- it may or may not be sent by the simulators. The entire map OpenSimExtras may or may not be present.

Portions of this are available in OpenSimulator 0.7.6 onward. Grid support is only available from dev-master hash/commit time 10a8d28_1407360312 onward.

SimulatorFeatures

2014-08-07T00:59:22Z

BlueWall: /* SimulatorFeaturesModule */

= SimulatorFeaturesModule =
from dev-master hash/commit time 10a8d28_1407360312
== Overview ==
The SimulatorFeaturesModule is the mechanism used to inform the viewer about a region's ability to handle mesh model objects. This information is sent when the presence is created in the region so the viewer will be able to determine the region's mesh capabilities. There are no configurable items for the features. But, many OpenSim capable viewers support extended use of the simulator features to pass other parameters that the viewer can use to dynamically refresh values needed to properly operate components for the grid containing the region. This is particularly useful for Hypergrid since several viewer components receive parameters upon login and are specific to that grid. Unless the parameters are dynamically refreshed, the components will not work when visiting new grids. We pass the parameters inside a data structure named "OpenSimExtras" along with the simulator features.

== Configuration ==
The region sends this data to the viewer, and we support the setting of these extras in the configuration of the simulator. But, we use the Robust GridService to push default values to the regions when they startup. The values we send are identical to the parameters we send in our home grid's login service when the user logs into the grid.
=== Robust ===
We currently (dev-master hash/commit time b4c6e23-1407353915 forward) support the configuration of several parameters via the Robust ini.
<source lang=ini>
[GridService]
; Support viewer export of content
ExportSupported = true

[LoginService]

; Grid Search service url
SearchURL = "url to search service"

; Grid Map Service
MapTileURL = "http://127.0.0.1:8002"

; Grid destination guide url
DestinationGuide = "url to destination guide (grid favorite locations)"
</source>

=== OpenSim ===

OpenSimExtras are configured in several places through the code and the best way to track them is to search for modules that watch the OnSimulatorFeaturesRequest event. We support the override of the grid defaults in the SimulatorFeaturesModule, but the defaults should be set at the grid level to ensure that the services required to operate the viewer components will be correct when users login or enter regions via Hypergrid.

<source lang=ini>
[SimulatorFeatures]

; Grid search service url
SearchServerURI = "url to grid search service"

; Grid destination guide url
DestinationGuideURI = "url to grid search service"

; Grid map service url
;(this may be set in one of several other locations, but we can use this to be consistent)
MapTileURL = "url to grid map service"

</source>

Extra information sent to the viewer over the SimulatorFeatures capability:

The OpenSimulator specific proportion of this is as follows (TODO: Really need to document the surrounding SimulatorFeatures structure as well!).

OpenSimExtras (OSDMap)
map-server-url (string)
search-server-url (string)
destination-guide-url (string)
ExportSupported (Boolean)
say-range (integer)
whisper-range (integer)
shout-range (integer)

Any of these is optional -- it may or may not be sent by the simulators. The entire map OpenSimExtras may or may not be present.

Portions of this are available in OpenSimulator 0.7.6 onward. Grid support is only available from dev-master hash/commit time 10a8d28_1407360312 onward.

SimulatorFeatures

2014-08-06T21:12:46Z

BlueWall: /* Robust */

= SimulatorFeaturesModule =
from dev-master hash/commit time b4c6e23-1407353915
== Overview ==
The SimulatorFeaturesModule is the mechanism used to inform the viewer about a region's ability to handle mesh model objects. This information is sent when the presence is created in the region so the viewer will be able to determine the region's mesh capabilities. There are no configurable items for the features. But, many OpenSim capable viewers support extended use of the simulator features to pass other parameters that the viewer can use to dynamically refresh values needed to properly operate components for the grid containing the region. This is particularly useful for Hypergrid since several viewer components receive parameters upon login and are specific to that grid. Unless the parameters are dynamically refreshed, the components will not work when visiting new grids. We pass the parameters inside a data structure named "OpenSimExtras" along with the simulator features.

== Configuration ==
The region sends this data to the viewer, and we support the setting of these extras in the configuration of the simulator. But, we use the Robust GridService to push default values to the regions when they startup. The values we send are identical to the parameters we send in our home grid's login service when the user logs into the grid.
=== Robust ===
We currently (dev-master hash/commit time b4c6e23-1407353915 forward) support the configuration of several parameters via the Robust ini.
<source lang=ini>
[GridService]
; Support viewer export of content
ExportSupported = true

[LoginService]

; Grid Search service url
SearchURL = "url to search service"

; Grid Map Service
MapTileURL = "http://127.0.0.1:8002"

; Grid destination guide url
DestinationGuide = "url to destination guide (grid favorite locations)"
</source>

=== OpenSim ===

OpenSimExtras are configured in several places through the code and the best way to track them is to search for modules that watch the OnSimulatorFeaturesRequest event. We support the override of the grid defaults in the SimulatorFeaturesModule, but the defaults should be set at the grid level to ensure that the services required to operate the viewer components will be correct when users login or enter regions via Hypergrid.

<source lang=ini>
[SimulatorFeatures]

; Grid search service url
SearchServerURI = "url to grid search service"

; Grid destination guide url
DestinationGuideURI = "url to grid search service"

; Grid map service url
;(this may be set in one of several other locations, but we can use this to be consistent)
MapTileURL = "url to grid map service"

</source>

Extra information sent to the viewer over the SimulatorFeatures capability:

The OpenSimulator specific proportion of this is as follows (TODO: Really need to document the surrounding SimulatorFeatures structure as well!).

OpenSimExtras (OSDMap)
map-server-url (string)
search-server-url (string)
destination-guide-url (string)
ExportSupported (Boolean)
say-range (integer)
whisper-range (integer)
shout-range (integer)

Any of these is optional -- it may or may not be sent by the simulators. The entire map OpenSimExtras may or may not be present.

Portions of this are available in OpenSimulator 0.7.6 onward. Grid support is only available from dev-master hash/commit time b4c6e23-1407353915 onward.

SimulatorFeatures

2014-08-06T21:11:22Z

BlueWall:

= SimulatorFeaturesModule =
from dev-master hash/commit time b4c6e23-1407353915
== Overview ==
The SimulatorFeaturesModule is the mechanism used to inform the viewer about a region's ability to handle mesh model objects. This information is sent when the presence is created in the region so the viewer will be able to determine the region's mesh capabilities. There are no configurable items for the features. But, many OpenSim capable viewers support extended use of the simulator features to pass other parameters that the viewer can use to dynamically refresh values needed to properly operate components for the grid containing the region. This is particularly useful for Hypergrid since several viewer components receive parameters upon login and are specific to that grid. Unless the parameters are dynamically refreshed, the components will not work when visiting new grids. We pass the parameters inside a data structure named "OpenSimExtras" along with the simulator features.

== Configuration ==
The region sends this data to the viewer, and we support the setting of these extras in the configuration of the simulator. But, we use the Robust GridService to push default values to the regions when they startup. The values we send are identical to the parameters we send in our home grid's login service when the user logs into the grid.
=== Robust ===
We currently (dev-master hash/commit time b4c6e23-1407353915 forward) support the configuration of several parameters via the Robust ini.
<source lang=ini>
[GridService]
ExportSupported = true

[LoginService]

; Grid Search service url
SearchURL = "url to search service"

; Grid Map Service
MapTileURL = "http://127.0.0.1:8002"

; Grid destination guide url
DestinationGuide = "url to destination guide (grid favorite locations)"
</source>

=== OpenSim ===

OpenSimExtras are configured in several places through the code and the best way to track them is to search for modules that watch the OnSimulatorFeaturesRequest event. We support the override of the grid defaults in the SimulatorFeaturesModule, but the defaults should be set at the grid level to ensure that the services required to operate the viewer components will be correct when users login or enter regions via Hypergrid.

<source lang=ini>
[SimulatorFeatures]

; Grid search service url
SearchServerURI = "url to grid search service"

; Grid destination guide url
DestinationGuideURI = "url to grid search service"

; Grid map service url
;(this may be set in one of several other locations, but we can use this to be consistent)
MapTileURL = "url to grid map service"

</source>

Extra information sent to the viewer over the SimulatorFeatures capability:

The OpenSimulator specific proportion of this is as follows (TODO: Really need to document the surrounding SimulatorFeatures structure as well!).

OpenSimExtras (OSDMap)
map-server-url (string)
search-server-url (string)
destination-guide-url (string)
ExportSupported (Boolean)
say-range (integer)
whisper-range (integer)
shout-range (integer)

Any of these is optional -- it may or may not be sent by the simulators. The entire map OpenSimExtras may or may not be present.

Portions of this are available in OpenSimulator 0.7.6 onward. Grid support is only available from dev-master hash/commit time b4c6e23-1407353915 onward.

GridService

2014-08-06T19:03:26Z

BlueWall: /* API */

= Introduction =

The grid service manages information about regions on the grid. Some of the API is a little odd - this is a legacy of its original undocumented private-only use.

This service should only be accessible from the LAN.

= API =
Functions available on the grid service are

* register - registers a region with the grid.
* deregister - deregisters a region from the grid.
* get_neighbours - gets the region neighbours of a given location.
* get_region_by_uuid - returns region details given a region UUID.
* get_region_by_position - returns region details given a position.
* get_region_by_name - returns region details given a name. This will only return the first name if there are multiple regions with the same name.
* get_regions_by_name - returns details of all regions that match a given name
* get_region_range - returns details of all regions in a given area
* get_default_regions - returns default regions for a grid. These are regions that are tried in order if the requested login region does not exist.
* get_default_hypergrid_regions - returns default Hypergrid regions for a grid. These are regions that are tried in order if Hypergrid destination request by an inbound foreign user does not exist.
* get_fallback_regions - returns fallback regions for a grid. These are regions that are tried in order if no default regions are online.
* get_hyperlinks - get linked Hypergrid regions.
* get_region_flags - get flags for a region.
* get_grid_extra_features - get default extra features see: [[SimulatorFeatures Extras]]

== Formats ==
=== Region ===

This has the format

<region0 type="List">
<uuid>dd5b77f8-bf88-45ac-aace-35bd76426c81</uuid>
<locX>256000</locX>
<locY>256000</locY>
<sizeX>256</sizeX>
<sizeY>256</sizeY>
<regionName>test</regionName>
<serverIP>192.168.1.2</serverIP>
<serverHttpPort>9000</serverHttpPort>
<serverURI>http://192.168.1.2:9000/</serverURI>
<serverPort>9000</serverPort>
<regionMapTexture>fc8fda13-c2e9-4e83-8543-b7fe98231399</regionMapTexture>
<parcelMapTexture>00000000-0000-0000-0000-000000000000</parcelMapTexture>
<access>13</access>
<regionSecret>0ab0a97d-ffcc-4b29-a715-74372b763b88</regionSecret>
<owner_uuid>f2f493c0-27d3-4cf2-be97-b44dfdad13b6</owner_uuid>
<Token/>
</region0>

where

* '''uuid''' uuid of the region
* '''locX''' X location of the south-west corner of the region. Please note that this is in meters, not map tiles (each 256m). So a location of 256000 corresponds to a map tile at 1000.
* '''locY''' Y location of the south-west corner of the region. Please note that this is in meters, not map tiles (each 256m).
* '''sizeX''' X dimension size of the region in meters.
* '''sizeY''' Y dimension size of the region in meters.
* '''regionName''' name of the region
* '''serverIP''' IP address of the region passed to clients.
* '''serverHttpPort''' HTTP port of the region as passed to clients.
* '''serverURI''' URI of the region.
* '''serverPort''' UDP port of the region as passed to clients.
* '''regionMapTexture''' map texture of the region as stored in the asset service.
* '''parcelMapTexture''' parcel map of the region as stored in the asset database.
* '''access''' mainly signals avatar maturity level required for access. Possible values (not all of which are used by core OpenSimulator) are
** Unknown = 0, Unknown or invalid access level
** Trial = 7, Trial accounts allowed
** PG = 13, PG rating. This is the default value to allow access by all avatars.
** Mature = 21, Mature rating.
** Adult = 42, Adult rating.
** Down = 254, Simulator is offline.
** NonExistent = 255, Simulator does not exist.
* '''regionSecret''', currently unused.
* '''owner_uuid''', UUID of estate user that owns the region.

== Calls ==

=== get_region_by_name ===
This gets information on the region with the given name.

The POST field is a urlencoded string like so

SCOPEID=00000000-0000-0000-0000-000000000000&NAME=test&METHOD=get_region_by_name

where

* '''SCOPEID''' must always be present and always 00000000-0000-0000-0000-000000000000 (UUID.Zero) at the present time.
* '''NAME''' is the name of the region to get.

If there is a region with the corresponding name, a response is sent like

<source lang='xml'>
<?xml version="1.0"?>
<ServerResponse>
<result type="List">
<uuid>dd5b77f8-bf88-45ac-aace-35bd76426c81</uuid>
<locX>256000</locX>
<locY>256000</locY>
<sizeX>256</sizeX>
<sizeY>256</sizeY>
<regionName>test</regionName>
<serverIP>192.168.1.2</serverIP>
<serverHttpPort>9000</serverHttpPort>
<serverURI>http://192.168.1.2:9000/</serverURI>
<serverPort>9000</serverPort>
<regionMapTexture>fc8fda13-c2e9-4e83-8543-b7fe98231399</regionMapTexture>
<parcelMapTexture>00000000-0000-0000-0000-000000000000</parcelMapTexture>
<access>13</access>
<regionSecret>0ab0a97d-ffcc-4b29-a715-74372b763b88</regionSecret>
<owner_uuid>f2f493c0-27d3-4cf2-be97-b44dfdad13b6</owner_uuid>
<Token/>
</result>
</ServerResponse>
</source>

If there is more than one region with the same name (not allowed in OpenSimulator by default), then the first matching region only is returned.

If no matching region is found then the response is

<source lang='xml'>
<?xml version="1.0"?>
<ServerResponse>
<result>null</result>
</ServerResponse>
</source>

=== get_region_by_uuid ===
This gets information on the region with the given UUID.

The POST field is a urlencoded string like so

SCOPEID=00000000-0000-0000-0000-000000000000&REGIONID=dd5b77f8-bf88-45ac-aace-35bd76426c81&METHOD=get_region_by_uuid

where

* '''SCOPEID''' must always be present and always 00000000-0000-0000-0000-000000000000 (UUID.Zero) at the present time.
* '''REGIONID''' is the UUID of region to get.

If there are any regions in the range, a response like

<source lang='xml'>
<?xml version="1.0"?>
<ServerResponse>
<result type="List">
<uuid>dd5b77f8-bf88-45ac-aace-35bd76426c81</uuid>
<locX>256000</locX>
<locY>256000</locY>
<sizeX>256</sizeX>
<sizeY>256</sizeY>
<regionName>test</regionName>
<serverIP>192.168.1.2</serverIP>
<serverHttpPort>9000</serverHttpPort>
<serverURI>http://192.168.1.2:9000/</serverURI>
<serverPort>9000</serverPort>
<regionMapTexture>fc8fda13-c2e9-4e83-8543-b7fe98231399</regionMapTexture>
<parcelMapTexture>00000000-0000-0000-0000-000000000000</parcelMapTexture>
<access>13</access>
<regionSecret>0ab0a97d-ffcc-4b29-a715-74372b763b88</regionSecret>
<owner_uuid>f2f493c0-27d3-4cf2-be97-b44dfdad13b6</owner_uuid>
<Token/>
</result>
</ServerResponse>
</source>

If no matching regions are found then

<source lang='xml'>
<?xml version="1.0"?>
<ServerResponse>
<result>null</result>
</ServerResponse>
</source>

will be returned.

=== get_region_flags ===
This get information on the flags of a region (yes, this should really just be included in get_region_range).

The POST field is a urlencoded string like so

SCOPEID=00000000-0000-0000-0000-000000000000&REGIONID=dd5b77f8-bf88-45ac-aace-35bd76426c81&METHOD=get_region_flags

where

* '''SCOPEID''' must always be present and always 00000000-0000-0000-0000-000000000000 (UUID.Zero) at the present time.
* '''REGIONID''' is the UUID of region to query for flags.

If the region exists, a response like

<source lang='xml'>
<?xml version="1.0"?>
<ServerResponse>
<result>7</result>
</ServerResponse>
</source>

will be received. The result corresponds to bit flags

* DefaultRegion = 1, // Used for new Rez. Random if multiple defined
* FallbackRegion = 2, // Regions we redirect to when the destination is down
* RegionOnline = 4, // Set when a region comes online, unset when it unregisters and DeleteOnUnregister is false
* NoDirectLogin = 8, // Region unavailable for direct logins (by name)
* Persistent = 16, // Don't remove on unregister
* LockedOut = 32, // Don't allow registration
* NoMove = 64, // Don't allow moving this region
* Reservation = 128, // This is an inactive reservation
* Authenticate = 256, // Require authentication
* Hyperlink = 512, // Record represents a HG link
* DefaultHGRegion = 1024 // Record represents a default region for hypergrid teleports only.

If no region with the given ID is found, then the response is

<source lang='xml'>
<?xml version="1.0"?>
<ServerResponse>
<result>-1</result>
</ServerResponse>
</source>

=== get_region_range ===
This gets information on all the regions in a given co-ordinate range.

The POST field is a urlencoded string like so

SCOPEID=00000000-0000-0000-0000-000000000000&XMIN=0&YMIN=0&XMAX=2147483647&YMAX=2147483647&METHOD=get_region_range

where

* '''SCOPEID''' must always be present and always 00000000-0000-0000-0000-000000000000 (UUID.Zero) at the present time.
* '''XMIN''' The minimum x-coordinate in the region range. Please note that this is in meters, not 256m map tiles. This must be in the range 0 - 2147483647. So to start this at map tile co-ordinate 1000, one must specify 256000 (1000 * 256).
* '''YMIN''' The minimum u-coordinate in the region range. Please note that this is in meters, not 256m map tiles. This must be in the range 0 - 2147483647.
* '''XMAX''' The maximum x-coordinate in the region range. Please note that this is in meters, not 256m map tiles. This must be in the range 0 - 2147483647.
* '''XMIN''' The maximum y-coordinate in the region range. Please note that this is in meters, not 256m map tiles. This must be in the range 0 - 2147483647.

If there are any regions in the range, a response like

<source lang='xml'>
<?xml version="1.0"?>
<ServerResponse>
<region0 type="List">
<uuid>dd5b77f8-bf88-45ac-aace-35bd76426c81</uuid>
<locX>256000</locX>
<locY>256000</locY>
<sizeX>256</sizeX>
<sizeY>256</sizeY>
<regionName>test</regionName>
<serverIP>192.168.1.2</serverIP>
<serverHttpPort>9000</serverHttpPort>
<serverURI>http://192.168.1.2:9000/</serverURI>
<serverPort>9000</serverPort>
<regionMapTexture>fc8fda13-c2e9-4e83-8543-b7fe98231399</regionMapTexture>
<parcelMapTexture>00000000-0000-0000-0000-000000000000</parcelMapTexture>
<access>13</access>
<regionSecret>0ab0a97d-ffcc-4b29-a715-74372b763b88</regionSecret>
<owner_uuid>f2f493c0-27d3-4cf2-be97-b44dfdad13b6</owner_uuid>
<Token/>
</region0>
<region1 type="List">
<uuid>dd5b77f8-bf88-45ac-aace-35bd76426c82</uuid>
<locX>256000</locX>
<locY>256256</locY>
<sizeX>256</sizeX>
<sizeY>256</sizeY>
<regionName>test2</regionName>
<serverIP>192.168.1.2</serverIP>
<serverHttpPort>9000</serverHttpPort>
<serverURI>http://192.168.1.2:9000/</serverURI>
<serverPort>9001</serverPort>
<regionMapTexture>e8c14947-c7d2-48e8-bab2-5a62ec4da4d8</regionMapTexture>
<parcelMapTexture>00000000-0000-0000-0000-000000000000</parcelMapTexture>
<access>13</access>
<regionSecret>273b84ff-bfe1-480b-901b-c6e4bcd3e091</regionSecret>
<owner_uuid>f2f493c0-27d3-4cf2-be97-b44dfdad13b6</owner_uuid>
<Token/>
</region1>
</ServerResponse>
</source>

If no matching regions are found then

<source lang='xml'>
<?xml version="1.0"?>
<ServerResponse>
<result>null</result>
</ServerResponse>
</source>

will be returned.

==== Notes ====
You can get information on all the regions in a grid by specifying 0,0 min values and 2147483647,2147483647 max values.

SimulatorFeatures

2014-08-04T00:46:27Z

BlueWall:

Extra information sent to the viewer over the SimulatorFeatures capability:

The OpenSimulator specific proportion of this is as follows (TODO: Really need to document the surrounding SimulatorFeatures structure as well!).

OpenSimExtras (OSDMap)
map-server-url (string)
search-server-url (string)
destination-guide-url (string)
ExportSupported (Boolean)
say-range (integer)
whisper-range (integer)
shout-range (integer)

Any of these is optional -- it may or may not be sent by the simulators. The entire map OpenSimExtras may or may not be present.

This is only available in OpenSimulator 0.7.6 onwards.

Some of the parameters may be configured at the grid level so regions will be handed default values on startup. The region configuration has the option to override the defaults and set values for parameters in various modules.

Please watch this page for details

SimulatorFeatures

2014-08-04T00:40:53Z

BlueWall:

UserProfiles

2013-11-28T13:43:45Z

BlueWall: /* Configure Standalone Service */

=Introduction=
OpenSimulator 0.7.6 and onwards ship with built-in user profiles support. This will support the dialog-based user profiles seen in Singularity and similar third-party viewers, but not the purely web-based profiles seen in other viewers

At this time, there are issues with using this in a standalone system.

Before OpenSimulator 0.7.6, user profiles was supported using an externally added module. See [[Profile]] for more information.

=Enabling=
Enabling the built-in user profiles support requires

# Configuration in Robust.ini or Robust.HG.ini as appropriate.
# Configuration in OpenSim.ini

==Configuration in Robust.ini or Robust.HG.ini==
The user profiles service needs to be enabled and the connector set up so that the appropriate JSON RPC methods are available to simulators.

=== Enable service ===
This requires a UserProfilesService section. You should be able to use the one from Robust.ini.example (or Robust.HG.ini.example) with Enabled = true. For instance

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = true
;; Configure this for separate profiles database
;; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=*****;Old Guids=true;"
;; Realm = UserProfiles
UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

If it is desired to provide a separate database for the user profile data, then remove the leading ';' from ConnectionString and Realm, providing the needed values to connect the service to your data source. The data source must be created and configured for access before use.

=== Enable connector ===
In the [ServiceList] section of Robust.ini or Robust.HG.ini, this requires the connector to be set up on a port that is available to the simulators (and only the simulators). Usually, this would be the same private port on which other grid-only services are exposed. For instance

<pre>
[ServiceList]
UserProfilesServiceConnector = "8002/OpenSim.Server.Handlers.dll:UserProfilesConnector"
</pre>

=== Publish Profile Server URI for HyperGrid ===
The [LoginService] section of the Robust.HG.ini file needs the connection details for the Profile Service so that foreign users will be able to view the profile of your users when they travel to other grids via HyperGrid. Set the value of SRV_ProfileServerURI to the URI your Profile Service is configured to use. See the following for example.

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

== Configure Standalone Service ==
Configuring the Standalone simulator to make the built-in Profile Service available is accomplished by editing the StandaloneCommon.ini file in the bin/config-include directory.

=== Enable service ===
Find the [UserProfileService] section in your StandaloneCommon.ini and make the necessary changes for your site

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = true

;; Configure this for separate databse
; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=***;Old Guids=true;"
; Realm = UserProfiles

UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

The preceding example will enable the UserProfiles service using the main database for the profile tables. If a separate database is desired for the profiles data, remove the leading ';' from the ConnectionString and Realm entries. Provide the correct values to the ConnectionString for your profiles database.. The data source must be created and configured for access before use.

=== Publish Profile Server URI for HyperGrid ===
If the Standalone is configured for HyperGrid operation, then the profile service URL will need to be published to allow foreign users to view your user's profiles when they travel to other grids. This is accomplished by setting the value of the SRV_ProfileServerURI which is found under the [LoginService] section in the StandaloneCommon.ini. For example

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

==Configuration in OpenSim.ini==
Here, there needs to be a [UserProfiles] section with a ProfileServiceURL set that the simulator can reach (not the viewer). For instance, if your ROBUST services and simulator are on the same LAN and your ROBUST services are running on a machine with IP address 192.168.1.3, then this setting would be

<pre>
[UserProfiles]
ProfileServiceURL = http://192.168.1.3:8002
</pre>

See OpenSim.ini.example for more details.

UserProfiles

2013-11-28T13:42:24Z

BlueWall: /* Enable service */

=Introduction=
OpenSimulator 0.7.6 and onwards ship with built-in user profiles support. This will support the dialog-based user profiles seen in Singularity and similar third-party viewers, but not the purely web-based profiles seen in other viewers

At this time, there are issues with using this in a standalone system.

Before OpenSimulator 0.7.6, user profiles was supported using an externally added module. See [[Profile]] for more information.

=Enabling=
Enabling the built-in user profiles support requires

# Configuration in Robust.ini or Robust.HG.ini as appropriate.
# Configuration in OpenSim.ini

==Configuration in Robust.ini or Robust.HG.ini==
The user profiles service needs to be enabled and the connector set up so that the appropriate JSON RPC methods are available to simulators.

=== Enable service ===
This requires a UserProfilesService section. You should be able to use the one from Robust.ini.example (or Robust.HG.ini.example) with Enabled = true. For instance

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = true
;; Configure this for separate profiles database
;; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=*****;Old Guids=true;"
;; Realm = UserProfiles
UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

If it is desired to provide a separate database for the user profile data, then remove the leading ';' from ConnectionString and Realm, providing the needed values to connect the service to your data source. The data source must be created and configured for access before use.

=== Enable connector ===
In the [ServiceList] section of Robust.ini or Robust.HG.ini, this requires the connector to be set up on a port that is available to the simulators (and only the simulators). Usually, this would be the same private port on which other grid-only services are exposed. For instance

<pre>
[ServiceList]
UserProfilesServiceConnector = "8002/OpenSim.Server.Handlers.dll:UserProfilesConnector"
</pre>

=== Publish Profile Server URI for HyperGrid ===
The [LoginService] section of the Robust.HG.ini file needs the connection details for the Profile Service so that foreign users will be able to view the profile of your users when they travel to other grids via HyperGrid. Set the value of SRV_ProfileServerURI to the URI your Profile Service is configured to use. See the following for example.

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

== Configure Standalone Service ==
Configuring the Standalone simulator to make the built-in Profile Service available is accomplished by editing the StandaloneCommon.ini file in the bin/config-include directory and the OpenSim.ini file in the bin directory.

=== Enable service ===
Find the [UserProfileService] section in your StandaloneCommon.ini and make the necessary changes for your site

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = true

;; Configure this for separate databse
; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=***;Old Guids=true;"
; Realm = UserProfiles

UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

The preceding example will enable the UserProfiles service using the main database for the profile tables. If a separate database is desired for the profiles data, remove the leading ';' from the ConnectionString and Realm entries. Provide the correct values to the ConnectionString for your profiles database.. The data source must be created and configured for access before use.

=== Publish Profile Server URI for HyperGrid ===
If the Standalone is configured for HyperGrid operation, then the profile service URL will need to be published to allow foreign users to view your user's profiles when they travel to other grids. This is accomplished by setting the value of the SRV_ProfileServerURI which is found under the [LoginService] section in the StandaloneCommon.ini. For example

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

==Configuration in OpenSim.ini==
Here, there needs to be a [UserProfiles] section with a ProfileServiceURL set that the simulator can reach (not the viewer). For instance, if your ROBUST services and simulator are on the same LAN and your ROBUST services are running on a machine with IP address 192.168.1.3, then this setting would be

<pre>
[UserProfiles]
ProfileServiceURL = http://192.168.1.3:8002
</pre>

See OpenSim.ini.example for more details.

UserProfiles

2013-11-28T13:42:03Z

BlueWall: /* Enable service */

=Introduction=
OpenSimulator 0.7.6 and onwards ship with built-in user profiles support. This will support the dialog-based user profiles seen in Singularity and similar third-party viewers, but not the purely web-based profiles seen in other viewers

At this time, there are issues with using this in a standalone system.

Before OpenSimulator 0.7.6, user profiles was supported using an externally added module. See [[Profile]] for more information.

=Enabling=
Enabling the built-in user profiles support requires

# Configuration in Robust.ini or Robust.HG.ini as appropriate.
# Configuration in OpenSim.ini

==Configuration in Robust.ini or Robust.HG.ini==
The user profiles service needs to be enabled and the connector set up so that the appropriate JSON RPC methods are available to simulators.

=== Enable service ===
This requires a UserProfilesService section. You should be able to use the one from Robust.ini.example (or Robust.HG.ini.example) with Enabled = true. For instance

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = true
;; Configure this for separate profiles database
;; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=*****;Old Guids=true;"
;; Realm = UserProfiles
UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

If it is desired to provide a separate database for the user profile data, then remove the leading ';' from ConnectionString and Realm, providing the needed values to connect the service to your data source. The data source must be created and configured for access before use.

=== Enable connector ===
In the [ServiceList] section of Robust.ini or Robust.HG.ini, this requires the connector to be set up on a port that is available to the simulators (and only the simulators). Usually, this would be the same private port on which other grid-only services are exposed. For instance

<pre>
[ServiceList]
UserProfilesServiceConnector = "8002/OpenSim.Server.Handlers.dll:UserProfilesConnector"
</pre>

=== Publish Profile Server URI for HyperGrid ===
The [LoginService] section of the Robust.HG.ini file needs the connection details for the Profile Service so that foreign users will be able to view the profile of your users when they travel to other grids via HyperGrid. Set the value of SRV_ProfileServerURI to the URI your Profile Service is configured to use. See the following for example.

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

== Configure Standalone Service ==
Configuring the Standalone simulator to make the built-in Profile Service available is accomplished by editing the StandaloneCommon.ini file in the bin/config-include directory and the OpenSim.ini file in the bin directory.

=== Enable service ===
Find the [UserProfileService] section in your StandaloneCommon.ini and make the necessary changes for your site

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = true

;; Configure this for separate databse
; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=***;Old Guids=true;"
; Realm = UserProfiles

UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

The preceding example will enable the UserProfiles service using the main database for the profile tables. If a separate database is desired for the profiles data, remove the leading ';' from the ConnectionString and Realm entries. Provide the correct values to the ConnectionString for your profiles database.

=== Publish Profile Server URI for HyperGrid ===
If the Standalone is configured for HyperGrid operation, then the profile service URL will need to be published to allow foreign users to view your user's profiles when they travel to other grids. This is accomplished by setting the value of the SRV_ProfileServerURI which is found under the [LoginService] section in the StandaloneCommon.ini. For example

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

==Configuration in OpenSim.ini==
Here, there needs to be a [UserProfiles] section with a ProfileServiceURL set that the simulator can reach (not the viewer). For instance, if your ROBUST services and simulator are on the same LAN and your ROBUST services are running on a machine with IP address 192.168.1.3, then this setting would be

<pre>
[UserProfiles]
ProfileServiceURL = http://192.168.1.3:8002
</pre>

See OpenSim.ini.example for more details.

UserProfiles

2013-11-28T13:38:17Z

BlueWall: /* Enable service */

=Introduction=
OpenSimulator 0.7.6 and onwards ship with built-in user profiles support. This will support the dialog-based user profiles seen in Singularity and similar third-party viewers, but not the purely web-based profiles seen in other viewers

At this time, there are issues with using this in a standalone system.

Before OpenSimulator 0.7.6, user profiles was supported using an externally added module. See [[Profile]] for more information.

=Enabling=
Enabling the built-in user profiles support requires

# Configuration in Robust.ini or Robust.HG.ini as appropriate.
# Configuration in OpenSim.ini

==Configuration in Robust.ini or Robust.HG.ini==
The user profiles service needs to be enabled and the connector set up so that the appropriate JSON RPC methods are available to simulators.

=== Enable service ===
This requires a UserProfilesService section. You should be able to use the one from Robust.ini.example (or Robust.HG.ini.example) with Enabled = true. For instance

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = true
;; Configure this for separate profiles database
;; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=*****;Old Guids=true;"
;; Realm = UserProfiles
UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

=== Enable connector ===
In the [ServiceList] section of Robust.ini or Robust.HG.ini, this requires the connector to be set up on a port that is available to the simulators (and only the simulators). Usually, this would be the same private port on which other grid-only services are exposed. For instance

<pre>
[ServiceList]
UserProfilesServiceConnector = "8002/OpenSim.Server.Handlers.dll:UserProfilesConnector"
</pre>

=== Publish Profile Server URI for HyperGrid ===
The [LoginService] section of the Robust.HG.ini file needs the connection details for the Profile Service so that foreign users will be able to view the profile of your users when they travel to other grids via HyperGrid. Set the value of SRV_ProfileServerURI to the URI your Profile Service is configured to use. See the following for example.

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

== Configure Standalone Service ==
Configuring the Standalone simulator to make the built-in Profile Service available is accomplished by editing the StandaloneCommon.ini file in the bin/config-include directory and the OpenSim.ini file in the bin directory.

=== Enable service ===
Find the [UserProfileService] section in your StandaloneCommon.ini and make the necessary changes for your site

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = true

;; Configure this for separate databse
; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=***;Old Guids=true;"
; Realm = UserProfiles

UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

The preceding example will enable the UserProfiles service using the main database for the profile tables. If a separate database is desired for the profiles data, remove the leading ';' from the ConnectionString and Realm entries. Provide the correct values to the ConnectionString for your profiles database.

=== Publish Profile Server URI for HyperGrid ===
If the Standalone is configured for HyperGrid operation, then the profile service URL will need to be published to allow foreign users to view your user's profiles when they travel to other grids. This is accomplished by setting the value of the SRV_ProfileServerURI which is found under the [LoginService] section in the StandaloneCommon.ini. For example

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

==Configuration in OpenSim.ini==
Here, there needs to be a [UserProfiles] section with a ProfileServiceURL set that the simulator can reach (not the viewer). For instance, if your ROBUST services and simulator are on the same LAN and your ROBUST services are running on a machine with IP address 192.168.1.3, then this setting would be

<pre>
[UserProfiles]
ProfileServiceURL = http://192.168.1.3:8002
</pre>

See OpenSim.ini.example for more details.

UserProfiles

2013-11-28T13:37:38Z

BlueWall: /* Configuration in Robust.ini or Robust.HG.ini */

=Introduction=
OpenSimulator 0.7.6 and onwards ship with built-in user profiles support. This will support the dialog-based user profiles seen in Singularity and similar third-party viewers, but not the purely web-based profiles seen in other viewers

At this time, there are issues with using this in a standalone system.

Before OpenSimulator 0.7.6, user profiles was supported using an externally added module. See [[Profile]] for more information.

=Enabling=
Enabling the built-in user profiles support requires

# Configuration in Robust.ini or Robust.HG.ini as appropriate.
# Configuration in OpenSim.ini

==Configuration in Robust.ini or Robust.HG.ini==
The user profiles service needs to be enabled and the connector set up so that the appropriate JSON RPC methods are available to simulators.

=== Enable service ===
This requires a UserProfilesService section. You should be able to use the one from Robust.ini.example (or Robust.HG.ini.example) with Enabled = true. For instance

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = false
;; Configure this for separate profiles database
;; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=*****;Old Guids=true;"
;; Realm = UserProfiles
UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

=== Enable connector ===
In the [ServiceList] section of Robust.ini or Robust.HG.ini, this requires the connector to be set up on a port that is available to the simulators (and only the simulators). Usually, this would be the same private port on which other grid-only services are exposed. For instance

<pre>
[ServiceList]
UserProfilesServiceConnector = "8002/OpenSim.Server.Handlers.dll:UserProfilesConnector"
</pre>

=== Publish Profile Server URI for HyperGrid ===
The [LoginService] section of the Robust.HG.ini file needs the connection details for the Profile Service so that foreign users will be able to view the profile of your users when they travel to other grids via HyperGrid. Set the value of SRV_ProfileServerURI to the URI your Profile Service is configured to use. See the following for example.

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

== Configure Standalone Service ==
Configuring the Standalone simulator to make the built-in Profile Service available is accomplished by editing the StandaloneCommon.ini file in the bin/config-include directory and the OpenSim.ini file in the bin directory.

=== Enable service ===
Find the [UserProfileService] section in your StandaloneCommon.ini and make the necessary changes for your site

<pre>
[UserProfilesService]
LocalServiceModule = "OpenSim.Services.UserProfilesService.dll:UserProfilesService"
Enabled = true

;; Configure this for separate databse
; ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=***;Old Guids=true;"
; Realm = UserProfiles

UserAccountService = OpenSim.Services.UserAccountService.dll:UserAccountService
AuthenticationServiceModule = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService"
</pre>

The preceding example will enable the UserProfiles service using the main database for the profile tables. If a separate database is desired for the profiles data, remove the leading ';' from the ConnectionString and Realm entries. Provide the correct values to the ConnectionString for your profiles database.

=== Publish Profile Server URI for HyperGrid ===
If the Standalone is configured for HyperGrid operation, then the profile service URL will need to be published to allow foreign users to view your user's profiles when they travel to other grids. This is accomplished by setting the value of the SRV_ProfileServerURI which is found under the [LoginService] section in the StandaloneCommon.ini. For example

<pre>
[LoginService]
SRV_ProfileServerURI = http://example.com:8002
</pre>

==Configuration in OpenSim.ini==
Here, there needs to be a [UserProfiles] section with a ProfileServiceURL set that the simulator can reach (not the viewer). For instance, if your ROBUST services and simulator are on the same LAN and your ROBUST services are running on a machine with IP address 192.168.1.3, then this setting would be

<pre>
[UserProfiles]
ProfileServiceURL = http://192.168.1.3:8002
</pre>

See OpenSim.ini.example for more details.

File:AtlanticScaled.png

2013-05-24T04:53:12Z

BlueWall: test

test

RestConsole

2013-05-07T16:45:06Z

BlueWall:

{{Quicklinks}}
== About ==
The REST console makes remote administration of the various OpenSimulator services possible.

The interface allows sending commands to the server and retrieving command output. Sending and receiving data is done through RESTful HTTP calls.

While sending is very straightforward, receiving is not. Receiving uses reverse HTTP, performing a long poll to a CAPS URI.

In order to make the protocol more efficient, the help functionality has been pushed to the client side. Rather than sending each keystroke to the server, only validated command lines are sent. To make this possible, the server sends a burst-on-connect of data, which is the tree of allowed commands and their help information. This can be used by the client to create the "help" command output locally as well as provide command line help interactively.

The sample console client, OpenSim.ConsoleClient.exe, shows how this is done.

== Usage ==
In order to use the remote console, start up OpenSimulator services with parameter <tt>-console rest</tt>.

Example for Robust server in grid mode:
mono Robust.exe -console rest

Example for simulators (both in grid and standalone mode):
mono OpenSim.exe -console rest

== Syntax ==
We take the OpenSimulator services address <nowiki>http://foo.bar:8002</nowiki> as example here.

First start a new session by sending a HTTP POST request. User name and password should match the settings for <tt>ConsoleUser</tt> and <tt>ConsolePass</tt> in section <tt>[Network]</tt> of OpenSim.ini.<br />
Parameters: USER, PASS
<nowiki>http://foo.bar:8002/StartSession/</nowiki>
Return: (XML) <ConsoleSession><SessionID></SessionID><Prompt></Prompt></ConsoleSession>

Now we got the SessionID, which can be used to send a command and to receive output. First, retrieve the console scrollback buffer.<br />
Parameters: none
<nowiki>http://foo.bar:8002/ReadResponses/<SessionID>/</nowiki>
Return: (XML) <ConsoleSession><Line Number=x></Line></ConsoleSession><br />
The reply contains all lines currently in the buffer. Subsequent fetches will only retrieve new lines. The fetch will hold for up to 30 seconds if there is no data, then return an error. The client is expected to try again (polling).

Use the SessionID as ID parameter, and send a POST request again.<br />
Parameters: ID, COMMAND
<nowiki>http://foo.bar:8002/SessionCommand/</nowiki>
Return: (XML) <ConsoleSession><Result></Result></ConsoleSession><br />
If everything went well, the command should have been executed. Try another command.

When you want to close down the connection, send a POST request again.<br />
Parameters: ID
<nowiki>http://foo.bar:8002/CloseSession/</nowiki>
Return: (XML) <ConsoleSession><Result></Result></ConsoleSession><br />
The session is closed, and you have to log in again, when you want to send a command again.

== Examples ==

=== Python ===

#!/usr/bin/python
# This piece of code is published by thomax (txOh) (c) 2010 under the
# Artistic License 1.0 (http://www.perlfoundation.org/artistic_license_1_0)

import urllib, urllib2
import xml.dom.minidom

class UserConsoleClient():

def __init__(self, addr):
self.addr = addr
url = self.addr + 'StartSession/'

params = urllib.urlencode({
'USER': 'Test', # REST username
'PASS': 'secret' # REST password
})
data = urllib2.urlopen(url, params).read()

dom = xml.dom.minidom.parseString(data)
elem = dom.getElementsByTagName('SessionID')
self.sessionid = elem[0].childNodes[0].nodeValue

def close(self):
url = self.addr + 'CloseSession/'
params = urllib.urlencode({
'ID': self.sessionid
})
print urllib2.urlopen(url, params).read()

def do_cmd(self, cmd):
url = self.addr + '/SessionCommand/'
params = urllib.urlencode({
'ID': self.sessionid,
'COMMAND': cmd
})
print urllib2.urlopen(url, params).read()

def read_buffer(self):
url = self.addr + 'ReadResponses/' + self.sessionid + '/'
params = urllib.urlencode({
'ID': self.sessionid
})

print urllib2.urlopen(url, params).read()

# set the base url to the REST console (with port)
console = UserConsoleClient('<nowiki>http://127.0.0.1:8300/</nowiki>')
console.read_buffer()
print 'quit with a "."'
cmd = ""
while cmd != ".":
if cmd != "":
console.do_cmd(cmd)
console.read_buffer()
cmd = raw_input("> ")

console.close()

=== Python (Updated) ===

<source lang="python">
#!/usr/bin/python
# This piece of code is published by thomax (txOh) (c) 2010 under the
# Artistic License 1.0 (http://www.perlfoundation.org/artistic_license_1_0)
# Modifications (c) 2013 BlueWall

import urllib, urllib2
import xml.dom.minidom

class UserConsoleClient():

def __init__(self, addr):
self.addr = addr
url = self.addr + 'StartSession/'

params = urllib.urlencode({
'USER': 'username', # REST username
'PASS': 'userpass' # REST password
})
data = urllib2.urlopen(url, params).read()
print data

dom = xml.dom.minidom.parseString(data)
elem = dom.getElementsByTagName('SessionID')
self.sessionid = elem[0].childNodes[0].nodeValue
elem = dom.getElementsByTagName('Prompt')
self.prompt = elem[0].childNodes[0].nodeValue + '# '

def close(self):
url = self.addr + 'CloseSession/'
params = urllib.urlencode({
'ID': self.sessionid
})
print urllib2.urlopen(url, params).read()

def do_cmd(self, cmd):
url = self.addr + 'SessionCommand/'
params = urllib.urlencode({
'ID': self.sessionid,
'COMMAND': cmd
})
data = urllib2.urlopen(url, params).read()
dom = xml.dom.minidom.parseString(data)
elem = dom.getElementsByTagName('Result')
return elem[0].childNodes[0].nodeValue

def read_buffer(self):
url = self.addr + 'ReadResponses/' + self.sessionid + '/'
params = urllib.urlencode({
'ID': self.sessionid
})

# print urllib2.urlopen(url, params).read()

result = urllib2.urlopen(url, params).read()
dom = xml.dom.minidom.parseString(result)

elem = dom.getElementsByTagName('Line')
for line in elem:
x0 = line.childNodes[0].nodeValue
x1 = str.replace(str(x0),':','~',2)
x2 = x1.split("~")
for lv in x2[2:]:
if not '+++' in lv:
print lv

# set the base url to the REST console (with port)
console = UserConsoleClient('http://example.com:8003/')
console.read_buffer()
print 'quit with a "."'
cmd = ""
while cmd != ".":
if cmd != "":
if 'OK' in console.do_cmd(cmd):
console.read_buffer()
cmd = raw_input("%s " % console.prompt)

console.close()

</source>

=== JavaScript/HTML ===

<pre>
<html>
<head>




<script type="text/javascript">

var sessionId;
var hostUrl;

function StartSession(url, user, password) {
hostUrl = url;
var response = SendRequest("/StartSession/", "USER=" + user + "&PASS=" + password);
sessionId = response.getElementsByTagName("SessionID")[0].firstChild.nodeValue;
};

function ReadResponses() {
var response = this.SendRequest("/ReadResponses/" + sessionId + "/", '');
var lines = response.getElementsByTagName("Line");
for (var i = 0; i < lines.length; ++i) {
var element = document.createElement("div");
element.appendChild(document.createTextNode(lines[i].firstChild.nodeValue));
document.getElementById("output").appendChild(element);
};
document.getElementById("output").scrollTop = document.getElementById("output").scrollHeight;
};

function Command(cmd) {
void SendRequest("/SessionCommand/", "ID=" + sessionId + "&COMMAND=" + cmd);
};

function CloseSession() {
void SendRequest("/CloseSession/", "ID=" + sessionId);
};

function SendRequest(path, data) {
var request = new XMLHttpRequest();
request.open("POST", hostUrl + path, false);
request.send(data);
return request.responseXML;
};

window.onunload = CloseSession;

</script>
</head>
<body>

<form action="#" onsubmit="
StartSession(this.address.value, this.user.value, this.password.value);
ReadResponses();
return false">
<input name="address" type="text" value="http://localhost:9000" />
<input name="user" type="text" value="ConsoleUser" />
<input name="password" type="text" value="ConsolePass" />
<input type="submit" value="Login" />
</form>

<div id="output" style="height:15em; border:thin solid; overflow:auto;"></div>

<form action="#" onsubmit="
Command(this.command.value);
ReadResponses();
return false">
<input type="text" name="command" value="Enter command here" size="40"/>
<input type="submit" value="Send Command" />
</form>

</body>
</html>
</pre>

0.7.5 Release

2013-01-27T23:31:44Z

BlueWall: /* General Server */

=Release Notes=
== General ==
'''These release notes are in development. The current release candidate for 0.7.5 is RC2'''.

Welcome to OpenSimulator 0.7.5, an open-source multi-user 3D virtual environment server platform.

As ever, OpenSimulator is a highly complex piece of alpha software. It's very likely but not guaranteed to work and various usage scenarios (standalone, grid, hypergrid, etc.) in combination with different dependencies (e.g. different versions of mono on Linux/Mac) can produce unexpected or unstable behaviour. If it breaks you get to keep both pieces.

If you are upgrading from a version prior to 0.7.x, make sure to read the [[0.7 Release]] notes. There have been extensive changes in OpenSimulator from 0.6.x to 0.7.

When you are upgrading, 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.

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.

You can download this release of OpenSimulator from http://opensimulator.org/wiki/Download

== Known issues ==

* There is an occasional issue where other people will see you in the animation-less t-pose when you teleport between regions. This is being handled via http://opensimulator.org/mantis/view.php?id=6483
* 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 will be addressed before final release.
* 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 "#RLV/~gift" rather than just "~gift". This is being addressed in http://opensimulator.org/mantis/view.php?id=6311. Any help from viewer developers on this would be much appreciated, otherwise this regression may remain in the final 0.7.5 release.
* In a stock Linden Lab viewer 2/3, various tabs and buttons will point back to the Linden Lab website. In particular, the profile data will try to fetch from the Linden Lab website. It's not known currently how/whether this can be changed in the stock viewer.
* No form of prim equivalence is implemented for meshes.
* Loading scripts from the simulator library does not work properly.
* Multiple attachments on a single attachment point not supported.
* Bulletsim physics engine support is in an intermediate state in this release and may not work at all under Linux. This will not affect users since the Open Dynamics Engine (ODE) remains the default physics engine in-use on OpenSimulator.

== Requirements ==

OpenSimulator requires:

* .NET Framework 3.5 when running under Windows.
* At least Mono 2.4.3 when running under Mono (Linux or Mac). Mono 2.6.x and Mono 2.10.x onwards work well. Mono 2.8.x versions are reported as less stable in some situations. OpenSimulator will run under Mono 3.0.2 but physics instability has been reported (at least with the ODE plugin).

== Backwards Compatibility Notices ==

* This release includes database migrations but these should be backward compatible with OpenSimulator 0.7.3.1 (i.e. one could rollback to 0.7.3.1 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.
* Due to a libomv bug fix, teleports in this release are incompatible with OpenSimulator 0.7.0.2 and earlier. This affects primarily Hypergrid teleports, since simulators within the same grid tend to be all in the same version. Teleports to OpenSimulator 0.7.1 and later should work.

== Changes ==

=== General Server ===
* Default endpoint connection limit increased from 2 to 12, which will allow 12 simultaneous connections to an IP:Port combination rather than just 2. Experience suggests this will improve data fetching from ROBUST services. However, this change may not affect Mono installations [https://github.com/mono/mono/pull/472 due to a bug which may still be present in recent Mono releases]. Separately, the number of simultaneous allowed asset requests to a connection was raised to 30. This will affect both Mono and Windows.
* Added facility to log outgoing http data via the "debug http" console command.
* More levels added to the "debug http" command to allow logging of incoming POST data. This command can be useful to debug configuration problems.
* The "show http-handlers" command now shows HTTP handlers listening on every port of that server - not just the 'main' port.
* "help all" console command will now show all commands in the old big list style rather than initially in categories.
* Dynamic plugins (Robust). Subscribe to remote repositories and install plugins from them. Enable and disable the plugins on the fly. See: http://opensimulator.org/wiki/Feature_Proposals/PluginManager for further information.

=== General Simulator ===
* The long (+4 years) deprecated IRegionModule interfaces for region modules have now been entirely removed. You may need to convert to the newer INonSharedRegionModule/ISharedRegionModule interfaces but this is not too difficult.
* Region debug console implemented, as accessed via the ctrl + shift + ` (backtick) keyboard shortcut in recent viewers. Only estate owners and managers can access this. Typing help at the prompt will show currently available commands (currently only auto_grant_attach_perms for temporary attachments).
* UDP related memory use by client connections improved. This should reduce the amount of memory used by each client connection as so reduce rubberbanding under Mono on busy simulators as memory is garbage collected. However, the affect may be swamped if there are many active scripts. There is further scope for improvement in this area.
* HTTPGetTexture capability now properly handles a request with no second value in the range header (e.g. 5333- to fetch all bytes from 5333), rather than just complaining on the console. This operation is being done by the latest LL viewer code (3.4.4).

=== Configuration ===
* Nonphysical* Regions.ini configuration names for controlling prim dimensions have been renamed to more consistent NonPhysical* names (e.g. NonphysicalPrimMin -> NonPhysicalPrimMin).

=== Services ===
* The "show http-handlers" console command is now available for ROBUST as well as the simulator.
* Inbound HTTP connectors can now be specified one per line in the [Startup] section of Robust.ini rather than in one large block.
* The ROBUST asset service now returns a 400 (bad request) HTTP status if appropriate rather than simply dropping the request.
* "show uptime", "show info", "set log level", "show version", "config show/get/set/save", "show threads", "thread abort" and "force gc" commands now available on the ROBUST console as well as the simulator console.

=== Hypergrid ===
* For the items below, please see Diva Canto's [http://metaverseink.com/blog/?p=459 HG 2.0 blog post] for more details.
* Avatar appearance issues when using hypergrid 'suitcase' folder fixed.
* Attachment issues when visiting other grids via the Hypergrid fixed.
* Issue fixed where assets accessed from foreign sims did not tranport the full chain of assets necessary for rezzing (e.g. the textures referenced by an object inside the rezzed object).
* Visitor access control to regions improved.
* Hypergrid Instant Mesasge now accounts for an offline IM storage service if present.
* Default Hypergrid config now changed to 2.0 from 1.5. On upgrading you will need to checking your existing Hypergrid configuration against the updates in Robust.HG.ini.example or config-include/StandloneCommon.ini.example as appropriate.

=== Objects ===
* Undo steps for object changes are no longer stored without limit. This meant that over time, a simulator with changing objects would use more and more memory that would not be released. The MaxPrimsUndo limit in the [Startup] section of OpenSim.ini is now enforced. The default is 20 steps.
* Minimum allowed sizes for physical and non-physical prims can now be configured. See the [Startup] section of OpenSim.ini.example for more details.
* Corrupted child prim permissions can no longer make objects change permissions after they have been rezzed.
* ReuseDynamicTextures option improved to work around a bug where an attempt to reuse a very small dynamic texture would cause the viewer not to properly redisplay it when it was pulled from its cache.
* Further crash bugs with very heavy use of dynamic textures by scripts fixed.
* Linkset sizes can now be restirected via the LinksetPrims value in the [Startup] section of OpenSim.ini.
* Setting llVolumeDetect(FALSE) on an object where volume detect has been previous set will now correctly clear the phantom flag.
* "show object pos" console commands added. These show object information by position on the console and are meant for debugging.
* More information added to various "show object" console commands for diagnostic purposes.
* "delete object pos <start-coord> to <end-coord>" console command added. This can be useful to delete all objects in a given volume of space.
* "dump object id" console command added to dump object serialization for any region object by its local or UUID. For diagnostics.

=== Mesh/Sculpt ===
* Mesh/Sculpt loading reliability improved.

=== Avatars ===
* OpenSimulator 0.7.4 regression fixed where a logged out avatar could still sometimes be present in the connections list which would stop relog or visit of the scene until the simulator was restarted.
* Fixed OpenSimulator 0.7.4 and even earlier regression where objects attached directly from the region would often not show up as attached.
* [http://community.secondlife.com/t5/Featured-News/Advanced-Experience-Tools-Preview/ba-p/1420633 Temporary attachments] implemented. This is currently not well documented in OpenSimulator.
* Facility to periodically resend appearance UUIDs (ResendAppearanceUpdates setting in the [Appearance] section of OpenSimDefaults.ini) now set to true by default. This has been shown to help with grey avatar issues.
* Current animation is now retained by an avatar as it moves between regions, as long as both source and destination region are running this version of OpenSimulator or later.

=== Physics ===
* Many updates to bulletsim in the areas of collisions, fps calculation, floating, friction, linksets, materials, megaregions, mesh, pushing, region crossings, shapes, terrain, vehicles. However, this should still be considered experimental in this release.
* Movement of physical prims in ODE plugin improved.
* Teravus added an experimental plugin for the C# XNA port of the bullet physics engine. This is likely to be slower than the C++ version but may give better debugging information where necessary.

=== Sound ===

=== Parcels/Region/Estates ===
* Bug fixed where having more than 63 users in an estate's banlist would cause the viewer to crash when the estate dialog was opened.
* Bug fixed with SQLite plugin where some parcel settings (such as media settings) were not persisted.
* AllowRegionRestartFromClient [EstateManagement] config option added by which estate managers can be prevented from restarting regions (since this may still be unstable on current OpenSimulator, though fixes in this area have been implented0>

=== Map ===
* Map information lookups from viewers can no longer appear to freeze the scene if the map service is not responding quickly.

=== Instant Messaging ===

=== Friends ===

=== Archiving ===
* Group ownership now properly changed to none when objects are loaded from an OAR where the group UUID is not present on that simulator.
* Parcel access lists now properly reconstructed on OAR load.
* Loading OARs containing deeded land parcels will now properly preserve the group as the owner if the group UUID is accessible by that simulator.
* "save iar" console command no longer hangs the console permanently if an asset save times out.
* Experimental support for [[OAR Format 1.0|multi-region OAR files]] added. As the name suggests, these are OAR files that store more than one region in an OAR. This is controlled using the --all switch on the "save oar" console command - currently the default is still to save single regions. This should be considered experimental.

=== NPC ===
* Fixed some script crashing race conditions if one script removed an NPC whilst another was fetching its details.
* NPCs can now move within the entire area of a megaregion rather than being stuck in the 'root' 256x256m area.
* llRequestPermissions() calls now always succeed for unowned NPCs, where they only worked for appropriately owned NPCs before.

=== Inventory ===
* Fixed issue where newly created body parts and clothing sometimes did not appear in the user's inventory.
* Inventory folder versioning now much better implemented. This may cut down on excess requests by the viewer for inventory information as these were triggered by a mismatch between it's expected folder version numbers and those persisted by OpenSimulator. This may help with issues seen on OpenSimulator 0.7.4 where many requests for people with large inventories would lead to other region issues (see http://opensimulator.org/mantis/view.php?id=6412).
* Item properties that should never change (e.g. creator and owner) can no longer be updated. This should prevent and help identify bugs in this area as change attempts are logged. See http://opensimulator.org/mantis/view.php?id=6359 for more details.

=== Groups ===
* Group information requests can no longer hold up the main incoming packet processing loop, which could lead to apparently frozen regions if the groups service was slow to respond.

=== Monitoring ===
* OpenSimulator 0.7.4 regression fixed where viewer stats sent by viewers were no longer being recorded in the LocalUserStatistics.db if this faiclity was enabled.

=== Test ===
* pCampbot fixed to work under Windows.

=== Scripting ===
* Script runtime error messages now displayed by version 3 and related third party viewers.
* Static methods from region modules can now be registered for calling by scripts using the modInvoke facility.
* WaitForEventCompletionOnScriptStop option added to the [XEngine] configuration section of OpenSim.ini. This is to provide a way to examine an issue where thread aborts of scripts still executing events (e.g. when an object is derezzed) can sometimes cause Mono 2.6 amd 2.10 to crash badly, with symptoms such as 100% cpu use and threads waiting for locks which no other thread holds. Default for wait period is 1 second but this can be increased. Tradeoff is that 'rogue' scripts will take longer to stop. May be increased in the future, though the ultimate solution will have to completely avoid thread aborts.
* llResetOtherScript() now waits for the WaitForEventCompletionOnScriptStop timeout before forcibly aborting another script if it is still running an event. This is an effort to avoid the mono crash issues outlined above when this function is heavily used.
* llGetLinkKey() fixed to always return the avatar that last sat on an object if given the the last link number.
* llGetLinkName() fixed to always return the avatar name that last sat on an object if given the last link number.
* llRequestPermissions() now automatically gets granted appropriate permissions from avatars that are sat on an object other than the very first avatar to sit on that object.
* The attached event now correctly fires when an object is attached directly from the region.
* The money event now goes to the clicked prim rather than always the root prim of a linkset.
* llSetLinkCamera() implemented.
* Behaviour of llList2*() functions made to better match LL when converting input values.
* ATTACH_*_PEC constants added
* PRIM_LINK_TARGET implemented on llGetPrimitiveParams() and similar functions.
* PRIM_SLICE implemented for llSetPrimitiveParams() and similar functions.
* llPlaySound() fixed to play sounds from the prim the script is in rather than the root prim.
* llLoopSound() now continues playing in a child prim when a sound is played in the root prim.
* llPlaySound() now consistently stopped by llStopSound().
* llDialog() fixed so that a script can hear responses no matter where a user has moved to within the region, rather than only when they are within shout range.
* llListStatistics() no longer ignores the last element in some operations.
* llParticleSystem() default PSYS_SRC_BURST_PART_COUNT now properly 1 rather than 0.
* OpenSimulator 0.7.4 regression nfixed where the DATA_SIM_POS option on llRequestSimulatorData() would not return information on regions that were in the same simulator.
* Issue fixed with llListFindList() would not return a match if a script constant was used int he source list.
* llGetLinkName() fixed for LINK_THIS constant.
* CLICK_ACTION_ZOOM constant added.
* osGetHealth() added to return health information on an avatar where this is enabled.
* osSetContentType() added which allows setting of an arbitrary return type for an URL set up by llRequestUrl().
* osGetNumberOfAttachments() added to return the number of attachments given a list of attachment points.
* osMessageAttachments() added to allow a script to send a link message to an avatar's attachments.
* osDropAttachmentAt(), osForceDropAttachment() and osForceDropAttachmentAt() OSSL functions added.
* osListenRegex() function added which acts like llListen() but allows filtering by regular expression on name or message content of listen reports.

== Acknowledgements ==

Many, many thanks to all the developers, testers and community members who contributed to this release. Your hard work makes this all possible :)

[[Category:Release Notes]]

MediaWiki:Sidebar

2012-11-17T02:16:38Z

BlueWall:

OsSetProjectionParams

2012-10-25T19:20:14Z

BlueWall:

{{osslfunc
|threat_level=High
|function_syntax=void osSetProjectionParams(integer projection, key texture, float fov, float focus, float amb)<br />
void osSetProjectionParams(key prim, integer projection, key texture, float fov, float focus, float amb)
|ossl_example=This example will control the projection map in the host prim and another prim identified by it's uuid

<source lang="lsl">
integer pstate = FALSE;

// These variables correspond to the settings found in the
// "Features" tab of the build editor
float FOV = 1.5; // Values 0.00 - 3.00
float Focus = 15.0; // Values -20.00 - 20.00
float Ambiance = 0.4; // Values 0.00 - 1.00
key Texture = "b4c6b075-4940-4270-bb10-d293fd6f8091";

// UUID of other prim that we want to control
key Remote = "9772974a-a0f6-43ec-b1a2-da558b0b0d59";

default
{
state_entry()
{
llSay(0, "Script running");
llSetText((string)llGetKey(),<0.3,0.5,0.75>,1.0);
llSetPrimitiveParams([]);

// Light must be enabled in "Features"

// This one controls this prim...
osSetProjectionParams(pstate, Texture, FOV, Focus, Ambiance);
// This one controls the remote prim...
osSetProjectionParams(Remote, pstate, Texture, FOV, Focus, Ambiance);

}

touch_start(integer _det)
{

if (pstate == TRUE)
{
pstate = FALSE;
}
else
{
pstate = TRUE;
}

// Control this prim...
osSetProjectionParams(pstate, Texture, FOV, Focus, Ambiance);
// Control the remote prim...
osSetProjectionParams(Remote, pstate, Texture, FOV, Focus, Ambiance);
}
}
</source>
|description=2 Variations possible.
*bool = TRUE / FALSE.
*double = float.
|
}}

IntegrationService

2012-07-23T18:38:52Z

BlueWall:

{{proposal}}

{{ambox|type=notice|text=''' : Re-factoring in-Progress. See: http://opensimulator.org/wiki/Feature_Proposals/PluginManager'''}}

= IntegrationService =

== Basic Info ==

* '''Summary''': Integration Service is a Robust facility to provide management for running dynamic plugins used for extending connections into the grid from external applications.
* '''Developer Sponsor(s)''': BlueWall Information Technologies, LLC (BlueWall) jamesh@bluewallgroup.com / IRC - "BlueWall" on #opensim-dev, #opensim
* '''Start Date''': March 31, 2012
* '''Branches Targeted''': OpenSim master/development (after evaluation)
* '''Commercial''': Not specifically, but of general interest to adopters to help them integrate their external projects with OpenSimulator
* '''Code Repository''': OpenSimulator main repository in the "integration" branch and https://github.com/BlueWall/opensim/tree/integration

== High-Level Design ==

=== Idea ===

Integration Service for Robust is a facility to manage dynamic plugins, allowing external applications to be integrated with the OpenSimulator grid. The service helps the application developer provide clean APIs for their OpenSimulator integration projects by supplying a convenient framework to manage plugins that reside outside of OpenSimulator core. Their applications may be easily distributed across other sites without the need to interface directly to the underlying database structure. The developer has access to the OpenSimulator framework, including database migrations, easing maintenance tasks for users and administrators of their applications. This framework also opens the possibility for “crowd sourcing” standard APIs and libraries for applications such as web integration for popular CMS like Drupal, Joomla and Django and building API libraries for popular programming languages. These would offer a level of abstraction from the OpenSimulator core project to help minimize conflicts with external projects when core changes are needed. With the user-base migrating to V3 based viewers, which require lots of web applications which are tightly integrated into the grid, this type of service is desired to help stabilize APIs and insulate them from core development as much as posible.
The Integration Service provides the management facility and some utility services for the external plugins. Several console commands allow management of external repositories and manipulation of plugins. A detailed user-side view for getting started may be seen at: http://bluewallvirtual.com/integration_use . This details the configuration settings in the Robust.ini for the service and gives some instructions for connecting to the example repository.
At the moment, there is an implementation of the landtool.php using this, and an example for development. Some other basic plugins are in the development stages and will be released as they are completed.

=== Criteria ===

* '''Scope''': This is already fairly complete and working. It will be good to get more eyes on it and work out details for security and provide hooks for things like Oauth for allowing applications to integrate with external sites to provide rich user experiences with the V3 based viewers. Additional testing and work is required to make the system more reliable at detecting and suggesting upgrades and requirements between versions.

* '''Software Requirements''': Mono Addins was upgraded to the current version, and and Oauth library was added, however it is not presently being used and is included for future applications.

* '''Impact''': This work requires no additional modifications to other modules
* '''Blockers''': None known

=== Implementation Overview ===

Integration Service implementation follows standard Robust module design and provides the main code in `OpenSim/Services/Integration` and additional code for external web management applications in `OpenSim/Server/Handlers/Integration`. The services are implemented externally, preferably in the `./addon-modules` area provided for third party development, and are available (in binary form) from repositories subscribed to by the user. A plugin repository for testing is setup at http://bluewallvirtual.com/plugins (please see: http://bluewallvirtual.com/node/46 for instructions and an overview of user interaction in the console) . An entry in the Robust.ini allows setting Integration Service to run in development mode, to allow local loading and debugging of plugins under development. Normally this is switched to “false” to have Integration Service manage the plugins via registries.
The plugin carries information to direct Integration Service to find initial configuration information that is used in conjunction with the existing Robust configuration. The configuration uses one ini per-plugin and are placed in the location specified in the Robust.ini by the user. Plugins can also cary information for users to aquire additional information and components such as web applications or libraries for use with the plugin.
For an overview of plugin development, see the Example at https://github.com/BlueWall/IntegrationExample and also IIntegrationPlugin . Be sure to set DevelopmentMode=true in your Robust.ini to load the plugins in a manner that allows them to be run in your debugger. This needs to be set to false when not developing.

=== User Experience ===

Users will use the Robust command line to add repositories and then select plugins from those. The plugins can be enabled, disabled, un-installed from the Robust command line. Information built into the plugin about support sites, etc. can be seen in the command line as well.

A good overview of operation is at http://bluewallvirtual.com/node/46

== Low-Level Design ==

Plugins adhere to an interface that imposes methods to handle startup and unloading. Included in these are methods to provide data needed to set the initial configuration and find the configuration file needed at runtime.

The plugins are managed by the mono-addins framework to allow registration of repositories, listing and selection of available plugins and plugin loading at runtime.

Feature Proposals/PluginManager

2012-07-23T18:17:16Z

BlueWall:

{{proposal}}
This is the next evolution of http://opensimulator.org/wiki/IntegrationService

We are working to make the plugin management in integral part of the system that will allow us to maintain comparability with the structure have and still be able to use dynamic interaction with the modules.

IntegrationService

2012-07-23T18:15:07Z

BlueWall:

{{proposal}}

{{ information }}: In-Progress. See: http://opensimulator.org/wiki/Feature_Proposals/PluginManager

= IntegrationService =

== Basic Info ==

* '''Summary''': Integration Service is a Robust facility to provide management for running dynamic plugins used for extending connections into the grid from external applications.
* '''Developer Sponsor(s)''': BlueWall Information Technologies, LLC (BlueWall) jamesh@bluewallgroup.com / IRC - "BlueWall" on #opensim-dev, #opensim
* '''Start Date''': March 31, 2012
* '''Branches Targeted''': OpenSim master/development (after evaluation)
* '''Commercial''': Not specifically, but of general interest to adopters to help them integrate their external projects with OpenSimulator
* '''Code Repository''': OpenSimulator main repository in the "integration" branch and https://github.com/BlueWall/opensim/tree/integration

== High-Level Design ==

=== Idea ===

Integration Service for Robust is a facility to manage dynamic plugins, allowing external applications to be integrated with the OpenSimulator grid. The service helps the application developer provide clean APIs for their OpenSimulator integration projects by supplying a convenient framework to manage plugins that reside outside of OpenSimulator core. Their applications may be easily distributed across other sites without the need to interface directly to the underlying database structure. The developer has access to the OpenSimulator framework, including database migrations, easing maintenance tasks for users and administrators of their applications. This framework also opens the possibility for “crowd sourcing” standard APIs and libraries for applications such as web integration for popular CMS like Drupal, Joomla and Django and building API libraries for popular programming languages. These would offer a level of abstraction from the OpenSimulator core project to help minimize conflicts with external projects when core changes are needed. With the user-base migrating to V3 based viewers, which require lots of web applications which are tightly integrated into the grid, this type of service is desired to help stabilize APIs and insulate them from core development as much as posible.
The Integration Service provides the management facility and some utility services for the external plugins. Several console commands allow management of external repositories and manipulation of plugins. A detailed user-side view for getting started may be seen at: http://bluewallvirtual.com/integration_use . This details the configuration settings in the Robust.ini for the service and gives some instructions for connecting to the example repository.
At the moment, there is an implementation of the landtool.php using this, and an example for development. Some other basic plugins are in the development stages and will be released as they are completed.

=== Criteria ===

* '''Scope''': This is already fairly complete and working. It will be good to get more eyes on it and work out details for security and provide hooks for things like Oauth for allowing applications to integrate with external sites to provide rich user experiences with the V3 based viewers. Additional testing and work is required to make the system more reliable at detecting and suggesting upgrades and requirements between versions.

* '''Software Requirements''': Mono Addins was upgraded to the current version, and and Oauth library was added, however it is not presently being used and is included for future applications.

* '''Impact''': This work requires no additional modifications to other modules
* '''Blockers''': None known

=== Implementation Overview ===

Integration Service implementation follows standard Robust module design and provides the main code in `OpenSim/Services/Integration` and additional code for external web management applications in `OpenSim/Server/Handlers/Integration`. The services are implemented externally, preferably in the `./addon-modules` area provided for third party development, and are available (in binary form) from repositories subscribed to by the user. A plugin repository for testing is setup at http://bluewallvirtual.com/plugins (please see: http://bluewallvirtual.com/node/46 for instructions and an overview of user interaction in the console) . An entry in the Robust.ini allows setting Integration Service to run in development mode, to allow local loading and debugging of plugins under development. Normally this is switched to “false” to have Integration Service manage the plugins via registries.
The plugin carries information to direct Integration Service to find initial configuration information that is used in conjunction with the existing Robust configuration. The configuration uses one ini per-plugin and are placed in the location specified in the Robust.ini by the user. Plugins can also cary information for users to aquire additional information and components such as web applications or libraries for use with the plugin.
For an overview of plugin development, see the Example at https://github.com/BlueWall/IntegrationExample and also IIntegrationPlugin . Be sure to set DevelopmentMode=true in your Robust.ini to load the plugins in a manner that allows them to be run in your debugger. This needs to be set to false when not developing.

=== User Experience ===

Users will use the Robust command line to add repositories and then select plugins from those. The plugins can be enabled, disabled, un-installed from the Robust command line. Information built into the plugin about support sites, etc. can be seen in the command line as well.

A good overview of operation is at http://bluewallvirtual.com/node/46

== Low-Level Design ==

Plugins adhere to an interface that imposes methods to handle startup and unloading. Included in these are methods to provide data needed to set the initial configuration and find the configuration file needed at runtime.

The plugins are managed by the mono-addins framework to allow registration of repositories, listing and selection of available plugins and plugin loading at runtime.

Feature Proposals/PluginManager

2012-07-23T17:47:54Z

BlueWall:

This is the next evolution of http://opensimulator.org/wiki/IntegrationService

We are working to make the plugin management in integral part of the system that will allow us to maintain comparability with the structure have and still be able to use dynamic interaction with the modules.

Feature Proposals/PluginManager

2012-07-23T17:47:33Z

BlueWall: Created page with "This is the next evolution of http://opensimulator.org/wiki/IntegrationService We are working to make the plugin management in integral part of the system that will allow us to ..."

IntegrationService

2012-07-14T02:35:26Z

BlueWall: /* Basic Info */

{{proposal}}
= IntegrationService =

== Basic Info ==

* '''Summary''': Integration Service is a Robust facility to provide management for running dynamic plugins used for extending connections into the grid from external applications.
* '''Developer Sponsor(s)''': BlueWall Information Technologies, LLC (BlueWall) jamesh@bluewallgroup.com / IRC - "BlueWall" on #opensim-dev, #opensim
* '''Start Date''': March 31, 2012
* '''Branches Targeted''': OpenSim master/development (after evaluation)
* '''Commercial''': Not specifically, but of general interest to adopters to help them integrate their external projects with OpenSimulator
* '''Code Repository''': OpenSimulator main repository in the "integration" branch and https://github.com/BlueWall/opensim/tree/integration

== High-Level Design ==

=== Idea ===

Integration Service for Robust is a facility to manage dynamic plugins, allowing external applications to be integrated with the OpenSimulator grid. The service helps the application developer provide clean APIs for their OpenSimulator integration projects by supplying a convenient framework to manage plugins that reside outside of OpenSimulator core. Their applications may be easily distributed across other sites without the need to interface directly to the underlying database structure. The developer has access to the OpenSimulator framework, including database migrations, easing maintenance tasks for users and administrators of their applications. This framework also opens the possibility for “crowd sourcing” standard APIs and libraries for applications such as web integration for popular CMS like Drupal, Joomla and Django and building API libraries for popular programming languages. These would offer a level of abstraction from the OpenSimulator core project to help minimize conflicts with external projects when core changes are needed. With the user-base migrating to V3 based viewers, which require lots of web applications which are tightly integrated into the grid, this type of service is desired to help stabilize APIs and insulate them from core development as much as posible.
The Integration Service provides the management facility and some utility services for the external plugins. Several console commands allow management of external repositories and manipulation of plugins. A detailed user-side view for getting started may be seen at: http://bluewallvirtual.com/integration_use . This details the configuration settings in the Robust.ini for the service and gives some instructions for connecting to the example repository.
At the moment, there is an implementation of the landtool.php using this, and an example for development. Some other basic plugins are in the development stages and will be released as they are completed.

=== Criteria ===

* '''Scope''': This is already fairly complete and working. It will be good to get more eyes on it and work out details for security and provide hooks for things like Oauth for allowing applications to integrate with external sites to provide rich user experiences with the V3 based viewers. Additional testing and work is required to make the system more reliable at detecting and suggesting upgrades and requirements between versions.

* '''Software Requirements''': Mono Addins was upgraded to the current version, and and Oauth library was added, however it is not presently being used and is included for future applications.

* '''Impact''': This work requires no additional modifications to other modules
* '''Blockers''': None known

=== Implementation Overview ===

Integration Service implementation follows standard Robust module design and provides the main code in `OpenSim/Services/Integration` and additional code for external web management applications in `OpenSim/Server/Handlers/Integration`. The services are implemented externally, preferably in the `./addon-modules` area provided for third party development, and are available (in binary form) from repositories subscribed to by the user. A plugin repository for testing is setup at http://bluewallvirtual.com/plugins (please see: http://bluewallvirtual.com/node/46 for instructions and an overview of user interaction in the console) . An entry in the Robust.ini allows setting Integration Service to run in development mode, to allow local loading and debugging of plugins under development. Normally this is switched to “false” to have Integration Service manage the plugins via registries.
The plugin carries information to direct Integration Service to find initial configuration information that is used in conjunction with the existing Robust configuration. The configuration uses one ini per-plugin and are placed in the location specified in the Robust.ini by the user. Plugins can also cary information for users to aquire additional information and components such as web applications or libraries for use with the plugin.
For an overview of plugin development, see the Example at https://github.com/BlueWall/IntegrationExample and also IIntegrationPlugin . Be sure to set DevelopmentMode=true in your Robust.ini to load the plugins in a manner that allows them to be run in your debugger. This needs to be set to false when not developing.

=== User Experience ===

Users will use the Robust command line to add repositories and then select plugins from those. The plugins can be enabled, disabled, un-installed from the Robust command line. Information built into the plugin about support sites, etc. can be seen in the command line as well.

A good overview of operation is at http://bluewallvirtual.com/node/46

== Low-Level Design ==

Plugins adhere to an interface that imposes methods to handle startup and unloading. Included in these are methods to provide data needed to set the initial configuration and find the configuration file needed at runtime.

The plugins are managed by the mono-addins framework to allow registration of repositories, listing and selection of available plugins and plugin loading at runtime.

Feature Proposals

2012-07-10T18:38:49Z

BlueWall: /* Present */

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

If you're adding a proposal here, please do it with a page name of Feature_Proposals/<name of service>. For example Feature_Proposals/AutoBackup.

=== Templates ===

* [[Feature Proposal Template]] - Use this template for your document.

=== Present ===

* [[Feature Proposals/Deduplicating Asset Service]]
* [[IntegrationService]]

=== Past ===

* [[Feature Proposals/AutoBackup|AutoBackup]]
* [[Statistics Server]] - Proposal for a statistics server in OpenSimulator.
* [[OpenID]] - Proposal for using OpenID in OpenSimulator
* [[AssetServerProposal]] - Proposal for a distributed asset server
* [[A better SimCrossing]] - A work in progress about implementing a smooth simcrossing
* [[Creating profiles not used for login]] - RFC for alternative ways of creating profiles that will never be used for login
* [[OpenSim Profile Anchors]] - a mechanism for retaining creator information for offline item transfers
* [[Explicit Object Serialization]] - a proposal to explicitly serialize scene objects rather than using automatic .NET XML serialization
* [[Opensim: 0.5 Release Target Discussion]]
* [[Opensim: 0.6 Release Target Discussion]]
* [[Opensim: Future Release Discussion]]
* [[OpenWiredux: Taking the next step]]

[[Category:Development]]
[[Category:Proposal]]

IntegrationService

2012-07-10T18:36:41Z

BlueWall: Created page with "{{proposal}} = IntegrationService = == Basic Info == * '''Summary''': Integration Service is a Robust facility to provide management for running dynamic plugins used for extend..."

{{proposal}}
= IntegrationService =

== Basic Info ==

* '''Summary''': Integration Service is a Robust facility to provide management for running dynamic plugins used for extending connections into the grid from external applications.
* '''Developer Sponsor(s)''': BlueWall Information Technologies, LLC (BlueWall) jamesh@bluewallgroup.com / IRC - "BlueWall" on #opensim-dev, #opensim
* '''Start Date''': March 31, 2012
* '''Branches Targeted''': OpenSim master/development (after evaluation)
* '''Commercial''': Not specifically, but of general interest to adopters to help them integrate their external projects with OpenSimulator
* '''Code Repository''': https://github.com/BlueWall/opensim/tree/integration ''will send to opensimulator.org as a branch soon''

== High-Level Design ==

=== Idea ===

Integration Service for Robust is a facility to manage dynamic plugins, allowing external applications to be integrated with the OpenSimulator grid. The service helps the application developer provide clean APIs for their OpenSimulator integration projects by supplying a convenient framework to manage plugins that reside outside of OpenSimulator core. Their applications may be easily distributed across other sites without the need to interface directly to the underlying database structure. The developer has access to the OpenSimulator framework, including database migrations, easing maintenance tasks for users and administrators of their applications. This framework also opens the possibility for “crowd sourcing” standard APIs and libraries for applications such as web integration for popular CMS like Drupal, Joomla and Django and building API libraries for popular programming languages. These would offer a level of abstraction from the OpenSimulator core project to help minimize conflicts with external projects when core changes are needed. With the user-base migrating to V3 based viewers, which require lots of web applications which are tightly integrated into the grid, this type of service is desired to help stabilize APIs and insulate them from core development as much as posible.
The Integration Service provides the management facility and some utility services for the external plugins. Several console commands allow management of external repositories and manipulation of plugins. A detailed user-side view for getting started may be seen at: http://bluewallvirtual.com/integration_use . This details the configuration settings in the Robust.ini for the service and gives some instructions for connecting to the example repository.
At the moment, there is an implementation of the landtool.php using this, and an example for development. Some other basic plugins are in the development stages and will be released as they are completed.

=== Criteria ===

* '''Scope''': This is already fairly complete and working. It will be good to get more eyes on it and work out details for security and provide hooks for things like Oauth for allowing applications to integrate with external sites to provide rich user experiences with the V3 based viewers. Additional testing and work is required to make the system more reliable at detecting and suggesting upgrades and requirements between versions.

* '''Software Requirements''': Mono Addins was upgraded to the current version, and and Oauth library was added, however it is not presently being used and is included for future applications.

* '''Impact''': This work requires no additional modifications to other modules
* '''Blockers''': None known

=== Implementation Overview ===

Integration Service implementation follows standard Robust module design and provides the main code in `OpenSim/Services/Integration` and additional code for external web management applications in `OpenSim/Server/Handlers/Integration`. The services are implemented externally, preferably in the `./addon-modules` area provided for third party development, and are available (in binary form) from repositories subscribed to by the user. A plugin repository for testing is setup at http://bluewallvirtual.com/plugins (please see: http://bluewallvirtual.com/node/46 for instructions and an overview of user interaction in the console) . An entry in the Robust.ini allows setting Integration Service to run in development mode, to allow local loading and debugging of plugins under development. Normally this is switched to “false” to have Integration Service manage the plugins via registries.
The plugin carries information to direct Integration Service to find initial configuration information that is used in conjunction with the existing Robust configuration. The configuration uses one ini per-plugin and are placed in the location specified in the Robust.ini by the user. Plugins can also cary information for users to aquire additional information and components such as web applications or libraries for use with the plugin.
For an overview of plugin development, see the Example at https://github.com/BlueWall/IntegrationExample and also IIntegrationPlugin . Be sure to set DevelopmentMode=true in your Robust.ini to load the plugins in a manner that allows them to be run in your debugger. This needs to be set to false when not developing.

=== User Experience ===

Users will use the Robust command line to add repositories and then select plugins from those. The plugins can be enabled, disabled, un-installed from the Robust command line. Information built into the plugin about support sites, etc. can be seen in the command line as well.

A good overview of operation is at http://bluewallvirtual.com/node/46

== Low-Level Design ==

Plugins adhere to an interface that imposes methods to handle startup and unloading. Included in these are methods to provide data needed to set the initial configuration and find the configuration file needed at runtime.

The plugins are managed by the mono-addins framework to allow registration of repositories, listing and selection of available plugins and plugin loading at runtime.

User talk:BlueWall

2012-07-10T16:59:22Z

BlueWall: moved User talk:BlueWall to Test Page: See if this creates a page

#REDIRECT [[Test Page]]

Test Page

2012-07-10T16:59:22Z

BlueWall: moved User talk:BlueWall to Test Page: See if this creates a page

'''As of 2011-10-10 I copy/pasted this over to the linked [[UXSimStatus]] for further change/editing -- [[User:Justincc|Justincc]] 20:22, 10 October 2011 (UTC)'''

== JSON User SimStats ==

As of OpenSim svn 9529 the xtended stats reporting will return a jsonp
callback to allow popular javascript toolkits to use the returned data to
create ajax monitoring applications in the browser. This is an advantage
because after the page is loaded, the browser will interact directly with
the region, eliminating traffic through the website (polling the region and
servicing the browser). It also allows the creation of mashups to create
mini-monitor apps in other pages.

To enable your stats reporting, set the following in your OpenSim.ini...

; Simulator Stats URI
; Enable JSON simulator data by setting a URI name (case sensitive)
Stats_URI = "jsonSimStats"

...the URI can be anything you want, and is case sensitive. You can query
the URI directly to return a json string to use in php, python, java, etc.
or you may use one of the popular javascript toolkits to have OpenSim
generate a callback for jsonp. The json serialization carries the following
data...

{"AssetsInCache":5.0,"TimeAfterCacheMiss":0.0,"BlockedMissingTextureRequests":0.0,"AssetServiceRequestFailures":0.0,
"abnormalClientThreadTerminations":0.0,"InventoryServiceRetrievalFailures":0.0,"Dilatn":0.967380821704865,"SimFPS":55.0,
"PhyFPS":47.1628913879395,"AgntUp":0.0,"RootAg":0.0,"ChldAg":0.0,"Prims":0.0,"AtvPrm":0.0,"AtvScr":0.0,"ScrLPS":0.0,
"PktsIn":0.0,"PktOut":0.0,"PendDl":0.0,"PendUl":0.0,"UnackB":0.0,"TotlFt":0.0,"NetFt":0.0,"PhysFt":0.0,"OthrFt":0.0,
"AgntFt":0.0,"ImgsFt":0.0,"Memory":"8","Uptime":"05:12:19.0365590","Version":"OpenSimulator Server 0.6.4.9533 "}

<source lang="html4strict">
<html>
<head>
<title>JSON Test</title>
<script src="http://ascent.bluewallgroup.com/jquery-1.3.2.js"></script>
<script src="http://ascent.bluewallgroup.com/timer.js"></script>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript" language="JavaScript">
SimFPS = 0;
PhyFPS = 0;
Memory = 0;
RootAg = 0;
ChldAg = 0;
Uptime = "";
Version = "";
</script>

<script type="text/javascript" language="JavaScript">

$.timer(15000, function(timer) {
$.getJSON("http://ascent.bluewallgroup.com:9300/jsonSimStats/?callback=?",

function(data){

SimFPS = Math.round(data.SimFPS);
PhyFPS = Math.round(data.PhyFPS);
Memory = Math.round(data.Memory);
ChldAg = data.ChldAg;
RootAg = data.RootAg;
Uptime = data.Uptime;
Version = data.Version;
drawChart();
setTags();
timer.reset(15000);
});
});
</script>

<script type="text/javascript" language="JavaScript">

google.load("visualization", "1", {packages:["gauge"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var cdata = new google.visualization.DataTable();
cdata.addColumn('string', 'Label');
cdata.addColumn('number', 'Value');
cdata.addRows(3);
cdata.setValue(0, 0, 'SimFPS');
cdata.setValue(0, 1, SimFPS);
cdata.setValue(1, 0, 'PhyFPS');
cdata.setValue(1, 1, PhyFPS);
cdata.setValue(2, 0, 'Memory');
cdata.setValue(2, 1, Memory);

var chart = new
google.visualization.Gauge(document.getElementById('chart_div'));
var options = {width: 400, height: 120, redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90, minorTicks: 5};
chart.draw(cdata, options);
}
</script>

<script type="text/javascript" language="JavaScript">
function setTags() {
$("#par-uptime").text("Uptime: " + Uptime);
$("#par-ragent").text("Root Agent: " + RootAg);
$("#par-version").text("Version: " + Version);
$("#par-cagent").text("Child Agent: " + ChldAg);
}
</script>

</head>
<body>
<h1>BlueWall Development Region</h1>
<table>
<tr><td>
<div id="par-version">version</div>
</td><td>
<div id="par-ragent">root agent</div>
</td></tr><tr><td>
<div id="par-uptime">uptime</div>
</td><td>
<div id="par-cagent">child agent</div>
</td></tr>
</table>
<div id="chart_div"></div>
</body>
</html>
</source>

[[SSL in OpenSim]]

== JSON Grid Simstats ==

Python example to gain the region data from a grid service
- should work but this version not tested -
*reference material*

<source lang="python">

import hashlib
import urllib2

''' value shown is an example, get this from your grid database each time - regions.regionSecret '''
regionsecret = 'fe21314b-6267-44f7-aa1e-6047e1c3f94a'

''' My region host '''
hostName = myregion.host.net

''' My region port '''
hostPort = 9000

''' create an *UPPERCASE* SHA1 hash from the regionSecret '''
resourceName = str(hashlib.sha1(regionsecret).hexdigest()).upper()

regionuri = hostName + ":" + hostPort + "/" + resourceName + "/"

''' data includes TimeZoneName , TimeZoneOffs, UxTime, Memory, Version and OSStatsURI '''
regiondata = simplejson.load(urllib2.urlopen(regionuri))

''' OSStatsURI is the uri to query the OpenSim instance. return same data as the user set uri '''
simuri = regiondata['OSStatsURI']

simdata = simplejson.load(urllib2.urlopen(simuri))

</source>

== Using shell environment variables in OpenSim configuration ==

We will need to use two new things in our configurations: a section [Environment] to tell us what variables we need to look at in the shell and we will need to use the Nini key expansion. Nini, can have keys that look like ${SECTION|VARIABLE} and can expand those to the variables we assign.

In your shell you will export your values and check the ones you want to use that are predefined by your system ...

<source lang="bash">
export RT_ZONE=Zone_00
</source>

<source lang="bash">
# You can see your HOSTNAME (It will be set by the system)...
echo $HOSTNAME
OSERV_00
</source>

In the ini you will include an [Environment] section...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSim on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/${Environment|RT_ZONE}/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "${Environment|HOSTNAME}:${Environment|RT_ZONE} "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=${Environment|RT_ZONE};User ID=username;Password=userpass;" ; Here too
</source>

When OpenSim picks up the variables in your shell and processes all the configurations, the variable keys will be filled in with the variables picked up from the shell ...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSim on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/Zone_00/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "OSERV_00:Zone_09 "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=Zone_00;User ID=username;Password=userpass;" ; Here too
</source>

This is a pretty good start. I think there will be a couple of places we might be able to use this to help us setup really flexible configuration systems for OpenSim.

Have Fun!

== TESTING ==

This is a test

Test Page

2012-07-10T16:58:44Z

BlueWall: /* TESTING */ new section

'''As of 2011-10-10 I copy/pasted this over to the linked [[UXSimStatus]] for further change/editing -- [[User:Justincc|Justincc]] 20:22, 10 October 2011 (UTC)'''

== JSON User SimStats ==

As of OpenSim svn 9529 the xtended stats reporting will return a jsonp
callback to allow popular javascript toolkits to use the returned data to
create ajax monitoring applications in the browser. This is an advantage
because after the page is loaded, the browser will interact directly with
the region, eliminating traffic through the website (polling the region and
servicing the browser). It also allows the creation of mashups to create
mini-monitor apps in other pages.

To enable your stats reporting, set the following in your OpenSim.ini...

; Simulator Stats URI
; Enable JSON simulator data by setting a URI name (case sensitive)
Stats_URI = "jsonSimStats"

...the URI can be anything you want, and is case sensitive. You can query
the URI directly to return a json string to use in php, python, java, etc.
or you may use one of the popular javascript toolkits to have OpenSim
generate a callback for jsonp. The json serialization carries the following
data...

{"AssetsInCache":5.0,"TimeAfterCacheMiss":0.0,"BlockedMissingTextureRequests":0.0,"AssetServiceRequestFailures":0.0,
"abnormalClientThreadTerminations":0.0,"InventoryServiceRetrievalFailures":0.0,"Dilatn":0.967380821704865,"SimFPS":55.0,
"PhyFPS":47.1628913879395,"AgntUp":0.0,"RootAg":0.0,"ChldAg":0.0,"Prims":0.0,"AtvPrm":0.0,"AtvScr":0.0,"ScrLPS":0.0,
"PktsIn":0.0,"PktOut":0.0,"PendDl":0.0,"PendUl":0.0,"UnackB":0.0,"TotlFt":0.0,"NetFt":0.0,"PhysFt":0.0,"OthrFt":0.0,
"AgntFt":0.0,"ImgsFt":0.0,"Memory":"8","Uptime":"05:12:19.0365590","Version":"OpenSimulator Server 0.6.4.9533 "}

<source lang="html4strict">
<html>
<head>
<title>JSON Test</title>
<script src="http://ascent.bluewallgroup.com/jquery-1.3.2.js"></script>
<script src="http://ascent.bluewallgroup.com/timer.js"></script>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript" language="JavaScript">
SimFPS = 0;
PhyFPS = 0;
Memory = 0;
RootAg = 0;
ChldAg = 0;
Uptime = "";
Version = "";
</script>

<script type="text/javascript" language="JavaScript">

$.timer(15000, function(timer) {
$.getJSON("http://ascent.bluewallgroup.com:9300/jsonSimStats/?callback=?",

function(data){

SimFPS = Math.round(data.SimFPS);
PhyFPS = Math.round(data.PhyFPS);
Memory = Math.round(data.Memory);
ChldAg = data.ChldAg;
RootAg = data.RootAg;
Uptime = data.Uptime;
Version = data.Version;
drawChart();
setTags();
timer.reset(15000);
});
});
</script>

<script type="text/javascript" language="JavaScript">

google.load("visualization", "1", {packages:["gauge"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var cdata = new google.visualization.DataTable();
cdata.addColumn('string', 'Label');
cdata.addColumn('number', 'Value');
cdata.addRows(3);
cdata.setValue(0, 0, 'SimFPS');
cdata.setValue(0, 1, SimFPS);
cdata.setValue(1, 0, 'PhyFPS');
cdata.setValue(1, 1, PhyFPS);
cdata.setValue(2, 0, 'Memory');
cdata.setValue(2, 1, Memory);

var chart = new
google.visualization.Gauge(document.getElementById('chart_div'));
var options = {width: 400, height: 120, redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90, minorTicks: 5};
chart.draw(cdata, options);
}
</script>

<script type="text/javascript" language="JavaScript">
function setTags() {
$("#par-uptime").text("Uptime: " + Uptime);
$("#par-ragent").text("Root Agent: " + RootAg);
$("#par-version").text("Version: " + Version);
$("#par-cagent").text("Child Agent: " + ChldAg);
}
</script>

</head>
<body>
<h1>BlueWall Development Region</h1>
<table>
<tr><td>
<div id="par-version">version</div>
</td><td>
<div id="par-ragent">root agent</div>
</td></tr><tr><td>
<div id="par-uptime">uptime</div>
</td><td>
<div id="par-cagent">child agent</div>
</td></tr>
</table>
<div id="chart_div"></div>
</body>
</html>
</source>

[[SSL in OpenSim]]

== JSON Grid Simstats ==

Python example to gain the region data from a grid service
- should work but this version not tested -
*reference material*

<source lang="python">

import hashlib
import urllib2

''' value shown is an example, get this from your grid database each time - regions.regionSecret '''
regionsecret = 'fe21314b-6267-44f7-aa1e-6047e1c3f94a'

''' My region host '''
hostName = myregion.host.net

''' My region port '''
hostPort = 9000

''' create an *UPPERCASE* SHA1 hash from the regionSecret '''
resourceName = str(hashlib.sha1(regionsecret).hexdigest()).upper()

regionuri = hostName + ":" + hostPort + "/" + resourceName + "/"

''' data includes TimeZoneName , TimeZoneOffs, UxTime, Memory, Version and OSStatsURI '''
regiondata = simplejson.load(urllib2.urlopen(regionuri))

''' OSStatsURI is the uri to query the OpenSim instance. return same data as the user set uri '''
simuri = regiondata['OSStatsURI']

simdata = simplejson.load(urllib2.urlopen(simuri))

</source>

== Using shell environment variables in OpenSim configuration ==

We will need to use two new things in our configurations: a section [Environment] to tell us what variables we need to look at in the shell and we will need to use the Nini key expansion. Nini, can have keys that look like ${SECTION|VARIABLE} and can expand those to the variables we assign.

In your shell you will export your values and check the ones you want to use that are predefined by your system ...

<source lang="bash">
export RT_ZONE=Zone_00
</source>

<source lang="bash">
# You can see your HOSTNAME (It will be set by the system)...
echo $HOSTNAME
OSERV_00
</source>

In the ini you will include an [Environment] section...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSim on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/${Environment|RT_ZONE}/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "${Environment|HOSTNAME}:${Environment|RT_ZONE} "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=${Environment|RT_ZONE};User ID=username;Password=userpass;" ; Here too
</source>

When OpenSim picks up the variables in your shell and processes all the configurations, the variable keys will be filled in with the variables picked up from the shell ...
<source lang="ini">
[Environment] ; Our Environment section that defines the shell variables we are interested in
RT_ZONE="" ; We might use a zone to setup an instance of OpenSim on a server
HOSTNAME="" ; We might be interested in obtaining the host's name

[Startup]
regionload_regionsdir=/home/opensim/etc/Regions/Zone_00/ ; We set our regionload_regionsdir using the variables
ConsolePrompt = "OSERV_00:Zone_09 "

[DatabaseService]
ConnectionString = "Data Source=localhost;Database=Zone_00;User ID=username;Password=userpass;" ; Here too
</source>

This is a pretty good start. I think there will be a couple of places we might be able to use this to help us setup really flexible configuration systems for OpenSim.

Have Fun!

== TESTING ==

This is a test

Feature Matrix

2012-05-03T10:09:02Z

BlueWall: /* World */

{{Quicklinks}}
<br />

= Introduction =

This is a matrix of the features currently implemented in OpenSimulator. Please feel free to correct existing entries and add new ones. The data in this matrix refers to the currently released version of OpenSimulator unless otherwise stated.

OpenSimulator can run on Linux & Mac with MONO, see the [http://www.mono-project.com/Main_Page Mono project] for availability or your distribution provider. Windows requires Net Framework 3.51 available from [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ab99342f-5d1a-413d-8319-81da479ab0d7&displaylang=en MS Downloads]

<br />

== Prims ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Create/change/move/delete prims
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Persistent prim inventories
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Basic asset types
| bgcolor="#00ff00" align="center" | Yes
| Basic asset types include textures, sounds, notecards, etc.
|-
| Coalesced object groups (being able to take a selection of unlinked objects as one group that can be rezzed back in the same spatial arrangements)
| bgcolor="#00ff00" align="center" | Yes
| Coalesced object groups means being able to take a selection of unlinked objects as one group that can be rezzed back in the same spatial arrangements. Support added in OpenSimulator 0.7.1
|-
| Linksets
| bgcolor="#00ff00" align="center" | Yes
| Bugs (some fairly fundamental) remain with linksets but basic support is implemented.
|-
| Media on a prim/Shared Media
| bgcolor="#00ff00" align="center" | Yes
| Support added in OpenSimulator 0.7.1. But please note that this is based on the current beta Linden implementation of mesh, which is likely to change soon. Please do not rely on mesh for any production use at the moment.
|-
| [[Dynamic textures]]
| bgcolor="#00ff00" align="center" | Yes
| Dynamic textures are textures that can be created on the fly via draw commands.
|-
| Sculpties
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| [[Mesh]]
| bgcolor="#ffff00" align="center" | Beta/Experimental
| Mesh is implemented in OpenSimulator 0.7.2 onwards. This is the newer mesh implementation as found in Linden Lab viewer 3. Older versions of OpenSimulator contained the older beta implementation. Please note that this feature is experimental and should be used cautiously.
|}

 

== Users ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Walking
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Flying
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Sitting
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Animations
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Gestures
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Attachments
| bgcolor="#ffd700" align="center" | Partial
| Both worn attachments and Head Up Displays (HUDs) are implemented. Outfits are implemented. Wearing multiple attachments at a single point is not yet implemented.
|-
| Combat
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Region crossing
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Teleport
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Persistent avatar inventories
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Inventory library
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Chat
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Instant messaging
| bgcolor="#00ff00" align="center" | Yes
| Offline IM storage requires a third party packages such as http://forge.opensimulator.org/gf/project/opensimwi/ in releases before 0.7.2.
|-
| Names
| bgcolor="#ffd700" align="center" | Partial
| Ordinary names consisting of a first and last name separated by a space are implemented. 'Display' names are not yet implemented.
|-
| Archiving
| bgcolor="#00ff00" align="center" | Yes
| Users inventories and parts of inventories can be saved and loaded as [[Inventory Archives|OpenSimulator Inventory Archives]].
|-
| Friends
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Lure
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| [[Enabling Groups|Groups]]
| bgcolor="#ffffff" align="center" | 3rd party
| Group support is only available as third party projects:
* [https://github.com/mcortez/flotsam Group service implementation from the Flotsam project]. '''Please note: this is not working properly with OpenSimulator 0.7.0.1 or 0.7.0.2, though it is fixed in OpenSimulator 0.7.1 and onwards. 0.6.9 should also work okay.'''
* [https://github.com/jor3l/OSModules/tree/master/osgroups/ osgroups from jor3l]
* [http://code.google.com/p/openmetaverse SimianGrid] also provides a Groups connector as part of its grid services package.

These services have connectors that are bundled with core OpenSimulator. See [[Enabling Groups]] and the OpenSim.ini.example file for more details.

|-
| Profiles
| bgcolor="#ffffff" align="center" | 3rd party
|
Only avatar names are stored in core OpenSimulator. Profile support (e.g. interests, 1st Life, etc.) is available via 3rd party modules, though these may currently only support OpenSimulator 0.6.9. Please add suitable links here.

* [http://forge.opensimulator.org/gf/project/osprofile forge.opensimulator.org/gf/project/osprofile]

|-
| Search
| bgcolor="#ffffff" align="center" | 3rd party
| Search support is only available via third party modules.
* [[OpenSimSearch]]

|-
| Display names
| bgcolor="#ff0000" align="center" | No
|
|}

 

== Scripting ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| [[Developer Documentation#Scripting|Scripts]]
| bgcolor="#00ff00" align="center" | Yes
| A large percentage (though not all) of LSL is implemented by OpenSimulator. There are also OpenSimulator specific OSSL functions available.
|-
| [[Non-LSL scripting|C# scripting]]
| bgcolor="#00ff00" align="center" | Yes
| C# scripting is experimental and insecure. However, it can be useful in some situations
|-
| Script control
| bgcolor="#00ff00" align="center" | Yes
| There are some facilities to control what user types can create and edit scripts. This can help secure an implementation using C# scripts. See the OpenSim.ini.example file in the OpenSimulator distribution for more details.
|}

 

== World ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Terrain
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Sun
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Wind
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Cloud
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Vegetation
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Sound
| bgcolor="#ffd700" align="center" | Partial
| Not all sound facilties work (e.g. queueing sounds).
|-
| Minimap
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| World Map
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Neighbouring regions
| bgcolor="#00ff00" align="center" | Yes
| Regions can neighbour each other, even if hosted on different servers.
|-
| Archiving
| bgcolor="#00ff00" align="center" | Yes
| Entire regions can be saved and loaded as [[OpenSim Archives]].
|-
| [[PhysicsEngines|Physics]]
| bgcolor="#00ff00" align="center" | Yes
| There are several physics modules bundled with OpenSim, but only the ODE module (Open Dynamics Engine) really works.
|-
| Parcel management
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Region settings
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Telehubs
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Estates
| bgcolor="#ffd700" align="center" | Partial
| Partial estate support is implemented. However, the only way to manipulate estates currently is via direct changes to the database.
|-
| Avatar limits
| bgcolor="#00ff00" align="center" | Yes
| Avatar limits were implemented in OpenSimulator 0.7.2.
|-
| Prim limits
| bgcolor="#00ff00" align="center" | Yes
| Prim limits where implement in OpenSimulator 0.7.2.
|-
| Teleports
| bgcolor="#ffd700" align="center" | Partial
| Teleporting in can be done to any point in or off world (if hypergrid enabled) however, Blocking teleports to a parcel is not currently enforced.
|-
| Megaregions
| bgcolor="#ff0000" align="center" | Experimental
| This is a system that allows regions to be created on the simulator that are larger than 256m x 256m. This is implemented purely on the server without requiring a specially adapted client. However, this is not fully implemented and you may encounter various issues with megaregions.
|-
| [[OSSLNPC|NPCs]]
| bgcolor="#ff0000" align="center" | Experimental
| Allow NPCs to be created and manipulated on a region. This is handled purely on the server-side - NPCs are different from bots controlled as external clients via a library such as libomv.
|}

 

== Other Simulation Features ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| IRC
| bgcolor="#00ff00" align="center" | Yes
| Relay chat back and forth to an Internet Relay Channel.
|-
| Money
| bgcolor="#ffffff" align="center" | 3rd party
| There are no plans to directly provide economy modules in OpenSimulator though custom currency names are supported in 0.7.2 and after. Third party facilities include:
* [http://forge.opensimulator.org/gf/project/opencurrency/ OpenCurrency]
* [http://forge.opensimulator.org/gf/project/currency/ DTL Currency]
* [http://github.com/SnoopyPfeffer/Mod-PayPal Mod-PayPal]
* [https://www.virwox.com/omc-open-metaverse-currency.php Open Metaverse Currency (OMC)]
* [http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?OpenSim%2FMoneyServer DTL/NSL Money Server]
|-
| Permissions
| bgcolor="#00ff00" align="center" | Yes
| Permissions (e.g. controlling whether objects can be modified or copied) must be enabled in OpenSim.ini - these are not enabled by default
|-
| [[Monitoring]]
| bgcolor="#ffd700" align="center" | Partial
| A number of monitoring facilities exist, though none of them yet cover everything that one would want to monitor.
|-
| Voice
| bgcolor="#ffd700" align="center" | Partial
| Voice support is currently primitive. OpenSimulator currently bundles a Vivox module (only usable with a Vivox voice server) and a [[Freeswitch Module|Freeswitch module]]. A third party [[Mumble]] voice module also exists which supports indication of which avatar is speaking. No module yet supports spatial voice.
|-
| Web frontends
| bgcolor="#ffffff" align="center" | 3rd party
| Various third-party web frontends are available, detailed on the [[Webinterface]] page.
|}

 

== Server Features ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Local console
| bgcolor="#00ff00" align="center" | Yes
| The local command console in OpenSimulator is the one present when you start an OpenSimulator instance
|-
| [[RestConsole|Remote console]]
| bgcolor="#00ff00" align="center" | Yes
|
|-
| [[RemoteAdmin|Remote admin]]
| bgcolor="#00ff00" align="center" | Yes
| The remote admin plugin allows OpenSimulator commands to be executed remotely.
|-
| [[Logging]]
| bgcolor="#00ff00" align="center" | Yes
| OpenSimulator uses the log4net package. More details on the logging page.
|}

 

== Architectures ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Single server (standalone) mode
| bgcolor="#00ff00" align="center" | Yes
| Persistent databases supported in standalone mode are SQLite and MySQL. A MSSQL exists and should work, but is not officially supported.
|-
| Grid (multi-server) mode
| bgcolor="#00ff00" align="center" | Yes
| In grid mode, only persistence to a MySQL database is officially supported. Persistence can also be done with a MSSQL database but this is not officially supported.
|-
| [[Hypergrid]]
| bgcolor="#ff0000" align="center" | Experimental
| This is an architecture, [http://en.wikipedia.org/wiki/Orthogonal orthogonal] to the previous two, that allows users to visit completely separate OpenSimulator installations while retaining their appearance, identity and inventory. This is under active development and should be considered experimental.
|}

 

Feature Matrix

2012-05-03T10:07:17Z

BlueWall: /* World */

{{Quicklinks}}
<br />

= Introduction =

This is a matrix of the features currently implemented in OpenSimulator. Please feel free to correct existing entries and add new ones. The data in this matrix refers to the currently released version of OpenSimulator unless otherwise stated.

OpenSimulator can run on Linux & Mac with MONO, see the [http://www.mono-project.com/Main_Page Mono project] for availability or your distribution provider. Windows requires Net Framework 3.51 available from [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ab99342f-5d1a-413d-8319-81da479ab0d7&displaylang=en MS Downloads]

<br />

== Prims ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Create/change/move/delete prims
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Persistent prim inventories
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Basic asset types
| bgcolor="#00ff00" align="center" | Yes
| Basic asset types include textures, sounds, notecards, etc.
|-
| Coalesced object groups (being able to take a selection of unlinked objects as one group that can be rezzed back in the same spatial arrangements)
| bgcolor="#00ff00" align="center" | Yes
| Coalesced object groups means being able to take a selection of unlinked objects as one group that can be rezzed back in the same spatial arrangements. Support added in OpenSimulator 0.7.1
|-
| Linksets
| bgcolor="#00ff00" align="center" | Yes
| Bugs (some fairly fundamental) remain with linksets but basic support is implemented.
|-
| Media on a prim/Shared Media
| bgcolor="#00ff00" align="center" | Yes
| Support added in OpenSimulator 0.7.1. But please note that this is based on the current beta Linden implementation of mesh, which is likely to change soon. Please do not rely on mesh for any production use at the moment.
|-
| [[Dynamic textures]]
| bgcolor="#00ff00" align="center" | Yes
| Dynamic textures are textures that can be created on the fly via draw commands.
|-
| Sculpties
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| [[Mesh]]
| bgcolor="#ffff00" align="center" | Beta/Experimental
| Mesh is implemented in OpenSimulator 0.7.2 onwards. This is the newer mesh implementation as found in Linden Lab viewer 3. Older versions of OpenSimulator contained the older beta implementation. Please note that this feature is experimental and should be used cautiously.
|}

 

== Users ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Walking
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Flying
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Sitting
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Animations
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Gestures
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Attachments
| bgcolor="#ffd700" align="center" | Partial
| Both worn attachments and Head Up Displays (HUDs) are implemented. Outfits are implemented. Wearing multiple attachments at a single point is not yet implemented.
|-
| Combat
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Region crossing
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Teleport
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Persistent avatar inventories
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Inventory library
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Chat
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Instant messaging
| bgcolor="#00ff00" align="center" | Yes
| Offline IM storage requires a third party packages such as http://forge.opensimulator.org/gf/project/opensimwi/ in releases before 0.7.2.
|-
| Names
| bgcolor="#ffd700" align="center" | Partial
| Ordinary names consisting of a first and last name separated by a space are implemented. 'Display' names are not yet implemented.
|-
| Archiving
| bgcolor="#00ff00" align="center" | Yes
| Users inventories and parts of inventories can be saved and loaded as [[Inventory Archives|OpenSimulator Inventory Archives]].
|-
| Friends
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Lure
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| [[Enabling Groups|Groups]]
| bgcolor="#ffffff" align="center" | 3rd party
| Group support is only available as third party projects:
* [https://github.com/mcortez/flotsam Group service implementation from the Flotsam project]. '''Please note: this is not working properly with OpenSimulator 0.7.0.1 or 0.7.0.2, though it is fixed in OpenSimulator 0.7.1 and onwards. 0.6.9 should also work okay.'''
* [https://github.com/jor3l/OSModules/tree/master/osgroups/ osgroups from jor3l]
* [http://code.google.com/p/openmetaverse SimianGrid] also provides a Groups connector as part of its grid services package.

These services have connectors that are bundled with core OpenSimulator. See [[Enabling Groups]] and the OpenSim.ini.example file for more details.

|-
| Profiles
| bgcolor="#ffffff" align="center" | 3rd party
|
Only avatar names are stored in core OpenSimulator. Profile support (e.g. interests, 1st Life, etc.) is available via 3rd party modules, though these may currently only support OpenSimulator 0.6.9. Please add suitable links here.

* [http://forge.opensimulator.org/gf/project/osprofile forge.opensimulator.org/gf/project/osprofile]

|-
| Search
| bgcolor="#ffffff" align="center" | 3rd party
| Search support is only available via third party modules.
* [[OpenSimSearch]]

|-
| Display names
| bgcolor="#ff0000" align="center" | No
|
|}

 

== Scripting ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| [[Developer Documentation#Scripting|Scripts]]
| bgcolor="#00ff00" align="center" | Yes
| A large percentage (though not all) of LSL is implemented by OpenSimulator. There are also OpenSimulator specific OSSL functions available.
|-
| [[Non-LSL scripting|C# scripting]]
| bgcolor="#00ff00" align="center" | Yes
| C# scripting is experimental and insecure. However, it can be useful in some situations
|-
| Script control
| bgcolor="#00ff00" align="center" | Yes
| There are some facilities to control what user types can create and edit scripts. This can help secure an implementation using C# scripts. See the OpenSim.ini.example file in the OpenSimulator distribution for more details.
|}

 

== World ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Terrain
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Sun
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Wind
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Cloud
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Vegetation
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Sound
| bgcolor="#ffd700" align="center" | Partial
| Not all sound facilties work (e.g. queueing sounds).
|-
| Minimap
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| World Map
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Neighbouring regions
| bgcolor="#00ff00" align="center" | Yes
| Regions can neighbour each other, even if hosted on different servers.
|-
| Archiving
| bgcolor="#00ff00" align="center" | Yes
| Entire regions can be saved and loaded as [[OpenSim Archives]].
|-
| [[PhysicsEngines|Physics]]
| bgcolor="#00ff00" align="center" | Yes
| There are several physics modules bundled with OpenSim, but only the ODE module (Open Dynamics Engine) really works.
|-
| Parcel management
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Region settings
| bgcolor="#00ff00" align="center" | Yes
|  
|-
| Estates
| bgcolor="#ffd700" align="center" | Partial
| Partial estate support is implemented. However, the only way to manipulate estates currently is via direct changes to the database.
|-
| Avatar limits
| bgcolor="#00ff00" align="center" | Yes
| Avatar limits were implemented in OpenSimulator 0.7.2.
|-
| Prim limits
| bgcolor="#00ff00" align="center" | Yes
| Prim limits where implement in OpenSimulator 0.7.2.
|-
| Teleports
| bgcolor="#ffd700" align="center" | Partial
| Teleporting in can be done to any point in or off world (if hypergrid enabled) however, Blocking teleports to a parcel is not currently enforced.
|-
| Megaregions
| bgcolor="#ff0000" align="center" | Experimental
| This is a system that allows regions to be created on the simulator that are larger than 256m x 256m. This is implemented purely on the server without requiring a specially adapted client. However, this is not fully implemented and you may encounter various issues with megaregions.
|-
| [[OSSLNPC|NPCs]]
| bgcolor="#ff0000" align="center" | Experimental
| Allow NPCs to be created and manipulated on a region. This is handled purely on the server-side - NPCs are different from bots controlled as external clients via a library such as libomv.
|}

 

== Other Simulation Features ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| IRC
| bgcolor="#00ff00" align="center" | Yes
| Relay chat back and forth to an Internet Relay Channel.
|-
| Money
| bgcolor="#ffffff" align="center" | 3rd party
| There are no plans to directly provide economy modules in OpenSimulator though custom currency names are supported in 0.7.2 and after. Third party facilities include:
* [http://forge.opensimulator.org/gf/project/opencurrency/ OpenCurrency]
* [http://forge.opensimulator.org/gf/project/currency/ DTL Currency]
* [http://github.com/SnoopyPfeffer/Mod-PayPal Mod-PayPal]
* [https://www.virwox.com/omc-open-metaverse-currency.php Open Metaverse Currency (OMC)]
* [http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?OpenSim%2FMoneyServer DTL/NSL Money Server]
|-
| Permissions
| bgcolor="#00ff00" align="center" | Yes
| Permissions (e.g. controlling whether objects can be modified or copied) must be enabled in OpenSim.ini - these are not enabled by default
|-
| [[Monitoring]]
| bgcolor="#ffd700" align="center" | Partial
| A number of monitoring facilities exist, though none of them yet cover everything that one would want to monitor.
|-
| Voice
| bgcolor="#ffd700" align="center" | Partial
| Voice support is currently primitive. OpenSimulator currently bundles a Vivox module (only usable with a Vivox voice server) and a [[Freeswitch Module|Freeswitch module]]. A third party [[Mumble]] voice module also exists which supports indication of which avatar is speaking. No module yet supports spatial voice.
|-
| Web frontends
| bgcolor="#ffffff" align="center" | 3rd party
| Various third-party web frontends are available, detailed on the [[Webinterface]] page.
|}

 

== Server Features ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Local console
| bgcolor="#00ff00" align="center" | Yes
| The local command console in OpenSimulator is the one present when you start an OpenSimulator instance
|-
| [[RestConsole|Remote console]]
| bgcolor="#00ff00" align="center" | Yes
|
|-
| [[RemoteAdmin|Remote admin]]
| bgcolor="#00ff00" align="center" | Yes
| The remote admin plugin allows OpenSimulator commands to be executed remotely.
|-
| [[Logging]]
| bgcolor="#00ff00" align="center" | Yes
| OpenSimulator uses the log4net package. More details on the logging page.
|}

 

== Architectures ==

{| border="1"
|-
! Feature Name
! Core OpenSim?
! Notes
|-
| Single server (standalone) mode
| bgcolor="#00ff00" align="center" | Yes
| Persistent databases supported in standalone mode are SQLite and MySQL. A MSSQL exists and should work, but is not officially supported.
|-
| Grid (multi-server) mode
| bgcolor="#00ff00" align="center" | Yes
| In grid mode, only persistence to a MySQL database is officially supported. Persistence can also be done with a MSSQL database but this is not officially supported.
|-
| [[Hypergrid]]
| bgcolor="#ff0000" align="center" | Experimental
| This is an architecture, [http://en.wikipedia.org/wiki/Orthogonal orthogonal] to the previous two, that allows users to visit completely separate OpenSimulator installations while retaining their appearance, identity and inventory. This is under active development and should be considered experimental.
|}

 

Monodevelop

2012-04-05T02:47:00Z

BlueWall: /* What is monodevelop? */

__NOTOC__
{{Quicklinks}}
<br />

'''NOTE:''' The information on this page is dated. Monodevelop is at release 2.8.8.4 and has matured quite a bit since this writing.

= What is monodevelop? =
Most of us already know that it is more convenient to view/edit the OpenSimulator source in Visual Studio 2005 C# Express on Windows. However, for those of us who don't have access to Windows, monodevelop is the most suitable equivalent and remains one of the best candidate for .NET programming on Linux systems. If you are planning to work with the source on any Linux system, monodevelop and kdevelop are both capable of viewing/editing C# solutions/projects. However, support for monodevelop is somewhat limited and it does not have the same features as VS2005 C# Express. If you have an available Windows system - use Visual Studio.

* Lastest Release: monodevelop 2.0
* Official Site: [http://monodevelop.com/ MonoDevelop official site]

== Installation ==

=== From Package ===
For Debian-based Linux distributions, you can install the monodevelop package via the following command in terminal:

<tt>sudo aptitude install monodevelop</tt>

If your sources do not have monodevelop, you can install using the following (from [http://www.mono-project.com/Other_Downloads Mono Project])

You can install Mono 1.9.1 and MonoDevelop 1.0 by using apt or aptitude from the debian.meebey.net/etch-backports repository. This repository is driven by the official package maintainer of the Debian Mono packages. This repository is also known to work for Ubuntu/Gutsy.

Add this line to your /etc/apt/sources.list file:

<tt>deb http://debian.meebey.net/etch-backports /</tt>

And then install or upgrade your Mono and MonoDevelop using:

<tt>apt-get update && apt-get dist-upgrade</tt>

or

<tt>apt-get update && apt-get install monodevelop</tt>

For Fedora 9, you can install the monodevelop package via the following command in terminal (as root):

<tt>yum install monodevelop</tt>

Please be aware that monodevelop has a slew of dependencies! Also, if you are interested in additional programming plugins, you might find them in your distribution's repository. If they are not there, you can also add them in the monodevelop GUI under the Add-in Manager in Tools.

=== From Source ===
Depending on your distribution of Linux, you may need to install monodevelop from source. However, it is important that you check the main site for packages. Both the available packages and sources can be found at http://www.monodevelop.com/Download (the official download site). In order to install monodevelop from source, download the appropriate file and extract the contents to a folder of your choosing. After you have extracted the files, execute the following command:

<tt> ./configure && make && make install </tt>

There are numerous problems that may occur during this process (as with any build), according to public forums. We will work to keep an updated archive of fixes as they are discovered. Anyone who is familiar with these issues may also amend this document openly.

=== monodevelop 2.0 ===

Monodevelop 2.0 works and will compile OpenSim, which will then run under mono 2.0. However, it is a tremendous hassle to build. If you need monodevelop 2.0 you should look after Ubuntu 9.04 or OpenSuse.

=== In a Virtual Machine ===
Another option, if you don't have a Mono environment set up, is to download the pre-configured VMware virtual machine from http://www.mono-project.com/VMware_Image . It runs OpenSuSE, and is maintained by Novell (owners of SuSE). It includes monodevelop, so you can try it out without fiddling with your current environment. If you do not have VMware installed, you can download a free "VMWare Player" -- for Windows and Linux (32- and 64-bit) -- from http://vmware.com/products/player/.

== Running monodevelop ==
Running monodevelop is simple. Open your terminal and run <tt>monodevelop</tt>. However, you should keep in mind that, if your OpenSimulator directory is owned by root because you installed it with the <tt>sudo</tt> command, you might want to run monodevelop as root. This will allow you to save your files without any annoying write-errors.

'''It is worth remembering that running OpenSimulator as root is a really, really, really, really bad idea and you should just chown it to your user account instead of following the above caveat.'''

== Creating a workspace ==
To create a projectfile, you must run the prebuild.sh/.bat, and nant. This creates opensim.sln, which you can import into monoDevelop.

== Known Issues ==

=== Error: I can't open the solution? ===
One common error you might encounter when attempting to open the OpenSimulator source is:

<tt>... can not be saved, because the source file can not be read.</tt>

Answer: Native support for Visual Studio 2005 solutions/projects is required to view/edit the OpenSimulator source. You will need to obtain version 0.13 or higher. Please be sure to check your repository for the latest release. In some cases, the provided version may be too old. For Ubuntu users, the feisty repository contains version 0.12 of monodevelop. You will need to install a newer version from source or find another repository to update the package.

=== Ubuntu Users: Update to Version 0.13 ===
The following repository contains Ubuntu updates for mono and monodevelop:

deb http://www.viraptor.info/repo feisty-custombackports contrib

You can add this source under the Third-Party Software tab in your Software Source manager under System>Administration. After it has been added, you can run your Synaptic Package Manager to update your files manually if you desire. You may be prompted to update through the auto-updater. You can also manually add this repository in your terminal by adding the address to the bottom of /etc/apt/sources.list and executing the following command:

<tt>sudo aptitude update && sudo aptitude upgrade</tt>

== The Future of monodevelop ==
Given some time, monodevelop could prove useful in the future development of OpenSimulator. However, more research must be done on the program itself to determine this. This is the primary reason that I created this entry and I'm hoping for more contributions. Some of us are working to integrate more features into monodevelop, but for now, VS2005 is the optimal choice.

* I hope this documents helps. Please feel free to update/modify this entry as needed.
* Note: I have been using Monodevelop 0.19 to work with OpenSimulator without any major problems! -- Matth

[[Category:Development]]

Monodevelop

2012-04-05T02:42:01Z

BlueWall: Undo revision 29489 by BlueWall (talk)

__NOTOC__
{{Quicklinks}}
<br />

= What is monodevelop? =
Most of us already know that it is more convenient to view/edit the OpenSimulator source in Visual Studio 2005 C# Express on Windows. However, for those of us who don't have access to Windows, monodevelop is the most suitable equivalent and remains one of the best candidate for .NET programming on Linux systems. If you are planning to work with the source on any Linux system, monodevelop and kdevelop are both capable of viewing/editing C# solutions/projects. However, support for monodevelop is somewhat limited and it does not have the same features as VS2005 C# Express. If you have an available Windows system - use Visual Studio.

* Lastest Release: monodevelop 2.0
* Official Site: [http://monodevelop.com/ MonoDevelop official site]

== Installation ==

=== From Package ===
For Debian-based Linux distributions, you can install the monodevelop package via the following command in terminal:

<tt>sudo aptitude install monodevelop</tt>

If your sources do not have monodevelop, you can install using the following (from [http://www.mono-project.com/Other_Downloads Mono Project])

You can install Mono 1.9.1 and MonoDevelop 1.0 by using apt or aptitude from the debian.meebey.net/etch-backports repository. This repository is driven by the official package maintainer of the Debian Mono packages. This repository is also known to work for Ubuntu/Gutsy.

Add this line to your /etc/apt/sources.list file:

<tt>deb http://debian.meebey.net/etch-backports /</tt>

And then install or upgrade your Mono and MonoDevelop using:

<tt>apt-get update && apt-get dist-upgrade</tt>

or

<tt>apt-get update && apt-get install monodevelop</tt>

For Fedora 9, you can install the monodevelop package via the following command in terminal (as root):

<tt>yum install monodevelop</tt>

Please be aware that monodevelop has a slew of dependencies! Also, if you are interested in additional programming plugins, you might find them in your distribution's repository. If they are not there, you can also add them in the monodevelop GUI under the Add-in Manager in Tools.

=== From Source ===
Depending on your distribution of Linux, you may need to install monodevelop from source. However, it is important that you check the main site for packages. Both the available packages and sources can be found at http://www.monodevelop.com/Download (the official download site). In order to install monodevelop from source, download the appropriate file and extract the contents to a folder of your choosing. After you have extracted the files, execute the following command:

<tt> ./configure && make && make install </tt>

There are numerous problems that may occur during this process (as with any build), according to public forums. We will work to keep an updated archive of fixes as they are discovered. Anyone who is familiar with these issues may also amend this document openly.

=== monodevelop 2.0 ===

Monodevelop 2.0 works and will compile OpenSim, which will then run under mono 2.0. However, it is a tremendous hassle to build. If you need monodevelop 2.0 you should look after Ubuntu 9.04 or OpenSuse.

=== In a Virtual Machine ===
Another option, if you don't have a Mono environment set up, is to download the pre-configured VMware virtual machine from http://www.mono-project.com/VMware_Image . It runs OpenSuSE, and is maintained by Novell (owners of SuSE). It includes monodevelop, so you can try it out without fiddling with your current environment. If you do not have VMware installed, you can download a free "VMWare Player" -- for Windows and Linux (32- and 64-bit) -- from http://vmware.com/products/player/.

== Running monodevelop ==
Running monodevelop is simple. Open your terminal and run <tt>monodevelop</tt>. However, you should keep in mind that, if your OpenSimulator directory is owned by root because you installed it with the <tt>sudo</tt> command, you might want to run monodevelop as root. This will allow you to save your files without any annoying write-errors.

'''It is worth remembering that running OpenSimulator as root is a really, really, really, really bad idea and you should just chown it to your user account instead of following the above caveat.'''

== Creating a workspace ==
To create a projectfile, you must run the prebuild.sh/.bat, and nant. This creates opensim.sln, which you can import into monoDevelop.

== Known Issues ==

=== Error: I can't open the solution? ===
One common error you might encounter when attempting to open the OpenSimulator source is:

<tt>... can not be saved, because the source file can not be read.</tt>

Answer: Native support for Visual Studio 2005 solutions/projects is required to view/edit the OpenSimulator source. You will need to obtain version 0.13 or higher. Please be sure to check your repository for the latest release. In some cases, the provided version may be too old. For Ubuntu users, the feisty repository contains version 0.12 of monodevelop. You will need to install a newer version from source or find another repository to update the package.

=== Ubuntu Users: Update to Version 0.13 ===
The following repository contains Ubuntu updates for mono and monodevelop:

deb http://www.viraptor.info/repo feisty-custombackports contrib

You can add this source under the Third-Party Software tab in your Software Source manager under System>Administration. After it has been added, you can run your Synaptic Package Manager to update your files manually if you desire. You may be prompted to update through the auto-updater. You can also manually add this repository in your terminal by adding the address to the bottom of /etc/apt/sources.list and executing the following command:

<tt>sudo aptitude update && sudo aptitude upgrade</tt>

== The Future of monodevelop ==
Given some time, monodevelop could prove useful in the future development of OpenSimulator. However, more research must be done on the program itself to determine this. This is the primary reason that I created this entry and I'm hoping for more contributions. Some of us are working to integrate more features into monodevelop, but for now, VS2005 is the optimal choice.

* I hope this documents helps. Please feel free to update/modify this entry as needed.
* Note: I have been using Monodevelop 0.19 to work with OpenSimulator without any major problems! -- Matth

[[Category:Development]]

Monodevelop

2012-04-05T02:40:11Z

BlueWall: /* What is monodevelop? */

__NOTOC__
{{Quicklinks}}
<br />

Note: The information in this page is outdated. Monodevelop has matured quite a bit since this writing and is at version 2.8.8.4.

'''Note:''' The information on this page is dated. Monodevelop is at release 2.8.8.4 and has matured quite a bit since this writing.

= What is monodevelop? =
Most of us already know that it is more convenient to view/edit the OpenSimulator source in Visual Studio 2005 C# Express on Windows. However, for those of us who don't have access to Windows, monodevelop is the most suitable equivalent and remains one of the best candidate for .NET programming on Linux systems. If you are planning to work with the source on any Linux system, monodevelop and kdevelop are both capable of viewing/editing C# solutions/projects. However, support for monodevelop is somewhat limited and it does not have the same features as VS2005 C# Express. If you have an available Windows system - use Visual Studio.

* Lastest Release: monodevelop 2.0
* Official Site: [http://monodevelop.com/ MonoDevelop official site]

== Installation ==

=== From Package ===
For Debian-based Linux distributions, you can install the monodevelop package via the following command in terminal:

<tt>sudo aptitude install monodevelop</tt>

If your sources do not have monodevelop, you can install using the following (from [http://www.mono-project.com/Other_Downloads Mono Project])

You can install Mono 1.9.1 and MonoDevelop 1.0 by using apt or aptitude from the debian.meebey.net/etch-backports repository. This repository is driven by the official package maintainer of the Debian Mono packages. This repository is also known to work for Ubuntu/Gutsy.

Add this line to your /etc/apt/sources.list file:

<tt>deb http://debian.meebey.net/etch-backports /</tt>

And then install or upgrade your Mono and MonoDevelop using:

<tt>apt-get update && apt-get dist-upgrade</tt>

or

<tt>apt-get update && apt-get install monodevelop</tt>

For Fedora 9, you can install the monodevelop package via the following command in terminal (as root):

<tt>yum install monodevelop</tt>

Please be aware that monodevelop has a slew of dependencies! Also, if you are interested in additional programming plugins, you might find them in your distribution's repository. If they are not there, you can also add them in the monodevelop GUI under the Add-in Manager in Tools.

=== From Source ===
Depending on your distribution of Linux, you may need to install monodevelop from source. However, it is important that you check the main site for packages. Both the available packages and sources can be found at http://www.monodevelop.com/Download (the official download site). In order to install monodevelop from source, download the appropriate file and extract the contents to a folder of your choosing. After you have extracted the files, execute the following command:

<tt> ./configure && make && make install </tt>

There are numerous problems that may occur during this process (as with any build), according to public forums. We will work to keep an updated archive of fixes as they are discovered. Anyone who is familiar with these issues may also amend this document openly.

=== monodevelop 2.0 ===

Monodevelop 2.0 works and will compile OpenSim, which will then run under mono 2.0. However, it is a tremendous hassle to build. If you need monodevelop 2.0 you should look after Ubuntu 9.04 or OpenSuse.

=== In a Virtual Machine ===
Another option, if you don't have a Mono environment set up, is to download the pre-configured VMware virtual machine from http://www.mono-project.com/VMware_Image . It runs OpenSuSE, and is maintained by Novell (owners of SuSE). It includes monodevelop, so you can try it out without fiddling with your current environment. If you do not have VMware installed, you can download a free "VMWare Player" -- for Windows and Linux (32- and 64-bit) -- from http://vmware.com/products/player/.

== Running monodevelop ==
Running monodevelop is simple. Open your terminal and run <tt>monodevelop</tt>. However, you should keep in mind that, if your OpenSimulator directory is owned by root because you installed it with the <tt>sudo</tt> command, you might want to run monodevelop as root. This will allow you to save your files without any annoying write-errors.

'''It is worth remembering that running OpenSimulator as root is a really, really, really, really bad idea and you should just chown it to your user account instead of following the above caveat.'''

== Creating a workspace ==
To create a projectfile, you must run the prebuild.sh/.bat, and nant. This creates opensim.sln, which you can import into monoDevelop.

== Known Issues ==

=== Error: I can't open the solution? ===
One common error you might encounter when attempting to open the OpenSimulator source is:

<tt>... can not be saved, because the source file can not be read.</tt>

Answer: Native support for Visual Studio 2005 solutions/projects is required to view/edit the OpenSimulator source. You will need to obtain version 0.13 or higher. Please be sure to check your repository for the latest release. In some cases, the provided version may be too old. For Ubuntu users, the feisty repository contains version 0.12 of monodevelop. You will need to install a newer version from source or find another repository to update the package.

=== Ubuntu Users: Update to Version 0.13 ===
The following repository contains Ubuntu updates for mono and monodevelop:

deb http://www.viraptor.info/repo feisty-custombackports contrib

You can add this source under the Third-Party Software tab in your Software Source manager under System>Administration. After it has been added, you can run your Synaptic Package Manager to update your files manually if you desire. You may be prompted to update through the auto-updater. You can also manually add this repository in your terminal by adding the address to the bottom of /etc/apt/sources.list and executing the following command:

<tt>sudo aptitude update && sudo aptitude upgrade</tt>

== The Future of monodevelop ==
Given some time, monodevelop could prove useful in the future development of OpenSimulator. However, more research must be done on the program itself to determine this. This is the primary reason that I created this entry and I'm hoping for more contributions. Some of us are working to integrate more features into monodevelop, but for now, VS2005 is the optimal choice.

* I hope this documents helps. Please feel free to update/modify this entry as needed.
* Note: I have been using Monodevelop 0.19 to work with OpenSimulator without any major problems! -- Matth

[[Category:Development]]

Monodevelop

2012-04-05T02:34:59Z

BlueWall: /* What is monodevelop? */

__NOTOC__
{{Quicklinks}}
<br />

Note: The information in this page is outdated. Monodevelop has matured quite a bit since this writing and is at version 2.8.8.4.

= What is monodevelop? =
Most of us already know that it is more convenient to view/edit the OpenSimulator source in Visual Studio 2005 C# Express on Windows. However, for those of us who don't have access to Windows, monodevelop is the most suitable equivalent and remains one of the best candidate for .NET programming on Linux systems. If you are planning to work with the source on any Linux system, monodevelop and kdevelop are both capable of viewing/editing C# solutions/projects. However, support for monodevelop is somewhat limited and it does not have the same features as VS2005 C# Express. If you have an available Windows system - use Visual Studio.

* Lastest Release: monodevelop 2.0
* Official Site: [http://monodevelop.com/ MonoDevelop official site]

== Installation ==

=== From Package ===
For Debian-based Linux distributions, you can install the monodevelop package via the following command in terminal:

<tt>sudo aptitude install monodevelop</tt>

If your sources do not have monodevelop, you can install using the following (from [http://www.mono-project.com/Other_Downloads Mono Project])

You can install Mono 1.9.1 and MonoDevelop 1.0 by using apt or aptitude from the debian.meebey.net/etch-backports repository. This repository is driven by the official package maintainer of the Debian Mono packages. This repository is also known to work for Ubuntu/Gutsy.

Add this line to your /etc/apt/sources.list file:

<tt>deb http://debian.meebey.net/etch-backports /</tt>

And then install or upgrade your Mono and MonoDevelop using:

<tt>apt-get update && apt-get dist-upgrade</tt>

or

<tt>apt-get update && apt-get install monodevelop</tt>

For Fedora 9, you can install the monodevelop package via the following command in terminal (as root):

<tt>yum install monodevelop</tt>

Please be aware that monodevelop has a slew of dependencies! Also, if you are interested in additional programming plugins, you might find them in your distribution's repository. If they are not there, you can also add them in the monodevelop GUI under the Add-in Manager in Tools.

=== From Source ===
Depending on your distribution of Linux, you may need to install monodevelop from source. However, it is important that you check the main site for packages. Both the available packages and sources can be found at http://www.monodevelop.com/Download (the official download site). In order to install monodevelop from source, download the appropriate file and extract the contents to a folder of your choosing. After you have extracted the files, execute the following command:

<tt> ./configure && make && make install </tt>

There are numerous problems that may occur during this process (as with any build), according to public forums. We will work to keep an updated archive of fixes as they are discovered. Anyone who is familiar with these issues may also amend this document openly.

=== monodevelop 2.0 ===

Monodevelop 2.0 works and will compile OpenSim, which will then run under mono 2.0. However, it is a tremendous hassle to build. If you need monodevelop 2.0 you should look after Ubuntu 9.04 or OpenSuse.

=== In a Virtual Machine ===
Another option, if you don't have a Mono environment set up, is to download the pre-configured VMware virtual machine from http://www.mono-project.com/VMware_Image . It runs OpenSuSE, and is maintained by Novell (owners of SuSE). It includes monodevelop, so you can try it out without fiddling with your current environment. If you do not have VMware installed, you can download a free "VMWare Player" -- for Windows and Linux (32- and 64-bit) -- from http://vmware.com/products/player/.

== Running monodevelop ==
Running monodevelop is simple. Open your terminal and run <tt>monodevelop</tt>. However, you should keep in mind that, if your OpenSimulator directory is owned by root because you installed it with the <tt>sudo</tt> command, you might want to run monodevelop as root. This will allow you to save your files without any annoying write-errors.

'''It is worth remembering that running OpenSimulator as root is a really, really, really, really bad idea and you should just chown it to your user account instead of following the above caveat.'''

== Creating a workspace ==
To create a projectfile, you must run the prebuild.sh/.bat, and nant. This creates opensim.sln, which you can import into monoDevelop.

== Known Issues ==

=== Error: I can't open the solution? ===
One common error you might encounter when attempting to open the OpenSimulator source is:

<tt>... can not be saved, because the source file can not be read.</tt>

Answer: Native support for Visual Studio 2005 solutions/projects is required to view/edit the OpenSimulator source. You will need to obtain version 0.13 or higher. Please be sure to check your repository for the latest release. In some cases, the provided version may be too old. For Ubuntu users, the feisty repository contains version 0.12 of monodevelop. You will need to install a newer version from source or find another repository to update the package.

=== Ubuntu Users: Update to Version 0.13 ===
The following repository contains Ubuntu updates for mono and monodevelop:

deb http://www.viraptor.info/repo feisty-custombackports contrib

You can add this source under the Third-Party Software tab in your Software Source manager under System>Administration. After it has been added, you can run your Synaptic Package Manager to update your files manually if you desire. You may be prompted to update through the auto-updater. You can also manually add this repository in your terminal by adding the address to the bottom of /etc/apt/sources.list and executing the following command:

<tt>sudo aptitude update && sudo aptitude upgrade</tt>

== The Future of monodevelop ==
Given some time, monodevelop could prove useful in the future development of OpenSimulator. However, more research must be done on the program itself to determine this. This is the primary reason that I created this entry and I'm hoping for more contributions. Some of us are working to integrate more features into monodevelop, but for now, VS2005 is the optimal choice.

* I hope this documents helps. Please feel free to update/modify this entry as needed.
* Note: I have been using Monodevelop 0.19 to work with OpenSimulator without any major problems! -- Matth

[[Category:Development]]

News

2012-04-04T14:44:18Z

BlueWall: /* Project News */

{{Quicklinks}}
__NOTOC__

== Project News ==

For older release history, see [[Release Notes]].
=== March 2012 ===
* [[0.7.3.1 Release|OpenSimulator 0.7.3.1 Released]].
=== February 2012 ===
* [[0.7.3 Release|OpenSimulator 0.7.3 Released]].

=== October 2011 ===
* [[0.7.2 Release|OpenSimulator 0.7.2 released]].

=== May 2011 ===
* [[0.7.1 Release|OpenSimulator 0.7.1 released]].
* [[0.7.1.1 Release|OpenSimulator 0.7.1.1 released]].

=== August 2010 ===
* [[0.7.0.1 Release|OpenSimulator 0.7.0.1 released]].
* Long haitus on the project news wiki page ended! Folks - please feel free to add your news here.

=== January 2010 ===
-Unofficial OpenSimulator meetup - UK<br />
-Presence Refactor in testing. (Friends, SQLite and HyperGrid still need implementation in this branch) [http://opensimulator.org/viewgit/?a=shortlog&p=opensim&h=refs/heads/presence-refactor link]<br />
-We're also looking for solid documentation writing. If you're interested, please subscribe to [http://lists.berlios.de/mailman/listinfo/opensim-dev opensim-dev] and send us a letter.

=== December 2009 ===
Version 0.6.8 has been released. Source packages can be downloaded at http://dist.opensimulator.org/.

=== September 2009 ===
Version 0.6.7 has been released. Source packages can be downloaded at http://dist.opensimulator.org/.

=== August 2009 ===
OpenSimulator has moved it's source repository to git. Please see [[Using Git]] for more details about setting up git to access the source repository.
For anyone that can't use git, we're keeping a SVN mirror at http://opensimulator.org/svn/opensim-track/trunk.

Additionally, we have a viewgit for OpenSimulator at http://opensimulator.org/viewgit/?a=summary&p=opensim

=== June 2009 ===
Version 0.6.6 has been released. Source packages can be downloaded at http://dist.opensimulator.org/.

=== May 2009 ===
Starting in r9562 OpenSimulator has a set of new configuration variables that specify how services and service connectors are set up.

Please reference the [[Services and Service Connectors Configuration]] page for more information.

=== April 2009 ===
* There is a current proposal to drop Visual Studio 2005 support in OpenSimulator by end of May. Visual Studio 2008 will still be supported. If you have strong opinions on the matter, use the [[Mailing Lists|mailing lists]] to make your voice heard. (this proposal was approved)

== Press ==

=== February 2010 ===
* [http://chronicle.com/article/After-Frustrations-in-Second/64137/ 14 Feb 2010 - After Frustrations in Second Life, Colleges Look to New Virtual Worlds]
=== January 2010 ===
* [http://blog.genkii.com/2010/01/13/sparkle-im-1-3-4-released/ 13 Jan 2010 - iPhone App Sparkle IM 1.3.4 released which supports OpenSimulator grids]
* [http://realxtend.blogspot.com/2010/01/naali-01-released.html 01 Jan 2010 - RealXtend releases first RC for naali, the realXtend and OpenSimulator Viewer]
=== November 2009 ===
* [http://www.hypergridbusiness.com/2009/11/opensim-in-intel-spotlight/ 18 Nov 2009 - OpenSimulator in Intel Spotlight, Intel CTO Justin Rattner introduced OpenSimulator and ScienceSim at SC09 Super Computing Conference]
=== September 2009 ===
* [http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20090930005401&newsLang=en 30 Sept 2009 - 3Di Releases Open Source, web based viewer called Rei]
=== January 2009 ===
* [http://blogs.intel.com/research/2009/01/sciencesim.php 29 Jan 2009 - Intel Research Launches ScienceSim based on OpenSimulator]
=== September 2008 ===
* [http://www-03.ibm.com/press/us/en/pressrelease/25038.wss 03 Sep 2008 - Made in IBM Labs: IBM Moves Real-Time Communication and Collaboration Into 3-D (integrated with OpenSim)]
=== February 2008 ===
* [http://www-03.ibm.com/press/us/en/pressrelease/23565.wss 21st Feb 2008 - Made in IBM Labs: IBM 3-D Data Centers Show Virtual Worlds Fit for Business]
* [http://www.realxtend.org/realxtend_opensim_release_15_02_2008.html 15th Feb 2008 - RealXtend joins OpenSim: Team up to make open source Virtual World standard]
* [http://www.ngigroup.com/jp/press/2008/02/001264.html 5th Feb 2008 - 3Di, Inc. Creates Voice Communication Function for Its Virtual World Application "Jin-sei"]
<cleanpage title=hide cats=hide />

== RSS Feeds ==
<rss>http://planet.opensim.us/rss20.xml|max=5|short|filter=opensim</rss>
<rss>http://feeds.technorati.com/search/opensim?language=en|max=5|short</rss>
<rss>http://feeds.technorati.com/search/opensim?authority=n&language=pt|max=5|short</rss>
<rss>http://feeds.technorati.com/search/opensim?authority=n&language=es|max=5|short</rss>
<rss>http://feeds.technorati.com/search/opensim?authority=n&language=fr|max=5|short</rss>

== Blogs ==
* [http://www.worldsimterra.com WorldSimTerra (Português, English, Español)]
* [http://www.adamfrisby.com/blog/2008/08/resources-for-running-your-own-opensim Adam's OpenSimulator resources blog post] - a list of resources for running OpenSimulator
* [http://rock-vacirca.blogspot.com Rock Vacirca's Blog] - lots of tutorials, not only on OpenSim, but on MySQL, Hippo, Second Inventory, etc
* [http://justincc.wordpress.com justincc's blog] - A blog with a weekly OpenSimulator development update and regular articles on various OpenSimulator topics.
* [http://lbsa71.net/category/opensim/ lbsa71.net] - tidbits from an OpenSimulator developer.
* [http://imohax.com Mo Hax] - posts and videos about OpenSimulator and Second Life from beginner perspective, focus on content previewing and educational use '''(No Page Information available)'''
* [http://www.metaverse3d.com/tag/opensim/ Metaverse3d] - French blog about metaverse and OpenSimulator.
* [http://www.subwereld.nl/ Subwereld] - A Dutch weblog about the OpenSimulator Project, the virtual world grids and OpenSimulator tools. '''(URI going to 404 Error)'''
* [http://maxping.org/ Maxping] - A web magazine that writes about open source virtual worlds. '''(Verify URI / Domain, no informations available)'''
* [http://blog.cyberlandia.net/ Cyberlandia Blog] - Italian blog about Opensim, hypergrid and virtual worlds '''(Blog never available)'''
* [http://b5od.com/?tag=/opensimulator b5od Teravus Misc Blog] - Teravus' technology blog about .NET, OpenSimulator, Security and other topics (OpenSimulator Tag) '''(Blogsystem in Maintenance-Modus for a long time)'''

News

2012-03-11T14:48:15Z

BlueWall: /* Project News */

{{Quicklinks}}
__NOTOC__

== Project News ==

For older release history, see [[Release Notes]].
=== February 2012 ===
* [[0.7.3 Release|OpenSimulator 0.7.3 Released]].

=== October 2011 ===
* [[0.7.2 Release|OpenSimulator 0.7.2 released]].

=== May 2011 ===
* [[0.7.1 Release|OpenSimulator 0.7.1 released]].
* [[0.7.1.1 Release|OpenSimulator 0.7.1.1 released]].

=== August 2010 ===
* [[0.7.0.1 Release|OpenSimulator 0.7.0.1 released]].
* Long haitus on the project news wiki page ended! Folks - please feel free to add your news here.

=== January 2010 ===
-Unofficial OpenSimulator meetup - UK<br />
-Presence Refactor in testing. (Friends, SQLite and HyperGrid still need implementation in this branch) [http://opensimulator.org/viewgit/?a=shortlog&p=opensim&h=refs/heads/presence-refactor link]<br />
-We're also looking for solid documentation writing. If you're interested, please subscribe to [http://lists.berlios.de/mailman/listinfo/opensim-dev opensim-dev] and send us a letter.

=== December 2009 ===
Version 0.6.8 has been released. Source packages can be downloaded at http://dist.opensimulator.org/.

=== September 2009 ===
Version 0.6.7 has been released. Source packages can be downloaded at http://dist.opensimulator.org/.

=== August 2009 ===
OpenSimulator has moved it's source repository to git. Please see [[Using Git]] for more details about setting up git to access the source repository.
For anyone that can't use git, we're keeping a SVN mirror at http://opensimulator.org/svn/opensim-track/trunk.

Additionally, we have a viewgit for OpenSimulator at http://opensimulator.org/viewgit/?a=summary&p=opensim

=== June 2009 ===
Version 0.6.6 has been released. Source packages can be downloaded at http://dist.opensimulator.org/.

=== May 2009 ===
Starting in r9562 OpenSimulator has a set of new configuration variables that specify how services and service connectors are set up.

Please reference the [[Services and Service Connectors Configuration]] page for more information.

=== April 2009 ===
* There is a current proposal to drop Visual Studio 2005 support in OpenSimulator by end of May. Visual Studio 2008 will still be supported. If you have strong opinions on the matter, use the [[Mailing Lists|mailing lists]] to make your voice heard. (this proposal was approved)

== Press ==

=== February 2010 ===
* [http://chronicle.com/article/After-Frustrations-in-Second/64137/ 14 Feb 2010 - After Frustrations in Second Life, Colleges Look to New Virtual Worlds]
=== January 2010 ===
* [http://blog.genkii.com/2010/01/13/sparkle-im-1-3-4-released/ 13 Jan 2010 - iPhone App Sparkle IM 1.3.4 released which supports OpenSimulator grids]
* [http://realxtend.blogspot.com/2010/01/naali-01-released.html 01 Jan 2010 - RealXtend releases first RC for naali, the realXtend and OpenSimulator Viewer]
=== November 2009 ===
* [http://www.hypergridbusiness.com/2009/11/opensim-in-intel-spotlight/ 18 Nov 2009 - OpenSimulator in Intel Spotlight, Intel CTO Justin Rattner introduced OpenSimulator and ScienceSim at SC09 Super Computing Conference]
=== September 2009 ===
* [http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20090930005401&newsLang=en 30 Sept 2009 - 3Di Releases Open Source, web based viewer called Rei]
=== January 2009 ===
* [http://blogs.intel.com/research/2009/01/sciencesim.php 29 Jan 2009 - Intel Research Launches ScienceSim based on OpenSimulator]
=== September 2008 ===
* [http://www-03.ibm.com/press/us/en/pressrelease/25038.wss 03 Sep 2008 - Made in IBM Labs: IBM Moves Real-Time Communication and Collaboration Into 3-D (integrated with OpenSim)]
=== February 2008 ===
* [http://www-03.ibm.com/press/us/en/pressrelease/23565.wss 21st Feb 2008 - Made in IBM Labs: IBM 3-D Data Centers Show Virtual Worlds Fit for Business]
* [http://www.realxtend.org/realxtend_opensim_release_15_02_2008.html 15th Feb 2008 - RealXtend joins OpenSim: Team up to make open source Virtual World standard]
* [http://www.ngigroup.com/jp/press/2008/02/001264.html 5th Feb 2008 - 3Di, Inc. Creates Voice Communication Function for Its Virtual World Application "Jin-sei"]
<cleanpage title=hide cats=hide />

== RSS Feeds ==
<rss>http://planet.opensim.us/rss20.xml|max=5|short|filter=opensim</rss>
<rss>http://feeds.technorati.com/search/opensim?language=en|max=5|short</rss>
<rss>http://feeds.technorati.com/search/opensim?authority=n&language=pt|max=5|short</rss>
<rss>http://feeds.technorati.com/search/opensim?authority=n&language=es|max=5|short</rss>
<rss>http://feeds.technorati.com/search/opensim?authority=n&language=fr|max=5|short</rss>

== Blogs ==
* [http://www.worldsimterra.com WorldSimTerra (Português, English, Español)]
* [http://www.adamfrisby.com/blog/2008/08/resources-for-running-your-own-opensim Adam's OpenSimulator resources blog post] - a list of resources for running OpenSimulator
* [http://rock-vacirca.blogspot.com Rock Vacirca's Blog] - lots of tutorials, not only on OpenSim, but on MySQL, Hippo, Second Inventory, etc
* [http://justincc.wordpress.com justincc's blog] - A blog with a weekly OpenSimulator development update and regular articles on various OpenSimulator topics.
* [http://lbsa71.net/category/opensim/ lbsa71.net] - tidbits from an OpenSimulator developer.
* [http://imohax.com Mo Hax] - posts and videos about OpenSimulator and Second Life from beginner perspective, focus on content previewing and educational use '''(No Page Information available)'''
* [http://www.metaverse3d.com/tag/opensim/ Metaverse3d] - French blog about metaverse and OpenSimulator.
* [http://www.subwereld.nl/ Subwereld] - A Dutch weblog about the OpenSimulator Project, the virtual world grids and OpenSimulator tools. '''(URI going to 404 Error)'''
* [http://maxping.org/ Maxping] - A web magazine that writes about open source virtual worlds. '''(Verify URI / Domain, no informations available)'''
* [http://blog.cyberlandia.net/ Cyberlandia Blog] - Italian blog about Opensim, hypergrid and virtual worlds '''(Blog never available)'''
* [http://b5od.com/?tag=/opensimulator b5od Teravus Misc Blog] - Teravus' technology blog about .NET, OpenSimulator, Security and other topics (OpenSimulator Tag) '''(Blogsystem in Maintenance-Modus for a long time)'''