OpenSimulator - User contributions [en]

User Documentation

2009-04-08T08:03:21Z

Sacha Magne:

{{Template:Quicklinks}}

==Initial Setup==
* [[Download]] - Download instructions
* [[Dependencies]] - The other packages you need to install that OpenSim relies upon
* [[Build Instructions]] - How to build and compile OpenSim from Source
* [[Configuration]] - How to configure your OpenSim server up and running
* [[Upgrading]] - How to upgrade your OpenSim version so that you can use your existing data
* [[Connecting]] - How to connect a compatible viewer to OpenSim
* [[Troubleshooting]] - How to trouble shoot your OpenSim installation.
* [[Tips]] - Useful tips from users like you
* [[FAQ]] - Frequently Asked Questions

==Administrator Guide==
* [[Server Commands]] - Commands to control OpenSim
* [[OpenSim Database support]] - Dealing with databases
* [[Logging]] - Logging in OpenSim
* [[Custom Libraries]] - Describes how to add custom content to your OpenSim server
* [[Automating Tasks]] - How to make administrating a walk in the park
* [[Network Settings]] - NAT, Ports, Services and more...
* [[Management]] - All about being an effective administrator/moderator
* [[Performance]] - How to tweak OpenSim's performance
* [[Console-less OpenSim]] - How to run OpenSim without console

==Core Facilities==
* [[OpenSim Archives]] - Loading and saving whole region archives with OpenSim
* [[IRCBridgeModule]] - A core OpenSim module for integrating IRC with a simulator.
* [[Hypergrid]] - Information about how to configure the experimental hypergrid architecture
* [[GridInfo]] - how to provide information about your grid to smart clients

==RealXtend==
* [[ModRex]] - How to setup the RealXtend server module
* [[RealXtend Viewer Linux]] - This tutorial describes how to use the RealXtend viewer on Linux, using wine

==Scripting==
* [[Scripting Documentation]] - Everything you need to know about OpenSim scripting
* [[Scripting Library]] - A list of example scripts

==Tutorials==
===Platform specific===
* [[Linux Gridserver, the ubuntu way]] the quick and dirty way to install opensim under ubuntu (Linux)
* [[Wiimote]] - How to use a wiimote/nunchuk controller with the OpenSim viewer (Linux)
* [[Cacti]] - Generate Serverstats using the Cacti-Tool and SNMP (Linux)
* [http://sunredbeach.com/dokuwiki/doku.php?id=opensim:minimal-server Installing an openSUSE 11.1 Minimal server setup for an OpenSim server] - Quick and Dirty setup on an openSUSE 11.1 server

* [http://chapter-and-metaverse.blogspot.com Chapter & Metaverse] - Full suite of tutorials, tips and tricks, for the Windows user (Windows)

===Cross-platform===
* [[OSGrid Region Registration]] - Describes how to link your region into OS-Grid
* [[Hints & Tricks]] - A page for Hints and Tricks
* [[Getting Started with Region Modules]] - The Hello World of OpenSim application development
* [[Building a bot]] - Getting started with bot design using libomv from the client side.
* [[pCampBot]] - Physical OpenSim bots
* [[Using L3DT]] - How to create custom terrains
* [[Detailed cross-region terrain making]] - A workflow for creating large cross-region custom terrains
* [http://update.multiverse.net/wiki/index.php/About_Terrain How to make a good Terrain (includes 4 programs to use)]

==Gforge Projects==
* [[OpenSimSearch]] - Search for your OpenSim
* [[Linux Gridserver]] - Linux Gridserver using the Moo tool
* [[Wixtd|WiXTD]] - Setup and usage of the WiXTD metaverse-portal
* [[ServerStats]] - RRD/Proc serverstats using the OpenSim module for Berlios Serverstats (Linux)
* [[JabberBridge]] - Jabber/Xmpp bridge for opensim (currently only works properly in Standalone mode)

==Unofficial Hypernauta's Basic Manual==
* If you are a real beginner it can be for you. Talking about "personal" worlds created using domestic computers. [http://www.dmu.com/opensime LINK]

==Contribution Policy==
* [[User_Wiki_Conventions|User Wiki Conventions]] - Read this carefully, before adding content to the wiki

[[Category:Users]]
<cleanpage title=hide cats=hide />

User Documentation

2009-04-08T07:37:49Z

Sacha Magne: Add monit (sm) wip

{{Template:Quicklinks}}

==Initial Setup==
* [[Download]] - Download instructions
* [[Dependencies]] - The other packages you need to install that OpenSim relies upon
* [[Build Instructions]] - How to build and compile OpenSim from Source
* [[Configuration]] - How to configure your OpenSim server up and running
* [[Upgrading]] - How to upgrade your OpenSim version so that you can use your existing data
* [[Connecting]] - How to connect a compatible viewer to OpenSim
* [[Troubleshooting]] - How to trouble shoot your OpenSim installation.
* [[Tips]] - Useful tips from users like you
* [[FAQ]] - Frequently Asked Questions

==Administrator Guide==
* [[Server Commands]] - Commands to control OpenSim
* [[OpenSim Database support]] - Dealing with databases
* [[Logging]] - Logging in OpenSim
* [[Custom Libraries]] - Describes how to add custom content to your OpenSim server
* [[Automating Tasks]] - How to make administrating a walk in the park
* [[Network Settings]] - NAT, Ports, Services and more...
* [[Management]] - All about being an effective administrator/moderator
* [[Performance]] - How to tweak OpenSim's performance
* [[Console-less OpenSim]] - How to run OpenSim without console
* [[Monit]] - Monit, the GridWay (Linux and Monit)

==Core Facilities==
* [[OpenSim Archives]] - Loading and saving whole region archives with OpenSim
* [[IRCBridgeModule]] - A core OpenSim module for integrating IRC with a simulator.
* [[Hypergrid]] - Information about how to configure the experimental hypergrid architecture
* [[GridInfo]] - how to provide information about your grid to smart clients

==RealXtend==
* [[ModRex]] - How to setup the RealXtend server module
* [[RealXtend Viewer Linux]] - This tutorial describes how to use the RealXtend viewer on Linux, using wine

==Scripting==
* [[Scripting Documentation]] - Everything you need to know about OpenSim scripting
* [[Scripting Library]] - A list of example scripts

==Tutorials==
===Platform specific===
* [[Linux Gridserver, the ubuntu way]] the quick and dirty way to install opensim under ubuntu (Linux)
* [[Wiimote]] - How to use a wiimote/nunchuk controller with the OpenSim viewer (Linux)
* [[Cacti]] - Generate Serverstats using the Cacti-Tool and SNMP (Linux)
* [http://sunredbeach.com/dokuwiki/doku.php?id=opensim:minimal-server Installing an openSUSE 11.1 Minimal server setup for an OpenSim server] - Quick and Dirty setup on an openSUSE 11.1 server

* [http://chapter-and-metaverse.blogspot.com Chapter & Metaverse] - Full suite of tutorials, tips and tricks, for the Windows user (Windows)

===Cross-platform===
* [[OSGrid Region Registration]] - Describes how to link your region into OS-Grid
* [[Hints & Tricks]] - A page for Hints and Tricks
* [[Getting Started with Region Modules]] - The Hello World of OpenSim application development
* [[Building a bot]] - Getting started with bot design using libomv from the client side.
* [[pCampBot]] - Physical OpenSim bots
* [[Using L3DT]] - How to create custom terrains
* [[Detailed cross-region terrain making]] - A workflow for creating large cross-region custom terrains
* [http://update.multiverse.net/wiki/index.php/About_Terrain How to make a good Terrain (includes 4 programs to use)]

==Gforge Projects==
* [[OpenSimSearch]] - Search for your OpenSim
* [[Linux Gridserver]] - Linux Gridserver using the Moo tool
* [[Wixtd|WiXTD]] - Setup and usage of the WiXTD metaverse-portal
* [[ServerStats]] - RRD/Proc serverstats using the OpenSim module for Berlios Serverstats (Linux)
* [[JabberBridge]] - Jabber/Xmpp bridge for opensim (currently only works properly in Standalone mode)

==Unofficial Hypernauta's Basic Manual==
* If you are a real beginner it can be for you. Talking about "personal" worlds created using domestic computers. [http://www.dmu.com/opensime LINK]

==Contribution Policy==
* [[User_Wiki_Conventions|User Wiki Conventions]] - Read this carefully, before adding content to the wiki

[[Category:Users]]
<cleanpage title=hide cats=hide />

Download

2009-02-21T15:18:14Z

Sacha Magne:

{{Template:Quicklinks}}
==Source code==
Here are the current released versions of OpenSim.

Please see [[Branches]] for more information on the repository branches and what they are for.

'''Please note:''' As OpenSim is still at an alpha code maturity stage, there is absolutely no guarantee that functionality works or is stable, even in the numbered releases. Certain features may not work either because the code is in rapid evolution, or because functionality expected by the Linden Labs Second Life viewer has simply not been implemented yet. However, constructive feedback is still welcomed.

Also, please be aware that OpenSim requires that you have a fair amount of technical knowledge in order to set it up.

You may need to use the Subversion source code management system to obtain the code. For Windows you can install just [http://subversion.tigris.org/servlets/NewsItemView?newsItemID=1941 Subversion] or the often preferred [http://tortoisesvn.tigris.org Tortoise Subversion extension]. Mac OS X 10.l5 and above have Subversion built but OS. X 10.4.x can still [http://homepage.mac.com/martinott/Subversion-1.4.4.pkg.zip download Subversion].

* '''0.6.3 Alpha release''' (r8540) **** USE 0.6.3 POSTFIXES ****
svn co http://opensimulator.org/svn/opensim/tags/0.6.3-release opensim

* '''0.6.3 Alpha with post-release fixes''' (r8542)
svn co http://opensimulator.org/svn/opensim/branches/0.6.3-post-fixes opensim

* '''0.6.2 Alpha release''' (r8068)
svn co http://opensimulator.org/svn/opensim/tags/0.6.2-release opensim

* '''0.6.1 Alpha release''' (r7840)
svn co http://opensimulator.org/svn/opensim/tags/0.6.1-release opensim

* '''0.6.1 Alpha with post-release fixes'''
svn co http://opensimulator.org/svn/opensim/branches/0.6.1-post-fixes opensim

* '''0.6.0 Alpha release''' (r7471)
svn co http://opensimulator.org/svn/opensim/tags/0.6.0-release opensim

* '''Latest Subversion revision version (bleeding edge)'''
svn co http://opensimulator.org/svn/opensim/trunk opensim

Another option for obtaining the code is via [http://www.selenic.com/mercurial/wiki/ mercurial] from the [http://opensimulator.org/hg/opensim-trunk/ OpenSim repository].

* '''Latest mercurial revision version (bleeding edge)'''
hg clone http://opensimulator.org/hg/opensim-trunk/ opensim

==Binaries==
==Installers==

* '''Official 0.6.2 Windows Installer'''
http://forge.opensimulator.org/gf/download/frsrelease/157/359/OpenSimSetup0.6.2.exe

* '''Official 0.6.1 Windows Installer'''
http://forge.opensimulator.org/gf/download/frsrelease/147/318/OpenSimSetup0.6.1.exe

* '''Official 0.6 Windows Installer''' Not Valid for OSGrid Nov 30 2008
http://forge.opensimulator.org/gf/download/frsrelease/137/251/OpenSimSetup0.6.exe

* '''[[UnofficialDebPackages|Unofficial .deb packages]]

==Packages==
* '''0.6.2 release''' (thanks to the OSGrid team, and especially Nebadon)
http://dist.opensimulator.org/OpenSimulator.v0.6.2.8068.zip

* '''0.6.1 release''' (thanks to the OSGrid team)
http://dist.opensimulator.org/opensim.v0.6.1.7840.zip

* '''0.6.0 release''' (thanks to the OSGrid team)
http://osgrid.org/download/osgrid.opensim.v0.6.0.7471.zip

* '''Official Nightly Build Binary (Recommended for quick testing)
http://builds.opensimulator.org

==Related Software==
[[Related_Software|Related Software Section - CLICK HERE]] 

''Pages by Category:''[[:Category:Users| User-pages]],[[:Category:Development| Developer-pages]],[[:Category:Scripts| Scripts]] 

[[Category:Users]]
[[Category:Developers]]
<cleanpage title=hide cats=hide />

Download

2009-02-21T13:39:28Z

Sacha Magne:

{{Template:Quicklinks}}
==Source code==
Here are the current released versions of OpenSim.

Please see [[Branches]] for more information on the repository branches and what they are for.

'''Please note:''' As OpenSim is still at an alpha code maturity stage, there is absolutely no guarantee that functionality works or is stable, even in the numbered releases. Certain features may not work either because the code is in rapid evolution, or because functionality expected by the Linden Labs Second Life viewer has simply not been implemented yet. However, constructive feedback is still welcomed.

Also, please be aware that OpenSim requires that you have a fair amount of technical knowledge in order to set it up.

You may need to use the Subversion source code management system to obtain the code. For Windows you can install just [http://subversion.tigris.org/servlets/NewsItemView?newsItemID=1941 Subversion] or the often preferred [http://tortoisesvn.tigris.org Tortoise Subversion extension]. Mac OS X 10.l5 and above have Subversion built but OS. X 10.4.x can still [http://homepage.mac.com/martinott/Subversion-1.4.4.pkg.zip download Subversion].

* '''0.6.3 Alpha release''' (r8540)
svn co http://opensimulator.org/svn/opensim/tags/0.6.3-release opensim

* '''0.6.3 Alpha with post-release fixes''' (r8542)
svn co http://opensimulator.org/svn/opensim/branches/0.6.3-post-fixes opensim

* '''0.6.2 Alpha release''' (r8068)
svn co http://opensimulator.org/svn/opensim/tags/0.6.2-release opensim

* '''0.6.1 Alpha release''' (r7840)
svn co http://opensimulator.org/svn/opensim/tags/0.6.1-release opensim

* '''0.6.1 Alpha with post-release fixes'''
svn co http://opensimulator.org/svn/opensim/branches/0.6.1-post-fixes opensim

* '''0.6.0 Alpha release''' (r7471)
svn co http://opensimulator.org/svn/opensim/tags/0.6.0-release opensim

* '''Latest Subversion revision version (bleeding edge)'''
svn co http://opensimulator.org/svn/opensim/trunk opensim

Another option for obtaining the code is via [http://www.selenic.com/mercurial/wiki/ mercurial] from the [http://opensimulator.org/hg/opensim-trunk/ OpenSim repository].

* '''Latest mercurial revision version (bleeding edge)'''
hg clone http://opensimulator.org/hg/opensim-trunk/ opensim

==Binaries==
==Installers==

* '''Official 0.6.2 Windows Installer'''
http://forge.opensimulator.org/gf/download/frsrelease/157/359/OpenSimSetup0.6.2.exe

* '''Official 0.6.1 Windows Installer'''
http://forge.opensimulator.org/gf/download/frsrelease/147/318/OpenSimSetup0.6.1.exe

* '''Official 0.6 Windows Installer''' Not Valid for OSGrid Nov 30 2008
http://forge.opensimulator.org/gf/download/frsrelease/137/251/OpenSimSetup0.6.exe

* '''[[UnofficialDebPackages|Unofficial .deb packages]]

==Packages==
* '''0.6.2 release''' (thanks to the OSGrid team, and especially Nebadon)
http://dist.opensimulator.org/OpenSimulator.v0.6.2.8068.zip

* '''0.6.1 release''' (thanks to the OSGrid team)
http://dist.opensimulator.org/opensim.v0.6.1.7840.zip

* '''0.6.0 release''' (thanks to the OSGrid team)
http://osgrid.org/download/osgrid.opensim.v0.6.0.7471.zip

* '''Official Nightly Build Binary (Recommended for quick testing)
http://builds.opensimulator.org

==Related Software==
[[Related_Software|Related Software Section - CLICK HERE]] 

''Pages by Category:''[[:Category:Users| User-pages]],[[:Category:Development| Developer-pages]],[[:Category:Scripts| Scripts]] 

[[Category:Users]]
[[Category:Developers]]
<cleanpage title=hide cats=hide />

Download

2009-02-21T10:37:54Z

Sacha Magne:

{{Template:Quicklinks}}
==Source code==
Here are the current released versions of OpenSim.

Please see [[Branches]] for more information on the repository branches and what they are for.

'''Please note:''' As OpenSim is still at an alpha code maturity stage, there is absolutely no guarantee that functionality works or is stable, even in the numbered releases. Certain features may not work either because the code is in rapid evolution, or because functionality expected by the Linden Labs Second Life viewer has simply not been implemented yet. However, constructive feedback is still welcomed.

Also, please be aware that OpenSim requires that you have a fair amount of technical knowledge in order to set it up.

You may need to use the Subversion source code management system to obtain the code. For Windows you can install just [http://subversion.tigris.org/servlets/NewsItemView?newsItemID=1941 Subversion] or the often preferred [http://tortoisesvn.tigris.org Tortoise Subversion extension]. Mac OS X 10.l5 and above have Subversion built but OS. X 10.4.x can still [http://homepage.mac.com/martinott/Subversion-1.4.4.pkg.zip download Subversion].

* '''0.6.3 Alpha release''' (r8540)
svn co http://opensimulator.org/svn/opensim/tags/0.6.3-release opensim

* '''0.6.2 Alpha release''' (r8068)
svn co http://opensimulator.org/svn/opensim/tags/0.6.2-release opensim

* '''0.6.1 Alpha release''' (r7840)
svn co http://opensimulator.org/svn/opensim/tags/0.6.1-release opensim

* '''0.6.1 Alpha with post-release fixes'''
svn co http://opensimulator.org/svn/opensim/branches/0.6.1-post-fixes opensim

* '''0.6.0 Alpha release''' (r7471)
svn co http://opensimulator.org/svn/opensim/tags/0.6.0-release opensim

* '''Latest Subversion revision version (bleeding edge)'''
svn co http://opensimulator.org/svn/opensim/trunk opensim

Another option for obtaining the code is via [http://www.selenic.com/mercurial/wiki/ mercurial] from the [http://opensimulator.org/hg/opensim-trunk/ OpenSim repository].

* '''Latest mercurial revision version (bleeding edge)'''
hg clone http://opensimulator.org/hg/opensim-trunk/ opensim

==Binaries==
==Installers==

* '''Official 0.6.2 Windows Installer'''
http://forge.opensimulator.org/gf/download/frsrelease/157/359/OpenSimSetup0.6.2.exe

* '''Official 0.6.1 Windows Installer'''
http://forge.opensimulator.org/gf/download/frsrelease/147/318/OpenSimSetup0.6.1.exe

* '''Official 0.6 Windows Installer''' Not Valid for OSGrid Nov 30 2008
http://forge.opensimulator.org/gf/download/frsrelease/137/251/OpenSimSetup0.6.exe

* '''[[UnofficialDebPackages|Unofficial .deb packages]]

==Packages==
* '''0.6.2 release''' (thanks to the OSGrid team, and especially Nebadon)
http://dist.opensimulator.org/OpenSimulator.v0.6.2.8068.zip

* '''0.6.1 release''' (thanks to the OSGrid team)
http://dist.opensimulator.org/opensim.v0.6.1.7840.zip

* '''0.6.0 release''' (thanks to the OSGrid team)
http://osgrid.org/download/osgrid.opensim.v0.6.0.7471.zip

* '''Official Nightly Build Binary (Recommended for quick testing)
http://builds.opensimulator.org

==Related Software==
[[Related_Software|Related Software Section - CLICK HERE]] 

''Pages by Category:''[[:Category:Users| User-pages]],[[:Category:Development| Developer-pages]],[[:Category:Scripts| Scripts]] 

[[Category:Users]]
[[Category:Developers]]
<cleanpage title=hide cats=hide />

Grid Associations

2009-02-16T19:45:36Z

Sacha Magne:

This is a wiki page to draft out the idea of grid associations and eventually have a list of associations.

What is a grid association?
* A group of grid owners working together to achieve common goals.

Why have grid associations?
* Unity is power.
* Homogeneous experience with standardized quality for users that teleport between grids.
* Hyper grid technology enables grid associations linking up in world.
* Shared quality goals.
* Same grid version.
* Shared user base.
* Teaming up for 24/7 maintenance.
* Collecting improvement ideas and bugs to OpenSim dev team.
* Shared assets for grid association sharing a theme.
* Together baked terrain offering seamless map over the entire grid associations hyper grid.
* Working on contents like avatars meshes
* Mutualising ressources
* Working on databse replication (grid A /B <> B/A )

What types of grid associations there could be?
* Theme: urban, nature, rpg, scifi
* Hobby: climbing, diving
* Business
* Game

== Grids Looking for Cooperation ==

Add your grid information to this list if you are interested in joining to a grid association.

{| border="1" width="100%"
! Grid Name
! Grid Homepage
! Grid HG SLUR
! Grid Contact Email
! Cooperation Wishlist
|-
| Example Grid
| http://www.example-grid.com
| secondlife://gateway.example-grid.com:9000/
| john.smith@example-grid.com
| We are looking for a, b and c.
|}

== Grid Associations ==

If you have formed a public grid association you can add it to this list.

{| border="1" width="100%"
! Association Name
! Association Homepage
! Association HG Gateway SLUR
! Association Contact Email
! Association Member Grids
|-
| Example Association
| http://www.example-association.com
| secondlife://gateway.example-association.com:9000/
| john.smith@example-association.com
| Grid A, Grid B, Grid C
|}

Public Hypergrid Nodes

2009-02-07T10:40:22Z

Sacha Magne:

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns are addressed, we advise you to be careful about who you link to.

{| border="1" cellpadding="5" cellspacing="0" align="center"
![[Hypergrid|link-region server and port]]
!Organization
!Description
!Grid Location
|-
|'''osl2.nac.uci.edu 9006'''
|University of California, Irvine
|The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.
|OSGrid is centered at 10,000, 10,000

|-
|'''osl3.nac.uci.edu 9000'''
|University of California, Irvine
|The "UC Irvine" region connected to OSGrid, neighboring Wright Plaza. You can link to it as a way to link to OSGrid.
|OSGrid is centered at 10,000, 10,000

|-
|'''ucigrid02.nacs.uci.edu 9000'''
|University of California, Irvine
|The UCI Grid
|UCIGrid is centered at 8,888, 8,888

|-
|'''ucigrid04.nacs.uci.edu 9003'''
|University of California, Irvine
|The UCI Grid, region "Gateway 3000". Link your lower-1,000's grid to this node in order to bridge to grids in the 10,000's.
|This node is positioned at 3,000, 3,000

|-
|'''ucigrid04.nacs.uci.edu 9007'''
|University of California, Irvine
|The UCI Grid, region "Gateway 7000". Link your 10,000's grid to this node in order to bridge to grids in the lower-1,000's.
|This node is positioned at 7,000, 7,000.

|-
|'''grid.cyberlandia.net 9000'''
|Cyberlandia
|The "Cyberlandia Gw" region. http://www.cyberlandia.net Metaverso italiano 3D, more to 250 region and 1000 users. You can link to it as a way to link to Cyberlandia.
|Cyberlandia is centered at ???

|-
|'''hypergrid.cyberlandia.net 9000'''
|Cyberlandia
|The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Cyberlandia grid" You can link to it as a way to link to OSGrid.
|OSGrid is centered at 10,000, 10,000

|-
|'''regionsde.ralf-haifisch.biz 9000'''
|Ralf Haifisch on osgrid
|The "Sharkland Tropical" region connected to OSGrid. German welcome aerea, Freebie aerea, region rental, pretty tropical regions
|Centered at 10000,10000

|-
|'''joomla-italia.net 9000'''
|Social Network Italia
|The "SNI City" region connected to SNI (Social Network Italia) grid http://www.opensim-italia.net. This grid is connected with Osgrid,Collateral World,Francogrid and Darwin
|Centered at ???

|-
|'''collateral.opensim-italia.net 9000'''
|Part of Social Network Italia
|Collateral World
|Centered at ???

|-
|'''88.191.79.199 9050'''
|Francogrid
|Francogrid node, connected to "City", behind the welcome land of Francogrid "Orion"
|Centered at 1000 1000

|-
|'''94.23.8.158 9999'''
|Le Monde de Darwin
|The Lost World of Darwin http://www.LeMondedeDarwin.com. [[Image:hypergrid.jpg|200px]]
|Centered at ???

|-
|'''sg.k-grid.com 9000'''
|K-Grid
|The Kool grid for the Kool KidZ . Feel free to visit us. The main Gateway is located at 3700,3700 so take that in account before any HyperJump. Adress updated 02/07/09
|This node is located at 3700,3700

|-
|'''metropolis.hypergrid.org 9000'''
|METROPOLIS-Grid
|The Region "Center-World" (at 1000:1000) connected to the METROPOLIS-Grid http://metropolis.hypergrid.org . German Grid with a lot of free Content and free SIM-hosting. Connected via HG to the most of the Grids listed here
|Centered at 1000,1000

|-
|'''ascent.bluewallgroup.com 9910'''
|BlueWall Group
|This region is in a good proximity @ (6000,6000) for intermediate jumps to OSGrid from grids in the (2000,2000) range, or any region within 4096 units. [[Image:Hypernaut 001.png|150px|none|thumb|Get your Hypernaut here :)]]
|Centered at 6000,6000

|-
|'''sim.thestudyofracialism.org 9000'''
|Backintyme Publishing
|TSOR1 is a stand-alone sim owned by Backintyme Publishing. It connects to most of the other downrange sites listed here. The sim is intended for an SL study/discussion group's eventual migration from SL to OS.
|Centered at 4000,4000

|-
|'''pc.backintyme.com 9100'''
|Backintyme Publishing
|TSOR2 is a small teleport relay island, also owned by Backintyme Publishing, intended for jumps to the vicinity of OSGrid. It is linked to most of the uprange sites listed here.
|Centered at 8000,8000

|-
|'''24.248.172.208 9005'''
|'''MyOpenGrid'''
|Myopengrid is connected to osl2.nac.uci.edu "Osgrid Gateway" and 88.191.79.199 9050 "Franco Grid"
|Centered at 7000,7000

|-
|'''cuonsim1.de 9300'''
|Cuon-Grid
|Cuon-Grid is a little grid and has some Main Sims with linux themes, server are in Germany. To login in to the grid use this http://sim-linuxmain.org:8081/CuonGrid/index.html. There are free sims for testing.
|Centered at 10,000, 10,000

|-
|'''metaversesims.net 9014'''
|Metaverse Sims
|Standalone mode - 6 regions - linked to several other grids. [[Image:Mtvs09010101.jpg|200px]]
|Centered at 9,000, 9,000

|-
|'''mecatreco.game-host.org 9002'''
|Villa Pelopes
|Two regions,one standalone server. Member of the [http://www.dmu.com Digital Media Universe], brazilian federation of independed hypergrided worlds: [[Image:Dmu.jpg|100px]]
| 1002 1002

|-
|'''ellis.pseudospace.net 9000'''
|Pseudospace Central Gateway & Welcome Center
|Pseudospace is a free to play, public access OpenSimulator grid created to provide role players with an immersive environment by which they may play, socialize, and build within. This is a mature grid which may contain adult content and situations, only those who are 18 or older may enter.

Please be advised, that we are currently under heavy construction. Feel free to look around, but mind the mess and the occasional flying prims! If you have any questions or concerns please feel free to email john(at)pseudospace(dot)net.

All user content such as skins, attachments, textures, etc. are provided for free using a share and share alike, create for the sake of creativity methodology. All such assets are kept within the content library on Ellis Island and are freely copyable / distributable unless the "No Transfer" option is enabled which simply means that the asset may not be copied off of the grid. Individual contributions to the grid's content library are greatly welcomed and may be done so by leaving a copyable box containing your contribution on one of the shelves located inside the Ellis Library.

| 9000 9000
|-

|-
|'''ellis.pseudospace.net 9009'''
|Pseudospace Lost Gateway
|Gateway on Pseudospace grid for regions within the 5000x5000 range. - See above description for grid info.
| 5000 5000
|-

|-

|'''grid4us.net 9020'''
|Grid4Us
|German Grid that is linked to OSGrid and Francogrid.
|Centered at 8500,8500

|-
|'''gotz.ath.cx 9002'''
|Gotz
|One region,one standalone server. Visits: 9:00 PST -> 19:00 PST. Member of the
[http://www.dmu.com Digital Media Universe] , brazilian federation of independent hypergrided worlds:[[Image:Dmu.jpg|100px]]
| 1002 1002

|-
|'''87.230.89.74 9000 '''
|SCHWARZE WELT
| inworld location of www.schwarze-welle.de , the maybe biggest dark music streaming readio
| 100000 10000

|-
|'''villapileque.game-host.org 9002'''
|Villa Pileque
|One region,one standalone server. Member of the
[http://www.dmu.com Digital Media Universe] , brazilian federation of independent hypergrided worlds:[[Image:Dmu.jpg|100px]]
| 1002 1002

|-
|'''peak.sciencesim.com 9001'''
|ScienceSim
|[http://www.sciencesim.com/ ScienceSim] is a virtual world created for the high performance computing community for scientific visualizations, a number of interesting real world terrains (Mt St Helens and Yellowstone Park) and some astronomical simulations. And some useful, BSD-licensed content.
| Centered at 10000,10000

|-
|'''meanduland.com 9124'''
|Meanduland
|[http://www.meanduland.com] is a residentual only sim offering beautiful regions with low lag and friendly neighbors. Located on the hypergrid to allow easy access to OSGrid. Links to the most popular OS grids available in our Welcome Island. This grid is up 24/7 and all are welcome to drop in and and look around. If you have trouble connecting, please contact Frank Northmead or Ayana Northmead and let us know so we can help fix the problem.
| Centered at 8000,8000

|-
|'''alpha.bubblecloud.org 9000'''
|Bubble Cloud
|The alpha 00 is the entrance area to bubble cloud grid. Bubble cloud is test grid where anyone can experiment. If you build something please do it in medieval fantasy setting for others to enjoy.
|Centered at 10,000, 10,000

|-
|'''opensim.mydyn.de 9090'''
|OpenSIM.de
|[http://www.opensim.de OpenSim.de] Standalone-Testserver with 16 Regions, German Users (Deutsche Benutzer), High-End Quad-Core Rackserver with Linux Ubuntu 8.10 . Port 9090 is the M34 named Main Island. Live Support & IRC, Wiki, FAQ, Howto´s, Downloads.
|Centered at 1000,1000
|}

Hypergrid

2008-12-26T14:38:07Z

Sacha Magne:

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''. (This is also a problem with programmers who have direct access to the cache that their client keeps; in this case, the only thing that needs to be done to enable piracy is for the user to actually see a texture/animation/in-world object. This does NOT allow scripts to be copied, though, since the script is only interpreted on the server and is never sent for interpretation by the client.)

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''hypergrid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region connected to OSGrid. Search on map "cyberlandia grid" Is link to cyberlandia Italian Opensim grid. You can link to it as a way to link to Cyberlandia.

* '''hypergrid.cyberlandia.net 9300'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Osgrid grid" You can link to it as a way to link to OSGrid.

* '''joomla-italia.net 9000
The "SNI City" region connected to SNI (Social Network Italia) grid http://www.opensim-italia.net. This grid is connected with Osgrid,Collateral World,Francogrid and Darwin

* '''collateral.opensim-italia.net 9000
The "Collateral" region connected to Collateral World Grid http://collateral.opensim-italia.net. This grid is connected with Social Network Italia, Osgrid and Francogrid '''[This grid is temporarily offline for maintenance]'''

* '''88.191.79.199 9050'''
Francogrid node, connected to "City", behind the welcome land of Francogrid "Orion"

* '''94.23.8.158 9999'''
Le Monde de Darwin node, The Lost of Darwin http://www.LeMondedeDarwin.com
----
[[Image:hypergrid.jpg]]
----

* '''grid.k-grid.com 9000'''
K-grid, [http://k-grid.com the Kool grid for the Kool KidZ] . Feel free to visit us. The main Gateway is located at 3700,3700 so take that in account before any HyperJump

* '''81.169.166.109 9000'''
The Region "Center-World" (at 1000:1000) connected to the METROPOLIS-Grid http://metropolis.hypergrid.org . German Grid with a lot of free Content and free SIM-hosting. Connected via HG to the most of the Grids listed here.

* '''ascent.bluewallgroup.com 9910'''
This region is in a good proximity @ (6000,6000) for intermediate jumps to OSGrid from grids in the (2000,2000) range, or any region within 4096 units. [[Image:Hypernaut 001.png|150px|none|thumb|Get your Hypernaut here :)]]

* '''sim.thestudyofracialism.org 9000'''
TSOR is a stand-alone 2-region sim (at 8500,8500). It connects via HG to most of the other sites listed here. Although currently sparse, the sim is eventually intended for an SL discussion-group's migration from SL to OS.

* '''http://myopengrid.com 9000'''
Myopengrid is connected to osl2.nac.uci.edu "Osgrid Gateway" our regions are at (7000,7000).

Hypergrid

2008-12-26T14:36:45Z

Sacha Magne:

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''. (This is also a problem with programmers who have direct access to the cache that their client keeps; in this case, the only thing that needs to be done to enable piracy is for the user to actually see a texture/animation/in-world object. This does NOT allow scripts to be copied, though, since the script is only interpreted on the server and is never sent for interpretation by the client.)

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''hypergrid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region connected to OSGrid. Search on map "cyberlandia grid" Is link to cyberlandia Italian Opensim grid. You can link to it as a way to link to Cyberlandia.

* '''hypergrid.cyberlandia.net 9300'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Osgrid grid" You can link to it as a way to link to OSGrid.

* '''joomla-italia.net 9000
The "SNI City" region connected to SNI (Social Network Italia) grid http://www.opensim-italia.net. This grid is connected with Osgrid,Collateral World,Francogrid and Darwin

* '''collateral.opensim-italia.net 9000
The "Collateral" region connected to Collateral World Grid http://collateral.opensim-italia.net. This grid is connected with Social Network Italia, Osgrid and Francogrid '''[This grid is temporarily offline for maintenance]'''

* '''88.191.79.199 9050'''
Francogrid node, connected to "City", behind the welcome land of Francogrid "Orion"

* '''94.23.8.158 9999'''
Le Monde de Darwin node, The Lost of Darwin http://www.LeMondedeDarwin.com
----
[[Image:hypergrid.jpg]]
----

* '''grid.k-grid.com 9000'''
K-grid, [http://k-grid.net the Kool grid for the Kool KidZ] . Feel free to visit us. The main Gateway is located at 3700,3700 so take that in account before any HyperJump

* '''81.169.166.109 9000'''
The Region "Center-World" (at 1000:1000) connected to the METROPOLIS-Grid http://metropolis.hypergrid.org . German Grid with a lot of free Content and free SIM-hosting. Connected via HG to the most of the Grids listed here.

* '''ascent.bluewallgroup.com 9910'''
This region is in a good proximity @ (6000,6000) for intermediate jumps to OSGrid from grids in the (2000,2000) range, or any region within 4096 units. [[Image:Hypernaut 001.png|150px|none|thumb|Get your Hypernaut here :)]]

* '''sim.thestudyofracialism.org 9000'''
TSOR is a stand-alone 2-region sim (at 8500,8500). It connects via HG to most of the other sites listed here. Although currently sparse, the sim is eventually intended for an SL discussion-group's migration from SL to OS.

* '''http://myopengrid.com 9000'''
Myopengrid is connected to osl2.nac.uci.edu "Osgrid Gateway" our regions are at (7000,7000).

OpenWiredux: Taking the next step

2008-12-13T21:56:31Z

Sacha Magne:

As the OpenSimWiredux is in use with lots of simple grids and also some larger grids, the need to make a revamp to it was a call for freedom.

== Old version ==

== Proposed changes ==
Adding the possibility for the user to add their region with the webserver : the regionserver will get the regions's data from there (SM)
Adding RegionServer's control and report (uptime, activities, release...)

== Progress ==

OpenWiredux: Taking the next step

2008-12-07T15:49:59Z

Sacha Magne:

Hypergrid

2008-12-07T10:59:44Z

Sacha Magne:

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''.

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''hypergrid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region connected to OSGrid. Search on map "cyberlandia grid" Is link to cyberlandia Italian Opensim grid. You can link to it as a way to link to Cyberlandia.

* '''hypergrid.cyberlandia.net 9300'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Osgrid grid" You can link to it as a way to link to OSGrid.

* '''joomla-italia.net 9000
The "Accoglienza" region connected to SNI (Social Network Italia) grid http://www.opensim-italia.net. This grid is connected with Osgrid,Collateral World and Francogrid

* '''collateral.opensim-italia.net 9000
The "Collateral" region connected to Collateral World Grid http://collateral.opensim-italia.net. This grid is connected with Social Network Italia, Osgrid and Francogrid

* '''88.191.79.199 9050'''
Francogrid node, connected to "City", behind the welcome land of Francogrid "Orion"

* '''94.23.8.158 9999'''
Le Monde de Darwin node, The Lost of Darwin

* '''k-grid.net 9000'''
K-grid, [http://k-grid.net the Kool grid for the Kool KidZ] . Feel free to visit us. The main Gateway is located at 3700,3700 so take that in account before any HyperJump

Hypergrid

2008-12-07T10:48:01Z

Sacha Magne:

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''.

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''hypergrid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region connected to OSGrid. Search on map "cyberlandia grid" Is link to cyberlandia Italian Opensim grid. You can link to it as a way to link to Cyberlandia.

* '''hypergrid.cyberlandia.net 9300'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Osgrid grid" You can link to it as a way to link to OSGrid.

* '''joomla-italia.net 9000
The "Accoglienza" region connected to SNI (Social Network Italia) grid http://www.opensim-italia.net. This grid is connected with Osgrid,Collateral World and Francogrid

* '''collateral.opensim-italia.net 9000
The "Collateral" region connected to Collateral World Grid http://collateral.opensim-italia.net. This grid is connected with Social Network Italia, Osgrid and Francogrid

* '''88.191.79.199 9050'''
Francogrid node, connected to "City", behind the welcome land of Francogrid "Orion"

* '''94.23.8.158 9999'''
Le Monde de Darwin node, The Lost of Darwin

* '''k-grid.net 9000'''
K-grid, the Kool grid for the Kool KidZ. Feel free to visit us

Grid List/K-grid

2008-11-05T12:20:58Z

Sacha Magne: New page: <table border="1" cellpadding="5" cellspacing="0"> <tr> <td>Name:</td><td>K-Grid</td> </tr> <tr> <td>Website:</td><td>http://k-grid.net/ (1)</td> </tr> <tr> <td>Login...

<table border="1" cellpadding="5" cellspacing="0">
<tr>
<td>Name:</td><td>K-Grid</td>
</tr>
<tr>
<td>Website:</td><td>http://k-grid.net/ (1)</td>
</tr>
<tr>
<td>Login URI:</td><td>-loginuri http://k-grid.net:8002 -loginpage http://k-grid.net/loginpage -helperuri http://k-grid.net/ (2)</td>
</tr>
<tr>
<td>Approx # Regions</td><td>tbd</td>
</tr>
<tr>
<td>Approx # Users</td><td>tbd</td>
</tr>
<tr>
<td>Logins/day</td><td>tbd</td>
</tr>
</table>

(1) Sims are all owned by individuals.

There is no charge to connect to the grid. There is no charge for an account. Homestead land is free. This grid hold interops abilities.
(2) Updates to the Secondlife or other Client

* The -loginpage argument is used to see the k-grid page of regions and news when logging in.

* The -helperuri (with the trailing slash) enables the prototype currency module.

Linux Gridserver, the ubuntu way

2008-08-15T19:03:19Z

Sacha Magne:

First, you need to update your sources.list with theses lines :

deb http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ hardy universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy universe
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates universe
deb http://fr.archive.ubuntu.com/ubuntu/ hardy multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse
deb http://archive.canonical.com/ubuntu hardy partner
deb-src http://archive.canonical.com/ubuntu hardy partner
deb http://security.ubuntu.com/ubuntu hardy-security main restricted
deb-src http://security.ubuntu.com/ubuntu hardy-security main restricted
deb http://security.ubuntu.com/ubuntu hardy-security universe
deb-src http://security.ubuntu.com/ubuntu hardy-security universe
deb http://security.ubuntu.com/ubuntu hardy-security multiverse
deb-src http://security.ubuntu.com/ubuntu hardy-security multiverse
deb http://ppa.launchpad.net/mono-edge/ubuntu/ hardy main universe multiverse restricted

Don't forget the :
apt-get update
apt-get upgrade

Then, you need to create a file called mono.pkg that contains thoses lines:

libmono-accessibility1.0-cil install
libmono-accessibility2.0-cil install
libmono-addins0.2-cil install
libmono-bytefx0.7.6.1-cil install
libmono-bytefx0.7.6.2-cil install
libmono-c5-1.0-cil install
libmono-cecil0.5-cil install
libmono-corlib1.0-cil install
libmono-corlib2.0-cil install
libmono-corlib2.1-cil install
libmono-cscompmgd7.0-cil install
libmono-cscompmgd8.0-cil install
libmono-data-tds1.0-cil install
libmono-data-tds2.0-cil install
libmono-dev install
libmono-i18n2.0-cil install
libmono-microsoft7.0-cil install
libmono-microsoft8.0-cil install
libmono-mozilla0.1-cil install
libmono-mozilla0.2-cil install
libmono-peapi1.0-cil install
libmono-peapi2.0-cil install
libmono-relaxng1.0-cil install
libmono-relaxng2.0-cil install
libmono-security1.0-cil install
libmono-security2.0-cil install
libmono-sharpzip0.84-cil install
libmono-sharpzip2.84-cil install
libmono-sqlite1.0-cil install
libmono-sqlite2.0-cil install
libmono-system-data1.0-cil install
libmono-system-data2.0-cil install
libmono-system-messaging1.0-cil install
libmono-system-messaging2.0-cil install
libmono-system-runtime1.0-cil install
libmono-system-runtime2.0-cil install
libmono-system-web1.0-cil install
libmono-system-web2.0-cil install
libmono-system1.0-cil install
libmono-system2.0-cil install
libmono-system2.1-cil install
libmono-winforms1.0-cil install
libmono0 install
libmono0-dbg install
libmono1.0-cil install
libmono2.0-cil install
mono-1.0-devel install
mono-1.0-service install
mono-2.0-devel install
mono-2.0-service install
mono-common install
mono-dbg install
mono-debugger install
mono-gac install
mono-gmcs install
mono-jit install
mono-jit-dbg install
mono-mcs install
mono-mjs install
mono-runtime install
mono-smcs install
mono-tools-devel install
mono-utils install
monodoc-base install
monodoc-manual install

then let the magic do its job :

sudo dpkg --set-selections < mono.pkg
apt-get update && sudo apt-get dselect-upgrade

Linux Gridserver, the ubuntu way

2008-08-15T18:58:59Z

Sacha Magne:

First, you need to update your sources.list with theses lines :

deb http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ hardy universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy universe
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates universe
deb http://fr.archive.ubuntu.com/ubuntu/ hardy multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse
deb http://archive.canonical.com/ubuntu hardy partner
deb-src http://archive.canonical.com/ubuntu hardy partner
deb http://security.ubuntu.com/ubuntu hardy-security main restricted
deb-src http://security.ubuntu.com/ubuntu hardy-security main restricted
deb http://security.ubuntu.com/ubuntu hardy-security universe
deb-src http://security.ubuntu.com/ubuntu hardy-security universe
deb http://security.ubuntu.com/ubuntu hardy-security multiverse
deb-src http://security.ubuntu.com/ubuntu hardy-security multiverse
deb http://ppa.launchpad.net/mono-edge/ubuntu/ hardy main universe multiverse restricted

Then, you need to create a file called mono.pkg that contains thoses lines:

libmono-accessibility1.0-cil install
libmono-accessibility2.0-cil install
libmono-addins0.2-cil install
libmono-bytefx0.7.6.1-cil install
libmono-bytefx0.7.6.2-cil install
libmono-c5-1.0-cil install
libmono-cecil0.5-cil install
libmono-corlib1.0-cil install
libmono-corlib2.0-cil install
libmono-corlib2.1-cil install
libmono-cscompmgd7.0-cil install
libmono-cscompmgd8.0-cil install
libmono-data-tds1.0-cil install
libmono-data-tds2.0-cil install
libmono-dev install
libmono-i18n2.0-cil install
libmono-microsoft7.0-cil install
libmono-microsoft8.0-cil install
libmono-mozilla0.1-cil install
libmono-mozilla0.2-cil install
libmono-peapi1.0-cil install
libmono-peapi2.0-cil install
libmono-relaxng1.0-cil install
libmono-relaxng2.0-cil install
libmono-security1.0-cil install
libmono-security2.0-cil install
libmono-sharpzip0.84-cil install
libmono-sharpzip2.84-cil install
libmono-sqlite1.0-cil install
libmono-sqlite2.0-cil install
libmono-system-data1.0-cil install
libmono-system-data2.0-cil install
libmono-system-messaging1.0-cil install
libmono-system-messaging2.0-cil install
libmono-system-runtime1.0-cil install
libmono-system-runtime2.0-cil install
libmono-system-web1.0-cil install
libmono-system-web2.0-cil install
libmono-system1.0-cil install
libmono-system2.0-cil install
libmono-system2.1-cil install
libmono-winforms1.0-cil install
libmono0 install
libmono0-dbg install
libmono1.0-cil install
libmono2.0-cil install
mono-1.0-devel install
mono-1.0-service install
mono-2.0-devel install
mono-2.0-service install
mono-common install
mono-dbg install
mono-debugger install
mono-gac install
mono-gmcs install
mono-jit install
mono-jit-dbg install
mono-mcs install
mono-mjs install
mono-runtime install
mono-smcs install
mono-tools-devel install
mono-utils install
monodoc-base install
monodoc-manual install

then let the magic do its job :

sudo dpkg --set-selections < mono.pkg
apt-get update && sudo apt-get dselect-upgrade

Linux Gridserver, the ubuntu way

2008-08-15T18:56:48Z

Sacha Magne:

First, you need to update your sources.list with theses lines :

deb http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted

deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted

deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates main restricted

deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates main restricted

deb http://fr.archive.ubuntu.com/ubuntu/ hardy universe

deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy universe

deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates universe

deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates universe

deb http://fr.archive.ubuntu.com/ubuntu/ hardy multiverse

deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy multiverse

deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates multiverse

deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates multiverse

deb http://fr.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse

# deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse

deb http://archive.canonical.com/ubuntu hardy partner

deb-src http://archive.canonical.com/ubuntu hardy partner

deb http://security.ubuntu.com/ubuntu hardy-security main restricted
deb-src http://security.ubuntu.com/ubuntu hardy-security main restricted

deb http://security.ubuntu.com/ubuntu hardy-security universe

deb-src http://security.ubuntu.com/ubuntu hardy-security universe

deb http://security.ubuntu.com/ubuntu hardy-security multiverse

deb-src http://security.ubuntu.com/ubuntu hardy-security multiverse

deb http://ppa.launchpad.net/mono-edge/ubuntu/ hardy main universe multiverse restricted

Then, you need to create a file called mono.pkg that contains thoses lines:

libmono-accessibility1.0-cil install
libmono-accessibility2.0-cil install
libmono-addins0.2-cil install
libmono-bytefx0.7.6.1-cil install
libmono-bytefx0.7.6.2-cil install
libmono-c5-1.0-cil install
libmono-cecil0.5-cil install
libmono-corlib1.0-cil install
libmono-corlib2.0-cil install
libmono-corlib2.1-cil install
libmono-cscompmgd7.0-cil install
libmono-cscompmgd8.0-cil install
libmono-data-tds1.0-cil install
libmono-data-tds2.0-cil install
libmono-dev install
libmono-i18n2.0-cil install
libmono-microsoft7.0-cil install
libmono-microsoft8.0-cil install
libmono-mozilla0.1-cil install
libmono-mozilla0.2-cil install
libmono-peapi1.0-cil install
libmono-peapi2.0-cil install
libmono-relaxng1.0-cil install
libmono-relaxng2.0-cil install
libmono-security1.0-cil install
libmono-security2.0-cil install
libmono-sharpzip0.84-cil install
libmono-sharpzip2.84-cil install
libmono-sqlite1.0-cil install
libmono-sqlite2.0-cil install
libmono-system-data1.0-cil install
libmono-system-data2.0-cil install
libmono-system-messaging1.0-cil install
libmono-system-messaging2.0-cil install
libmono-system-runtime1.0-cil install
libmono-system-runtime2.0-cil install
libmono-system-web1.0-cil install
libmono-system-web2.0-cil install
libmono-system1.0-cil install
libmono-system2.0-cil install
libmono-system2.1-cil install
libmono-winforms1.0-cil install
libmono0 install
libmono0-dbg install
libmono1.0-cil install
libmono2.0-cil install
mono-1.0-devel install
mono-1.0-service install
mono-2.0-devel install
mono-2.0-service install
mono-common install
mono-dbg install
mono-debugger install
mono-gac install
mono-gmcs install
mono-jit install
mono-jit-dbg install
mono-mcs install
mono-mjs install
mono-runtime install
mono-smcs install
mono-tools-devel install
mono-utils install
monodoc-base install
monodoc-manual install

then let the magic do its job :

sudo dpkg --set-selections < mono.pkg
apt-get update && sudo apt-get dselect-upgrade

Linux Gridserver, the ubuntu way

2008-08-15T18:48:11Z

Sacha Magne: New page: First, you need to update your sources.list with theses lines : deb http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy main res...

First, you need to update your sources.list with theses lines :

deb http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ hardy universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy universe
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates universe
deb http://fr.archive.ubuntu.com/ubuntu/ hardy multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-updates multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse
deb http://archive.canonical.com/ubuntu hardy partner
deb-src http://archive.canonical.com/ubuntu hardy partner
deb http://security.ubuntu.com/ubuntu hardy-security main restricted
deb-src http://security.ubuntu.com/ubuntu hardy-security main restricted
deb http://security.ubuntu.com/ubuntu hardy-security universe
deb-src http://security.ubuntu.com/ubuntu hardy-security universe
deb http://security.ubuntu.com/ubuntu hardy-security multiverse
deb-src http://security.ubuntu.com/ubuntu hardy-security multiverse
deb http://ppa.launchpad.net/mono-edge/ubuntu/ hardy main universe multiverse restricted

Then, you need to create a file called mono.pkg that contains thoses lines:

libmono-accessibility1.0-cil install
libmono-accessibility2.0-cil install
libmono-addins0.2-cil install
libmono-bytefx0.7.6.1-cil install
libmono-bytefx0.7.6.2-cil install
libmono-c5-1.0-cil install
libmono-cecil0.5-cil install
libmono-corlib1.0-cil install
libmono-corlib2.0-cil install
libmono-corlib2.1-cil install
libmono-cscompmgd7.0-cil install
libmono-cscompmgd8.0-cil install
libmono-data-tds1.0-cil install
libmono-data-tds2.0-cil install
libmono-dev install
libmono-i18n2.0-cil install
libmono-microsoft7.0-cil install
libmono-microsoft8.0-cil install
libmono-mozilla0.1-cil install
libmono-mozilla0.2-cil install
libmono-peapi1.0-cil install
libmono-peapi2.0-cil install
libmono-relaxng1.0-cil install
libmono-relaxng2.0-cil install
libmono-security1.0-cil install
libmono-security2.0-cil install
libmono-sharpzip0.84-cil install
libmono-sharpzip2.84-cil install
libmono-sqlite1.0-cil install
libmono-sqlite2.0-cil install
libmono-system-data1.0-cil install
libmono-system-data2.0-cil install
libmono-system-messaging1.0-cil install
libmono-system-messaging2.0-cil install
libmono-system-runtime1.0-cil install
libmono-system-runtime2.0-cil install
libmono-system-web1.0-cil install
libmono-system-web2.0-cil install
libmono-system1.0-cil install
libmono-system2.0-cil install
libmono-system2.1-cil install
libmono-winforms1.0-cil install
libmono0 install
libmono0-dbg install
libmono1.0-cil install
libmono2.0-cil install
mono-1.0-devel install
mono-1.0-service install
mono-2.0-devel install
mono-2.0-service install
mono-common install
mono-dbg install
mono-debugger install
mono-gac install
mono-gmcs install
mono-jit install
mono-jit-dbg install
mono-mcs install
mono-mjs install
mono-runtime install
mono-smcs install
mono-tools-devel install
mono-utils install
monodoc-base install
monodoc-manual install

then let the magic do its job :

sudo dpkg --set-selections < mono.pkg
apt-get update && sudo apt-get dselect-upgrade

User Documentation

2008-08-15T18:45:53Z

Sacha Magne: /* Tutorials */

{{Template:Quicklinks}}
__NOTOC__
==Initial Setup==
* [[Download]] - Download instructions
* [[OpenSim Build Instructions|Build Instructions]] - How to build and compile OpenSim from Source
* [[OpenSim Configuration|Configuration]] - How to get your OpenSim server up and running
* [[Connecting]] - How to connect a compatible viewer to OpenSim
* [[Troubleshooting]] - How to trouble shoot your OpenSim installation.
* [[Tips]] - Useful tips from users like you
* [[FAQ]] - Frequently Asked Questions

==Administrator Guide==
* [[Server Commands]] - Commands to control OpenSim
* [[OpenSim Database support]] - Dealing with databases
* [[Custom Libraries]] - Describes how to add custom content to your OpenSim server
* [[Automating Tasks]] - How to make administrating a walk in the park
* [[Network Settings]] - NAT, Ports, Services and more...
* [[Management]] - All about being an effective administrator/moderator
* [[Performance]] - How to tweak OpenSim's performance
* [[Console-less OpenSim]] - How to run OpenSim without console
* [[GridInfo]] - how to provide information about your grid to smart clients

==Facilities==
* [[OpenSim Archives]] - Loading and saving whole region archives with OpenSim

==Scripting==
* [[Scripting Documentation]] - Everything you need to know about OpenSim scripting
* [[Scripting Library]] - A list of example scripts

==Tutorials==
* [[OSGrid Region Registration]] - Describes how to link your region into OS-Grid
* [[Hints & Tricks]] - A page for Hints and Tricks
* [[Using L3DT]] - How to create custom terrains
* [[Detailed cross-region terrain making]] - A workflow for creating large cross-region custom terrains
* [[Linux Gridserver]] using 'moo' - How to setup a Gridserver on a Linux machine using 'moo'
* [[Linux Gridserver, the ubuntu way]] the quick and dirty way to install opensim under ubuntu

==Contribution Policy==
* [[User_Wiki_Conventions|User Wiki Conventions]] - Read this carefully, before adding content to the wiki
[[Category:Users]]
<cleanpage title=hide cats=hide />

Test Page

2008-08-11T19:31:36Z

Sacha Magne: /* oswatchdog */

===Open Sim Watchdog Script===
This is a small script to watch for an OpenSim region simulator under screen in Linux. If the process is missing, a new instance will be started.

==oswatchdog==
<source lang="bash">
#!/bin/sh
#
# THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE CONTRIBUTORS BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#
#
# Adjust To Your System:
#
# Sample Cron Entry: Runs Each Minute 24/7/365
# */1 * * * * exec /opt/opensim/scripts/oswatchdog
#
#
#
# Where Does Your OpenSim Installation Live?
BASE="/opt/opensim"
# Where Do You Run OpenSim.exe From?
RUN="$BASE/production/bin"
# Where Do You Want To Log Events To?
LOG="$BASE/log"
# Where Is Your Screen Binary?
SCREEN="/usr/bin/screen"

#if the file exist, opensim won't be restarted
# Sacha Magne
LOCKFILE="/tmp/norun.opensim"

if [ -f "$LOCKFILE" ]; then
echo $LOCKFILE "found. no restart"
exit
fi

# Check For For Our Screen Process, Named OSG
running=`ps ax|grep OSG|grep -v grep`

# If The Process Is Not There...
if [ -z "$running" ]; then
#...We Make A Log Entry And Start A New One
# The Log Entry
TIME="Simulator Down, Restarting: `/usr/bin/date +"%A, %B %d - %r"`"

echo $TIME >>$LOG/OSGReport.txt
cd $RUN
$SCREEN -S OSG -d -m mono OpenSim.exe
fi
# All Done 'Till Next Time

A better SimCrossing

2008-07-25T14:06:44Z

Sacha Magne:

The idea behind that name is using some technics used in Telecom world (GSM,3G) to perform a better transition between sims.

Concept:

The SimCrossing (SC) is based one several messages exchanged between the object (Object), the actual sim (OriginSim) and the next sim (TargetSim). The main exchange are located in the HandOverArea (HOarea) located on the OriginSim. This area is computed by the server for each TargetSim (maximum 4 ).

In order to have a smooth transition, we need to determine an HandOver area where all the simcrossing messages exchange should happens. This area is computed on the object level regarding the ping latency between the Target and the object velocity. This area contains a RedZone area where all the Simcrossing conditions should be satisfied, otherwise the simcrossing won’t happen.

Phase 1 : Login or rezzing

During the login phase, the object asks the surrounding sims list to its actual simulator. We can call this list the ActiveSet . The ActiveSet contains the sim data and their “ping” time.

The object compute the SimCrossing boundaries and determine an “HandOver” area with a Redzone area based on the timers (ping + delta). Normaly the Handover should be ready before entering the Redzone.

Phase 2: Object logged and alive entering in the HandOver Area

On periodic basis, the object send a ping to each simulator on its activeset and update their status accordingly in order to keep an up to date neighbored simulator list.

When the object enter in the HandOver area, a message “SimCrossing Request” is sent to the Source simulator. The simulator will relay the message to the next Simulator (Target Sim) and will start downloading the object context. Those data should include all the running code, the values of the code’s variables like a memory dump (heap,stack and such).

more details here http://docs.google.com/Doc?docid=dfcvvffc_3jj3jwgxn&hl=en

A better SimCrossing

2008-07-25T13:56:40Z

Sacha Magne: New page: The idea behind that name is using some technics used in Telecom world (GSM,3G) to perform a better transition between sims.

The idea behind that name is using some technics used in Telecom world (GSM,3G) to perform a better transition between sims.

Developer Documentation

2008-07-24T20:02:04Z

Sacha Magne: /* Developer Documentation */

{{Template:Quicklinks}}

== Developer Documentation ==
You can view the current [[Top 10 Bugs|top 10 bugs]] blocking forward development.

* [[Hacking OpenSim for fun and profit]] — A starters guide for programming OpenSim
* [[Database Documentation]] — A map of grid and region instances used in OpenSim
* [[OpenSim: Debugging - profiler dumps]] — Dumps of OpenSim profiles to aid in tracking memory leaks.
* [[OpenSim: Testing]] — What is tested.
* [[OpenSim: TechRef]] — A technical description of the simulator operation.
* [[Opensim: 0.5 Release Target Discussion]]
* [[Opensim: 0.6 Release Target Discussion]]
* [[Opensim: Future Release Discussion]]
* [[OpenSim: Class Diagrams]]
* [[Grid Architecture Diagram]]
* [[OpenSim: Scripting]] — How to use scripts and what limitations apply.
* [[Webinterface]] — How to mashup with the web.
* [[RemoteAdmin]] — How to use the remote admin plug-in.
* [[OpenSim: Prim Inventory Persistence]] — Information on the current state of prim inventory persistence.
* [[LSL_Status/Functions|LSL Implemented]] — A list of LSL-functions that are available in OpenSim.
* [[PhysicsEngines]] — Options for physics engines in OpenSim.
* [[MonoSqlite]] — How the database model currently works.
* [[Monodevelop]] — How to use the [[monodevelop]] IDE for editing C# solutions.
* [[Scripting Documentation]] - Everything you need to know about OpenSim scripting
* [[LSL:PrimitiveParams]] Notes on converting SL Edit GUI values and LSL PrimitiveParams to OpenSim PrimitiveBaseShape fields
* [[OpenSim.Region.ScriptEngine]] — How the ScriptEngine looks internally.
* [[RegionModules]] — The various modules that are used in the RegionServer and how to write new ones.
* [[OpenSim: Screenshots]] — Various OpenSim screenshots.
* [[OpenSim: Threading strategy]] — How threading is implemented and handled.
* [[OpenSim: Permissions]] — Notes on object permissions & definition of the ObjectFlags variable.
* [[OpenSim Load Balancing and Region Splitting]] - Instructions for using load balancing and region splitting features.
* [[Asset Server problems]] - list of known problems with the asset server
* [[OpenID]] - Proposal for using OpenID in OpenSim
* [[OpenSim.Region.DataSnapshot]] - Shiny new data gathering/search system
* [[How to create a dynamic plugin]] - A tutorial for using PluginLoader
* [[A better SimCrossing]] - A work in progress about implemening a smooth simcrossing

==Communication==

A good first point of contact is the OpenSim IRC, on irc.freenode.net channels #opensim / #opensim-dev. The OpenSim developers hold [[office hours]] once a week in-world on Tuesdays at "Wright Plaza" on OSGrid. There is a "Test Hour" on Saturdays, also generally on "Wright Plaza". Both these weekly events are held at 1900UTC. Check on the #opensim IRC channel on Freenode just before each of these events if there is any confusion.

==SVN Access==
You can browse the source code for OpenSim [http://opensimulator.org/cgi-bin/viewcvs.cgi using a web browser] or via SVN.
* Anonymous Checkout
svn co http://opensimulator.org/svn/opensim/trunk
* Developer Checkout
svn co svn+ssh://USERNAME@opensimulator.org/var/svn/opensim/trunk

==Recent SVN Commits==
<rss>http://cia.vc/stats/project/opensim/.rss|max=5|title=none</rss>

[[Category:Main]]
[[Category:Getting Started]]
[[Category:Development]]
<cleanpage title=hide cats=hide />

OSSL Proposals

2008-06-17T14:08:47Z

Sacha Magne: /* OSSL Proposal Table */

This is a page dedicated to OpenSim's very own home brew custom scripting language Known as "'''O'''pen '''S'''im '''S'''cripting '''L'''anguage"

<big>'''Please see [[OSSL_Standards|OSSL Standards]] for proposed naming schema'''</big>

* Please post your osFunction along with a brief description of what it would be for, or do and an example of it.
* Make sure it begins with os NOT ll.
* And remember, almost anything within reason can be posted here as an idea, who knows, maybe a variation of your request can be possible.
* If a function could implemented in standard LSL, there is no reason to make an OS function. LSL code and function code executes at the same speed in OpenSim.
==OSSL Proposal Table==
{| class="sortable" cellpadding="5" cellspacing="0" style="width:100%;border:1px solid #000000;border-collapse: collapse; white-space:normal;"
|- style="background-color:#99CCFF;font-size:6pt;font-weight:bold;border-bottom:1px solid;" align="center" valign="bottom"
| osFunction
| Description
| Example Usage
| Signed

|- style="background-color:#CCFFCC;font-size:8pt;border-bottom:1px solid;" valign="top"
| int osRestartRegion()
| Restarts the region the script is currently in. The script this is run in has to be owned by the master avatar for that region. Returns 1 if the region is restarting, 0 on failure.
| osRestartRegion();
| gryc (Implemented by AFrisby)

|- style="background-color:#CCFFCC;font-size:8pt;border-bottom:1px solid;" valign="top"
| int osWebTexture()
| Sets the texture from a web-url
| osWebTexture(string url,integer maptype);
| AFrisby?

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osGroupAdd(key, string Role)
| Adds user to a group with given role, default role Everyone. Returns 1 if successful 0 if fail.
| osGroupAdd(87f6e6a0-d884-11dc-95ff-0800200c9a66, "Officer")
| Nitrus Nori

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| int osShutdownRegion()
| Shuts down the region the script is currently in. The script this is run in has to be owned by the master avatar for that region. Returns 1 if the region is going down, 0 on failure.
| osShutdownRegion();
| gryc

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| void osAttachmentSay(integer channel, string msg)
| Provide a secure, low lag method of communicating between attachments over the chat channels by only sending messages to objects attached to the same avatar. Would fail (or not be heard) if in a non-attached object.
| osAttachmentSay(-20, "detatch");
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| void osMessageSecure(string message_key, string str, integer num, key id); secure_message(string message_key, string str, integer num, key id);
| Provide a method of sending secure, salt encripted messages sim wide. Messages would only be able to be received by scripts with the matching key in the secure_message method.
| osMessageSecure("myPassPhrase", "Hello World", 0, NULL_KEY);
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| void osSetText( vector color, string text [,vector color, string text]);
| Allow setting of multiple colors on the prim text
| osSetText(<1,0,0>,"Red", <0,1,0>, "\nGreen", <0,0,1>, "\nBlue");
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osSensor
| Gets ALL the objects in the specified range not just the first 16
| (same as standard)
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| list lst=osDetectObjectsInSim(key id)
| given an Agent Key, provide a list of ALL object owned by that agent
| osDetectObjectsInSim(key id) returning a strided list of [ name, <pos> ]
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer=osDialog([ title, label1, type1, len1, label2, type2, len2]....
| given title and a listing of fields, builds up a real form where to put structured checked data
| will return a [ value1, value2, valuen ] corresponding to fields read. Type might be something like (string, text (multiline), integer, float, currency(decimals), options(combobox)
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| key id=osMakeTextureText(string name,integer width, integer height,[posx1,posy1,font1,color1,size1,text1,posx2,posy2,font2,color2,size2,text2....])
| allow for producing a texture on the fly with desired Font content from a selected font selection. Width, Height in pixels 1024x512 to control how big will be the texture
| will generate a texture with defined text. (Allow some support for at least ISO-8859-1) texture will be created in the object inventory. posx, posy in the range 0-1 to be pixel independent
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osMakeNotecard(string name, [ line1, line2, line3, ...])
| allow creation of new notecards in current object repository
| generate a new asset id useful for storing modified configuration
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer handler=osReadNotecardKey(string notecard, string key)
| allows reading notecards (through dataserver) in format key=value in convenient and efficient way
| ...
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osWriteNotecardKey(string notecard, string key,string value)
| allows WRITING notecards in format key=value in convenient and efficient way. Might be optimized having a fixed record length "file" so to avoid rewriting of the entire notecard
| ...
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer handle=osXMLParser(string xml)
| will activate a listener xmlparser(integer handler,string parent, string field, string value)
| to easily parse xml without writing php external code
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osReturnObjects(key owner, integer type);
| Provide a scriptable method of returning objects from a sim. type would be OBJECT_SCRIPTED, OBJECT_PASSIVE or OBJECT_ALL. Would return a binary Success/Fail, and work inline with land permissions for the script owner.
| osReturnObjects( target, OBJECT_ALL);
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osReturnItem(key item);
| Provide a scriptable method of returning individual objects from a sim. Would return a binary Success/Fail, and work inline with land permissions for the script owner.
| osReturnItem(uuid);
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osSetTimerEvent(integer timer, float rate); (event) timer(integer timer_num)
| Support for multiple timers in a script.
| osSetTimerEvent(2, 0.5);
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osTimerOnce(integer timer, float rate);
| Allow for a one shot timer event, rather than the normal repeating heartbeat type
| osTimerOnce(2, 10);
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osVerifyScripts();
| Check to see if all scripts in an object are created by the owner of the script calling the function. Return TRUE if they are, FALSE otherwise, to prevent insertion of alien scripts into an object
| if (!osVerifyScripts()) { llDie(); }
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| void osStopOtherAnimations(list animation_exceptions);
| Provide a method of stopping all animations on an avatar, except those defined in the list
| osStopOtherAnimations(["my_sitting_anim"]);
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| void osPutScriptInLinkedSet(string name,integer linknum, integer starting_parm, integer running)
| Use this to propagate one script to ALL or part of linked set.
| Useful to have all objects in a linked set sharing a common behaviour
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osRezObject(string name, string description, integer permissionmask, list setPrimitiveObjectLikeList) will trigger the object_rez object as usual
| similar to llRezObject, but without the need of having a prim inside the inventory (which produced a lot of problems in deploying and in sl). Newly created object will have the same owner of current object where script is running.
| In case list is empty or position not specified, suitable defaults should apply like pos being 1 m higher in the z axis
| Sal

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| string osGetOwnerName();
| Provide a method of getting the owner name without having to use llKey2Name
| myName = osGetOwnerName();
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osXMPPOpen(string server, string username, string password, string resource);
| Open an XMPP session to a jabber or other XMPP server, returning a handle to be able to manipulate the connection. Incoming messages to be parsed through a xmpp_message(integer handle, string sender, string service, string message) event. Accounts would have to be set up manually by the scripter, or by some other method, to prevent scripted spamming of a server, and to allow users to set up gateways and other services if needed.
| handle = osXMPPOpen("jabber.org", "MyObject", "MyPassword", "OpenSim");
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| list osXMPPGetRosta(integer handle);
| Get the rosta from the XMPP server, list in the strided form of [username, presence, resource];
| list presence = osXMPPGetRosta(handle);
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| list osXMPPGetServices(integer handle);
| Get a list of available services from the XMPP Server.
| list services = osXMPPGetServices(handle);
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osXMPPAdd(string username, string service)
| Add a username to the account rosta. Return boolean success or fail
| if (osXMPPAdd("Test User", "Yahoo")) { ... }
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer oxXMPPDelete(string username)
| Remove a username from the account rosta. Return boolean success or fail
| if (osXMPPDelete("Test User")) { ... }
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osXMPPGetStatus(string username);
| Poll the server for the status of a specific username on the rosta - returns would be OFFLINE, BUSY, AWAY and ONLINE
| if (osXMPPGetStatus("Test User") & ONLINE) { ... }
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osXMPPSendMessage(integer handle, string message, string target);
| Send a message via the open XMPP channel, to the specified target. Return boolean success values
| if (osXMPPSendMessage(handle, "Hello World", osGetOwnerName()) { llOwnerSay("Successfully sent message");
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| void osXMPPClose(integer handle);
| Close the XMPP session
| osXMPPClose();
| Del M

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| void osRezObjectKey(key object,vector pos,vector vel,rotation rot, int param);
| Basically llGodLikeRezObject[http://lslwiki.net/lslwiki/wakka.php?wakka=llGodLikeRezObject] with the features of llRezObject[http://lslwiki.net/lslwiki/wakka.php?wakka=llRezObject] but for everyone to use. Calls object_rez.
| osRezObjectKey(object_key,llGetPos(),ZERO_VECTOR,llGetRot(),0);
| Tdub

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osRezFromURL(string url, vector pos, vector vel, rotation rot, integer param) - calls on_rez
| Fetch a fragment of xml from a web server and rez its contents in-world as in 'load-xml'. Off or intergrid object repositories, such as objects stored in SVN via websvn, CMS, etc.
| osRezFromURL("http://my.objectstore.com/myawesomeprims.xml", <1, 1, 1>, <0, 0, 0>, <0, 0, 0>, 0)
| Jimbo2120

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| list osRunCustom(string function, list params)
| Allow scripts to call external custom routines that are grid-specific without modifying the set of LSL and OSL functions.
| list results = osRunCustom("function1", [...])
| Ezekiel

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osSetScriptServer()
| Create a 'Server' prim that allows for extended scripting capabilities: more memory, higher bandwidth when communicating with external servers, probably some database connectivity, no artificial delays, can receive IMs, etc. Could be limited to one server per prim / parcel or per avatar, could be forced to remain in a fixed position. A server is important for residents that want to set up a virtual business.
| osSetScriptServer()
| Ezekiel

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osRemoteLoadScript(string url, string target)
| Load a source file in txt format from "URL" and compile it into script "target" in the inventory of the same prim. Requires permission of the object owner (RequestPermission). Returns boolean success value. Replaces an existing script with same name. This function would allow updates to scripted solutions that operate in any grid and sim worldwide, allowing the creator of the solution to distribute code fixes and implement new functions. Since the source code is distributed openly, it can be copied and modified by anyone. A function that would allow for secure code distribution, protecting copyrights and certificates, would also be very interesting but should be far more difficult to implement.
| integer updatestatus = osRemoteLoadScript("http://www.xyz.com/updates/script1013.txt", "betterscript" )
| Ezekiel

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osSetCustomPrimitiveAttributes(list params)
| Set some custom persistent primitive attributes, the same way as llSetPrimitiveParams do. The attribute name has to be specified as a string, then the attribute type using a lSL constant. In the example, we set a "magnet" custom attribute as -0.5, supposing a customized physic engine handles this attribute to provide prim attraction.
| integer osSetCustomPrimitiveAttributes(["magnet", TYPE_FLOAT, -0.5])
| Grumly

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| list osGetCustomPrimitiveAttributes(list paramNames)
| Return a list values of the specified attributes names, the same way as llGetPrimitiveParams do.
| list osGetCustomPrimitiveAttributes(["Magnetic"])
| Grumly

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osSyncUUID(key oldUUID, key newUUID);
| Allows to change the UUID of an avatar or item(requires permission from owner).
| Suppose a terminal in the LL-grid wants to communicate with an OS-Grid terminal. It can only send messages, if the UUID's of avatars match. An OS-Grid script can get the avatar's LL-UUID by calling the dataserver script. Then it calls osSyncUUID(llDetectedKey(0), keyFromHTTPRequest); . Now the two keys are equal, and avatar-avatar communication between grids can take place!
| Phrearch

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| integer osTeleport(string RegionName, int x, int y, int z);
| Teleports an avatar to a custom region
|
| Phrearch

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| osSetStatus(integer status, integer value);
| Improved verion of the LSL function llSetStatus.
| The function works basically the same way as llSetStatus, except that an extra flag is added named STATUS_PHYSICS_ROOT. When this flag is TRUE, physics would be enabled Only for the root prim in a linked set, while the other prims in the set would behave as phantom. This would be useful for bypassing the 32-prim physics limit for vehicles by using only the root prim as a collision mesh.
| Pesho

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| vector osGetBonePos();
| When called from an Attachment, retrieves the position of the bone it is attached to, in Region Coordinates.
| When llGetPos() is called from an attachment, the vector returned is the one of the avatar center, whereas llGetLocalPos() returns the local offset from the bone it is attached to. It would be useful to know where the attachment's location really is in world space.
| Pesho

|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| string osGetOSLLRelease();
| When called return the actual release of OSSL running on the sim.
| if osGetOSSLRelease() > 1.1 {llSay(0,"good");}
| Sacha Magne
|- style="font-size:8pt;border-bottom:1px solid;" valign="top"
| List osGetServerLib();
| When called return a list of all the additional libraries loaded on the server. it will avoid any scripts using a specific library to crash in case of missing libs.
| List lib=osGetServerLib();
| Sacha Magne
|}
[[Category:Main]]
[[Category:Development]]
[[Category:Users]]

Build Instructions

2008-06-17T13:37:28Z

Sacha Magne: /* MS Windows */

[[Category:Users]]
=Installing from source=

==Download from SVN==
Check out the [[Download]] Section

==MS Windows==

OpenSim requires either the .Net framework version 2.0, or the latest Mono. It supports the following compilers:
* [http://msdn2.microsoft.com/en-us/express/aa700756.aspx Microsoft Visual C# Express Edition] (note: not Visual C++)
* [http://www.mono-project.com/ mono]

Note for people who just downloaded the sources from http://dist.opensimulator.org/ (the "Downloads" link on the left) be advised that some important things are missing (like MySQL template scripts). For such features, you must download using svn!

Additional note: any Microsoft C# Express edition should work (2005 or 2008)

=== Building ===

* In the top-level directory, run the '<tt>runprebuild.bat</tt>' file. This will create both a VS2005 solution file, and a nant build file.
* Open the resulting sln file with visual studio, and build it there, or if you prefer to use nant, run nant in the same top-level directory. This will build the executables.

If you don't care about physics (walking on prims, etc), ignore the rest of this section.

==== Physics ====

===== Open Dynamics Engine (ODE) =====
If you want to implement collision-based physics, OpenDynamicsEngine (ODE) is the furthest along at the moment (9/07). It is not fully supported, but is starting to work somewhat reliably using a small number of regions per sim.

As installed from svn, ODE does not work on all platforms. If you get an ODE-related crash, and/or an ode.dll not found type of error (which can occur even though the dll is present!), try to build ode from source, follow the directions on [[PhysicsEngines]].

Be sure you don't already have a system library version of libode.so that's being used instead of the one in the bin folder of your opensimulator distribution

=== Running ===

Recent versions of OpenSim come without an <tt>OpenSim.ini</tt> file. Copy the <tt>OpenSim.ini.example</tt> file to <tt>OpenSim.ini</tt> before making any changes.

Double-click on the <tt>OpenSim.exe</tt> executable file in the <tt>bin</tt> directory. This will start up OpenSim in standalone mode.

The debugger in VS2005 C# may be used to step through the code. For those that use a Cygwin shell, you may find that one or more dll's have permissions that cause problems running. Most find that a "<tt>chmod 777 *</tt>" from the <tt>bin</tt> directory solves this.

Physics can be invoked by adding the appropriate line to the [Startup] section of <tt>OpenSim.ini</tt>. For ODE, that would be:

physics = OpenDynamicsEngine

You can also add a command line option to a shortcut, or run from a command prompt with:

-physics=OpenDynamicsEngine

'''''Windows Vista'''''

To run on Windows Vista, you must first disable Windows Firewall. Under the new "Start" button of Vista, select "Control panel". Then double-click "Windows Firewall". In the window that pops up, on the left column, select "Turn Windows Firewall on or off". You will have to give permission for this to run, then select the option "Off (not recommended)". Click "OK" and exit from the Windows Firewall window.

If you have McAfee SecurityCenter, see the description below.

Once all the security features are disabled, right click on <tt>OpenSim.exe</tt> and select "Run as administrator". This will pop up a window asking permission, select "Allow". Your OpenSim server should run in a DOS-like window and accept connections.

'''''McAfee Security'''''

McAfee Security does not allow applications to listen on ports not explicitly specified. You have two options: 1) disable firewall protection all together, 2) enable <tt>OpenSim.exe</tt> to be able to open ports.

''Disable firewall''

Open McAfee SecurityCenter. Select "Internet & Network". In the lower left corner is a small link to "Configure...". Select this. In the right side of the window, select the bar that says "Firewall protection is enabled". Here you can select "Off".

''Enable <tt>OpenSim.exe</tt> to open ports''

Open McAfee SecurityCenter. Select "Internet & Network". In the lower left corner is a small link to "Configure...". Select this. In the right side of the window, select the bar that says "Firewall protection is enabled". Select the "Advanced..." button. This will pop up a new window.

In the new window, on the left side, select "Program Permissions." In the middle on the right side of the window, select the "Add Allowed Program" button. Use the browser that pops up to find the OpenSim executable and select it.

Finally, select "OK" and exit the McAfee SecurityCenter window.

==Linux/Mac OS X/FreeBSD==

Please note that the current (as of 2007-11-23) SVN will not work on 64bit linux systems when built. You will need to use the binary build further down the page.
[[Installing and running on x86-64]]

===Building===

Steps to get packages that are needed to compile the source.

'''FreeBSD 6.2'''
su
cd /usr/ports/devel/subversion/ && make install clean (you may also need to rebuild apr-svn if this step fails)
cd /usr/ports/lang/mono/ && make install clean
cd /usr/ports/devel/nant/ && make install clean
cd /usr/ports/databases/sqlite3/ && make install clean
cd /usr/ports/x11-toolkits/libgdiplus/ && make install clean
cd /opensim/installation/directory/
svn co http://opensimulator.org/svn/opensim/trunk opensim
cd opensim
./runprebuild.sh
nant

Note: [http://opensimulator.org/wiki/OpenSim:FAQ#System.DllNotFoundException:_..2Flibopenjpeg-libsl-2.1.2.0.so|Follow the instructions on the FAQ to fix the]
"System.DllNotFoundException: ./libopenjpeg-libsl-2.1.2.0.so" issue, but use "gmake" instead of "make"

For ODE Physics you must do the following:
cd /usr/ports/graphics/libGL/ && make install clean
cd /usr/ports/graphics/libGLU/ && make install clean
cd /opensim/installation/directory/
svn co http://opensimulator.org/svn/opensim-libs/trunk opensim-libs
cd opensim-libs/unmanaged/OpenDynamicsEngine2/
sh autogen.sh
./configure --enable-shared --enable-release --disable-demos
make
mv ./ode/src/libode.so /opensim/installation/directory/opensim/bin/

'''Ubuntu 7.10'''
sudo aptitude install subversion nant mono mono-gmcs libmono-microsoft8.0-cil libmono-system-runtime2.0-cil
svn co http://opensimulator.org/svn/opensim/trunk opensim
cd opensim
./runprebuild.sh
nant

* The above steps are for just running OpenSim. If you want to use MySQL either install during the installation process or install later. For development you'll need to install gcc, gc++, and whatever other modules are needed.
* The above steps work on running OpenSim 0.4 on Ubuntu Server 7.10. I did a new install and everything worked fine for me. During the installation process I had Ubuntu install MySQL. --[[User:Mokele|Mokele]] 11:41, 9 February 2008 (PST)

'''Ubuntu 8.04'''

Basically the same instructions as in Ubuntu 7.10.

sudo apt-get install subversion nant mono-gmcs libmono-microsoft8.0-cil libmono-system-runtime2.0-cil libgdiplus
svn co http://opensimulator.org/svn/opensim/trunk opensim
cd opensim
./runprebuild.sh
nant

* If you get an exception "System.NotSupportedException: CodePage 1252 not supported" running OpenSim with MySql, install also libmono-i18n2.0-cil.

sudo apt-get install libmono-i18n2.0-cil

* The above steps work on running OpenSim revision 4612 on Ubuntu Server 8.04.
--[[User:Trains|Trains]] 10 May 2008

'''openSUSE 10.3'''

Install an openSUSE 10.3 with its default options, add the online repositories
when finished installing do an online update with all the latest packages.

In yast install these packages, for running Opensim in standalone mode.
subversion (1.4.4)
nant (0.85)
mono-jscript
- check that mono-core is installed

* optional mysql - for Opensim running in Grid mode:
Install these mysql packages via yast
mysql
mysql-client
mysql-administrator
mysql-gui-tools
mysql-query-browser

Before building create the mysql database.
/etc/init.d/mysql start
mysql -u root -p -h localhost
(when asked for password just hit enter)

mysql> create database opensim;
mysql> quit

set the configuration in bin/mysql_connection.ini

Build after installation of above in bash terminal.

su -
svn co http://opensimulator.org/svn/opensim/trunk opensim
cd opensim
./runprebuild.sh
nant

After this you should be able to continue on starting the diffrent Servers, look in the mysql-config section.

'''Mac OS X 10.5/10.4'''
* OpenSim is now working on PowerPC Macs! Thanks to DrScofield and those who helped him. Current nightly builds for PowerPC are not working, not sure about Intel so use the 0.5 Build. OpenSim works on Intel Macs. I'm testing on PowerBook G4. Tested these step on 10.5, but not 10.4 but should work --[[User:Mokele|Mokele]] 22:36, 14 February 2008 (PST)
* Install XCode Developers Tools from DVD/CD Installation Disk or download from http://developer.apple.com/. You have to create an Apple account to access the downloads if you don't have an Apple account.
* Install X11 for 10.4 from the Optional Install from the DVD/CD Installation Disk. X11 for 10.5 is installed by default.
* Install Mono 1.2.5 from http://ftp.novell.com/pub/mono/archive/1.2.5/macos-10-universal/5/MonoFramework-1.2.5_5.macos10.novell.universal.dmg and in Terminal or X11 edit the .profile file and add the following line:
export PKG_CONFIG_PATH="/Library/Frameworks/Mono.framework/Versions/1.2.5/lib/pkgconfig/:${PKG_CONFIG_PATH}"
* Compile OpenSim
svn co http://opensimulator.org/svn/opensim/tags/0.5.0-release opensim
cd opensim
./runprebuild.sh
nant

* Download and Compile libopenjpeg-libsl-2.1.2.0.dylib and libsecondlife.dll
* libopenjpeg-libsl-2.1.2.0.dylib:
svn co http://opensimulator.org/svn/opensim-libs/libsl1550 opensim-libs
cd opensim-libs/openjpeg-libsl
make -f Makefile.osx
cp libopenjpeg-libsl-2.1.2.0.dylib ../../opensim/bin
* Note: The Makefile that creates the libopenjpeg-libsl-2.1.2.0.so does not compile on PowerPC, not sure about Intel. Looks like a gcc issue with compile options.

* libsecondlife.dll: (for PowerPC Only, see details on this step [http://xyzzyxyzzy.net/2008/02/12/installing-opensim-on-powerpcor-of-eggs-and-virtual-worlds installing OpenSim on PowerPC…or: of eggs and virtual worlds])
cd .. (back into opensim-libs)
nant
cp libsecondlife.dll ../../opensim/bin

* Edit the libsecondlife.dll.config (PowerPC Only). Remove the cpu="x86" tag in the last dllmap line.

'''RedHat'''
sudo vi /etc/yum.repos.d/mono.repo

[mono]
name=Mono for rhel-4-i386 (stable)
baseurl=http://ftp.novell.com/pub/mono/download-stable/rhel-4-i386/
enabled=1
gpgcheck=0

sudo yum install mono-complete monodoc-core nant
svn co svn co http://opensimulator.org/svn/opensim/trunk opensim
cd opensim
./runprebuild.sh
nant

'''Fedora 5'''
* I needed to build latest mono and nant from sources to build OpenSim successfully, the ones available in yum repository didn't work so I had to uninstall and build and configure the packages.

For detailed instructions go [http://ruakuu.blogspot.com/2008/06/installing-and-configuring-opensim-on.html here]

=== Physics ===
If you want to implement collision-based physics, OpenDynamicsEngine (ODE) is the furthest along at the moment (9/07). It is not fully supported, but is starting to work somewhat reliably using a small number of regions per sim.

==== Open Dynamics Engine (ODE) ====
As installed from svn, ODE does not work on all platforms. If you get an ODE-related crash, and/or a libode.so not found type of error, you will need to build libode from source.

Remove <tt>libode.so</tt> from the <tt>./bin</tt> folder. (Note that subsequent svn updates may replace it again; best fix is to copy your built <tt>libode.so</tt> to <tt>bin</tt>). Do NOT remove <tt>ode.net.dll</tt>! Download the latest source packages from http://www.ode.org/. When compiling, make sure to use the following configure options:

--with-trimesh=gimpact
--enable-shared

Make sure the configure script confirms these choices, and always compile with single precision (I believe that's the default). Try <code> make -k </code> if you get errors relating to drawstuff, test*, or openGL. <code> make install </code> should put <tt>libode.so</tt> in the proper place (usually <tt>/usr/local/lib</tt>), and it should be seen by opensim (<tt>ode.net.dll</tt>)

===Running===
Recent versions of OpenSim come without an <tt>OpenSim.ini</tt> file. Copy the <tt>OpenSim.ini.example</tt> file to <tt>OpenSim.ini</tt> before making any changes.
cd bin
mono OpenSim.exe

* To invoke ODE, add the option:
-physics=OpenDynamicsEngine
to the <tt>mono OpenSim.exe</tt> line

or add <code> physics = OpenDynamicsEngine </code> to the [Startup] section of <tt>OpenSim.ini</tt>. Same deal for other physics engines, when available.

On mono 1.2.6, some distributions may see
Unhandled Exception: System.NotSupportedException: CodePage 1252 not supported
on startup when using mysql. This can be resolved by installing the package libmono-i18n2.0-cil (see http://bugs.mysql.com/bug.php?id=33938).

===Dependencies===
The following packages and their dependencies are required to run OpenSim on a default Debian 4 netinstall:
* mono
* libmono-corlib2.0-cil
* libmono-sqlite2.0-cil
* libmono-system-web2.0-cil
* libmono-microsoft8.0-cil
* libmono-system-runtime2.0-cil
[[Category:Users]]