OpenSimulator - User contributions [en]

JabberBridge

2009-02-19T15:39:23Z

MW2:

The JabberBridge is part of the Parallel Selves Message Bridge Project. [Currently only works properly in standalone mode]

[To use it, you need a account set up on a Jabber compatible server. That will act as the master bridging account]

The code can be checked out from:
svn checkout http://forge.opensimulator.org/svn/psimb

Using 'anonymous' as the username and leaving the password blank.

* Once you have compiled that, copy PSMessageBridge.dll and jabber-net.dll to your opensim bin folder.
* Edit your opensim.ini file so that under the [Messaging] section it has a entry:
MessageTransferModule = JabberTransferModule
* Then add a new section at the bottom of your opensim.ini file like:

[JabberBridge]
enable = true
privateAccounts = true
account = <Jabber Account Username>
server = <Jabber Server Url>
password = <Jabber account password>

Replacing the Jabber Account and server details for the real ones.

Then you are ready to start using it. When a user logs in, they will get a IM from the "Jabber Console", which acts as the control console for all Jabber related commands. So don't close that IM session.

The first mode, is everyone uses the Jabber master bridge account, that was set in the ini file. This allows users to start two way chat sessions with any Jabber user. But as all the messages are routed through the master account, the person you are trying to talk to, will maybe not realise who you are and could block you. This also could be open for abuse, with people sending annoying messages to people using that account.

To open a chat session, using the Master account. Just type in the Jabber Console IM session: 'New session: <jabberName@JabberServerURL>' So for example 'New session: OpenSimTester@Jabber.org'.

The second mode of usage, is where everyone can use their own private account. To start using this, in the Jabber Console IM session, type 'Open Account: <JabberUserName> <JabberServerUrl> <password>' (A space between each of those elements).

Then you can start chat sessions in the same way as above. Also your Jabber friends will be able to see your online and start chat sessions with you.

Once you have finished using the Bridge, remember to close your account/ sign off. By typing in the Jabber Console session: 'Close account:'

JabberBridge

2009-02-19T15:38:58Z

MW2:

The JabberBridge is part of the Parallel Selves Message Bridge Project. [Currently only works properly in standalone mode]

[To use it, you need a account set up on a Jabber compatible server. That will act as the master bridging account]

The code can be checked out from:
svn checkout http://forge.opensimulator.org/svn/psimb

Using 'anonymous' as the username and leaving the password blank.

* Once you have compiled that, copy PSMessageBridge.dll and jabber-net.dll to your opensim bin folder.
* Edit your opensim.ini file so that under the [Messaging] section it has a entry:
MessageTransferModule = JabberTransferModule
* Then add a new section at the bottom of your ini file like:

[JabberBridge]
enable = true
privateAccounts = true
account = <Jabber Account Username>
server = <Jabber Server Url>
password = <Jabber account password>

Replacing the Jabber Account and server details for the real ones.

Then you are ready to start using it. When a user logs in, they will get a IM from the "Jabber Console", which acts as the control console for all Jabber related commands. So don't close that IM session.

The first mode, is everyone uses the Jabber master bridge account, that was set in the ini file. This allows users to start two way chat sessions with any Jabber user. But as all the messages are routed through the master account, the person you are trying to talk to, will maybe not realise who you are and could block you. This also could be open for abuse, with people sending annoying messages to people using that account.

To open a chat session, using the Master account. Just type in the Jabber Console IM session: 'New session: <jabberName@JabberServerURL>' So for example 'New session: OpenSimTester@Jabber.org'.

The second mode of usage, is where everyone can use their own private account. To start using this, in the Jabber Console IM session, type 'Open Account: <JabberUserName> <JabberServerUrl> <password>' (A space between each of those elements).

Then you can start chat sessions in the same way as above. Also your Jabber friends will be able to see your online and start chat sessions with you.

Once you have finished using the Bridge, remember to close your account/ sign off. By typing in the Jabber Console session: 'Close account:'

JabberBridge

2009-02-19T15:18:42Z

MW2:

The JabberBridge is part of the Parallel Selves Message Bridge Project. [Currently only works properly in standalone mode]

[To use it, you need a account set up on a Jabber compatible server. That will act as the master bridging account]

The code can be checked out from:
svn checkout http://forge.opensimulator.org/svn/psimb

Using 'anonymous' as the username and leaving the password blank.

* Once you have compiled that, copy PSMessageBridge.dll and jabber-net.dll to your opensim bin folder.
* Edit your opensim.ini file so that under the [Messaging] section it has a entry: MessageTransferModule = JabberTransferModule
* Then add a new section at the bottom of your ini file like:

[JabberBridge]
enable = true
privateAccounts = true
account = <Jabber Account Username>
server = <Jabber Server Url>
password = <Jabber account password>

Replacing the Jabber Account and server details for the real ones.

Then you are ready to start using it. When a user logs in, they will get a IM from the "Jabber Console", which acts as the control console for all Jabber related commands. So don't close that IM session.

The first mode, is everyone uses the Jabber master bridge account, that was set in the ini file. This allows users to start two way chat sessions with any Jabber user. But as all the messages are routed through the master account, the person you are trying to talk to, will maybe not realise who you are and could block you. This also could be open for abuse, with people sending annoying messages to people using that account.

To open a chat session, using the Master account. Just type in the Jabber Console IM session: 'New session: <jabberName@JabberServerURL>' So for example 'New session: OpenSimTester@Jabber.org'.

The second mode of usage, is where everyone can use their own private account. To start using this, in the Jabber Console IM session, type 'Open Account: <JabberUserName> <JabberServerUrl> <password>' (A space between each of those elements).

Then you can start chat sessions in the same way as above. Also your Jabber friends will be able to see your online and start chat sessions with you.

Once you have finished using the Bridge, remember to close your account/ sign off. By typing in the Jabber Console session: 'Close account:'

JabberBridge

2009-02-19T15:14:37Z

MW2: New page: The JabberBridge is part of the Parallel Selves Message Bridge Project. [Currently only works properly in standalone mode] [To use it, you need a account set up on a Jabber compatible ser...

The JabberBridge is part of the Parallel Selves Message Bridge Project. [Currently only works properly in standalone mode]

[To use it, you need a account set up on a Jabber compatible server. That will act as the master bridging account]

The code can be checked out from:
svn checkout http://forge.opensimulator.org/svn/psimb

Using 'anonymous' as the username and leaving the password blank.

* Once you have compiled that, copy PSMessageBridge.dll and jabber-net.dll to your opensim bin folder.
* Edit your opensim.ini file so that under the [Messaging] section it has a entry: MessageTransferModule = JabberTransferModule
* Then add a new section at the bottom of your ini file like:

[JabberBridge]
enable = true
privateAccounts = true
account = <Jabber Account Username>
server = <Jabber Server Url>
password = <Jabber account password>

Replacing the Jabber Account and server details for the real ones.

Then you are ready to start using it. When a user logs in, they will get a IM from the "Jabber Console", which acts as the control console for all Jabber related commands. So don't close that IM session.

The first mode, is everyone uses the Jabber master bridge account, that was set in the ini file. This allows users to start two way chat sessions with any Jabber user. But as all the messages are routed through the master account, the person you are trying to talk to, maybe not realise who you are and could block you. This also could be open for abuse, we people sending annoying messages to people using that account.

To open a chat session, using the Master account. Just type in the Jabber Console IM session: 'New session: <jabberName@JabberServerURL>' So for example 'New session: OpenSimTester@Jabber.org'.

The second mode of usage, is where everyone can use their own private account. To start using this, in the Jabber Console IM session, type 'Open Account: <JabberUserName> <JabberServerUrl> <password>' (A space between each of those elements).

Then you can start chat sessions in the same way as above. Also your Jabber friends will be able to see your online and start chat sessions with you.

Once you have finished using the Bridge, remember to close your account/ sign off. By typing in the Jabber Console session: 'Close account:'

User Documentation

2009-02-19T14:55:24Z

MW2: /* Gforge Projects */

{{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 />

Prim Linking Testing

2009-02-02T19:55:35Z

MW2:

Linking and unlinking of prims seems to be one area where there are quite a few problems and bugs in OpenSimulator. So to help us track down the issues, we are creating a set of test cases so we can try to see what works and what doesn't work.

The following initial set of test cases has been created to try to test most of the issues (on linking/unlinking) that have been reported in mantis. It will help greatly if as many people as possible try them out and report back their findings. And also add any new test cases they can think of to the list.

----

'''#1 Linking prims one by one into a link set, causes rotation issues on child prims'''

Test 1.1:

* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.2:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Edit each prim to give each one random properties. [Hollow, twist ,etc]
* Give each prim a random rotation.
* Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.3:
* Create four copies of the linkset from test 2.
* Give each linkset a random rotation.
* Link all the linksets together.
* Check rotations.
* Turn the whole set physical.
* Check for artifacts.
* Unlink the whole set.
* Check that the prims are still physical
* And check for any other changes.

Results:
* [MW] All tests passed without any issues.

'''#2 Editing rotations linked parts within linksets causes problems.'''

Test 2.1:

* Create a single box prim, and drag-shift copy it to create 11 prims.
* Select one prim to be the root and then link the other 10 prims to it.
* Enable edit linked parts.
* Select a child prim and rotate it. [Repeat on 4 other child prims]
* Select root part and rotate it.

Results:
* [MW] Passed without any issues.

'''#3 When creating or shift-drag copying a link set of 6-8 prims (or larger) [with a distance bewteen each prim of >10], by linking all the child prims in one go. The child prims will not collide with avatars/other prims.'''

Test 3.1:
* Create a single box prim, and drag-shift copy it to create 8 prims.
* Move each prim so they are separated by at least 10 units from each on all axis.
* Pick a prim that will be the root prim.
* Select all other prims apart from the root prim and link them to the root prim.
* Try walking through the child pims.

Results:
* [MW] Passed without any issues.

'''#4 Changes to hollow, twist and other prim settings, on child prims in a linkset, don't stick once the linkset is moved or unlinked. The prims revert back to old values.'''

Test 4.1:
* Create a single box prim, and drag-shift copy it to create 5 prims..
* Select one prim to be the root and then link the other 4 prims to it.
* Enable edit linked parts.
* Edit the child prims, so that they have random values for twist, hollow, etc.
* Unselect the prim and exit edit mode.
* Check the child prims still have the values that were set.
* Move the linked set and again check values.
* Unlink the whole linkset, and check values on each prim.

Results:
* [MW] Passed without any issues.

'''#5 Extending a linkset breaks the rotation of child prims.'''

Test 5.1:
* Rezz a cube and a pyramid to the right, rotate the pyramid along the Y axis to 270 degrees (top facing the cube)
* Build a linkset with the cube as the root prim and rotate it along the Z axis to 60 degrees
* Rezz another prim and extend the linkset with the new prim as root.
* Check the rotation of the prims is still correct.

Results:
* [MW] Passed without any issues.

'''#6 Sometimes, linking a linkset to another linkset will cause prims to rotate randomly.'''

Test 6.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat the 3 steps above, to create a second link set.
* Link the two linksets together, and check rotations don't change

Results:
* [MW] Passed without any issues.

'''#7 When linking two or more linked sets together and at least one of the linked sets contains hollowed and/or cut cylinders. Prims rotation will “explode”.'''

Test 7.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Edit each prim to give them random properties for hollow and/or cut.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat the 3 steps above, to create a second link set.
* Link the two linksets together, and check rotations don't change

Results:
* [MW] Passed without any issues.

'''#8 Rotation of child prims become jumbled after adding a rotated prim or secondary link set to an existing link set.'''

Test 8.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Create another single prim and give it a random rotation.
* Link that single prim to the previously created linkset, with the linkset being the parent.
* Check rotation of child prims.
* Create a second single prim and again give it a random rotation.
* Link the previous linkset to that prim, with the prim being the parent.
* Check rotations of child prims.

Results:
* [MW] Passed without any problems

'''#9 Unlink from >=~500 linked prims end with avatar freeze and slow to respond region.'''

Test 9.1:
* Create a single box prim, and drag-shift copy it to create 10 prims.
* Rotate each prim so it has a random rotation.
* Select all prims and shift-drag copy them and repeat until there are at least 100 prims.
* Link all prims together.
* Shift copy the linkset 5 times and then link all linksets into a single set.
* Enabled edit linked parts and select a group of prims (say 200), and unlink them from the rest.
* Check avatar can still walk.
* Link all the prims back into a single linkset.
* Unlink whole linkset.
* Check Avatar can still walk.

Results:
* [MW] For the user who unlinked the set, he doesn't see the region responding to his movements or commands, but other users on the same region can see him moving around. Also for those other users the region can be slow to respond to any commands.
Plus once the user who unlinked the set, moves to the edge of the region, the region server starts to lag very badly, with repeated console messages. [This was done on a region with no direct neighbours.]

'''#10 After unlinking and deleting parts of a linkset, then logging off and back on, the deleted parts will still be there.'''

Test 10.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Select one prim to be the root and then link the other 10 prims to it.
* Select a few prims and unlink them from the link set.
* Delete the unlinked prims
* Log off
* Log back on and see if the deleted prims are still there.

Results:
* [MW] Passed without any issues.

'''#11 After unlinking and deleting parts (or taking them into inventory) of a linkset, then restarting the region, the deleted parts will still be there.'''

Test 11.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat to create a second linkset.
* Log off, and restart region.
* Log back on and check the linksets are there as they were.
* Create a single prim and give it a random rotation and properties.
* Add that new prim, to linkset #1, with it being a child prim.
* Unlink and delete a single prim from linkset #2.
* Log off, and restart region.
* Log back on and check the changes to the linksets were persisted.

Results:
* [MW] Restarting the region after unlinking and then deleting a prim or taking it into inventory, will result in the prim being back as part of the linkset, after the restart.

'''#12 Large Scale Link Test.'''

Test 12.1:
* Create a prim, and then shift-drag copy it to make four prims in a square.
* Give each prim a random rotation and properties.
* Shift-drag all four prims until there are 64 prims.
* Shift-drag all 64 prims, until there are 256 prims.
* Shift-drag all 256 prims until there are 1024 prims.
* Link all the prims into 4 linksets of 256 prims each.
* Give each linkset a random rotation.
* Link all 4 linksets together.
* Shift-drag copy the whole linkset four times.
* Give all 4 linksets a random roation, and then link them all together.
* Check the rotations haven't changed.

Results:
* [MW] Passed without any issues.

Prim Linking Testing

2009-02-02T11:40:13Z

MW2:

Prim Linking Testing

2009-02-02T11:38:54Z

MW2:

Linking and unlinking of prims seems to be one area of quite a few problems and bugs in OpenSimulator. So to help us track down the issues, we are creating a set of test cases so we can try to see what works and what doesn't work.

The following initial set of test cases has been created to try to test most of the issues (on linking/unlinking) that have been reported in mantis. It will help greatly if as many people as possible try them out and report back their findings. And also add any new test cases they can think of to the list.

----

'''#1 Linking prims one by one into a link set, causes rotation issues on child prims'''

Test 1.1:

* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.2:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Edit each prim to give each one random properties. [Hollow, twist ,etc]
* Give each prim a random rotation.
* Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.3:
* Create four copies of the linkset from test 2.
* Give each linkset a random rotation.
* Link all the linksets together.
* Check rotations.
* Turn the whole set physical.
* Check for artifacts.
* Unlink the whole set.
* Check that the prims are still physical
* And check for any other changes.

Results:
* [MW] All tests passed without any issues.

'''#2 Editing rotations linked parts within linksets causes problems.'''

Test 2.1:

* Create a single box prim, and drag-shift copy it to create 11 prims.
* Select one prim to be the root and then link the other 10 prims to it.
* Enable edit linked parts.
* Select a child prim and rotate it. [Repeat on 4 other child prims]
* Select root part and rotate it.

Results:
* [MW] Passed without any issues.

'''#3 When creating or shift-drag copying a link set of 6-8 prims (or larger) [with a distance bewteen each prim of >10], by linking all the child prims in one go. The child prims will not collide with avatars/other prims.'''

Test 3.1:
* Create a single box prim, and drag-shift copy it to create 8 prims.
* Move each prim so they are separated by at least 10 units from each on all axis.
* Pick a prim that will be the root prim.
* Select all other prims apart from the root prim and link them to the root prim.
* Try walking through the child pims.

Results:
* [MW] Passed without any issues.

'''#4 Changes to hollow, twist and other prim settings, on child prims in a linkset, don't stick once the linkset is moved or unlinked. The prims revert back to old values.'''

Test 4.1:
* Create a single box prim, and drag-shift copy it to create 5 prims..
* Select one prim to be the root and then link the other 4 prims to it.
* Enable edit linked parts.
* Edit the child prims, so that they have random values for twist, hollow, etc.
* Unselect the prim and exit edit mode.
* Check the child prims still have the values that were set.
* Move the linked set and again check values.
* Unlink the whole linkset, and check values on each prim.

Results:
* [MW] Passed without any issues.

'''#5 Extending a linkset breaks the rotation of child prims.'''

Test 5.1:
* Rezz a cube and a pyramid to the right, rotate the pyramid along the Y axis to 270 degrees (top facing the cube)
* Build a linkset with the cube as the root prim and rotate it along the Z axis to 60 degrees
* Rezz another prim and extend the linkset with the new prim as root.
* Check the rotation of the prims is still correct.

Results:
* [MW] Passed without any issues.

'''#6 Sometimes, linking a linkset to another linkset will cause prims to rotate randomly.'''

Test 6.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat the 3 steps above, to create a second link set.
* Link the two linksets together, and check rotations don't change

Results:
* [MW] Passed without any issues.

'''#7 When linking two or more linked sets together and at least one of the linked sets contains hollowed and/or cut cylinders. Prims rotation will “explode”.'''

Test 7.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Edit each prim to give them random properties for hollow and/or cut.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat the 3 steps above, to create a second link set.
* Link the two linksets together, and check rotations don't change

Results:
* [MW] Passed without any issues.

'''#8 Rotation of child prims become jumbled after adding a rotated prim or secondary link set to an existing link set.'''

Test 8.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Create another single prim and give it a random rotation.
* Link that single prim to the previously created linkset, with the linkset being the parent.
* Check rotation of child prims.
* Create a second single prim and again give it a random rotation.
* Link the previous linkset to that prim, with the prim being the parent.
* Check rotations of child prims.

Results:
* [MW] Passed without any problems

'''#9 Unlink from >=~500 linked prims end with avatar freeze and slow to respond region.'''

Test 9.1:
* Create a single box prim, and drag-shift copy it to create 10 prims.
* Rotate each prim so it has a random rotation.
* Select all prims and shift-drag copy them and repeat until there are at least 100 prims.
* Link all prims together.
* Shift copy the linkset 5 times and then link all linksets into a single set.
* Enabled edit linked parts and select a group of prims (say 200), and unlink them from the rest.
* Check avatar can still walk.
* Link all the prims back into a single linkset.
* Unlink whole linkset.
* Check Avatar can still walk.

Results:
* [MW] For the user who unlinked the set, he doesn't see the region responding to his movements or commands, but other users on the same region can see him moving around. Also for those other users the region can be slow to respond to any commands.
Plus once the user who unlinked the set, moves to the edge of the region, the region server starts to lag very badly, with repeated console messages. [This was done on a region with no direct neighbours.]

'''#10 After unlinking and deleting parts of a linkset, then logging off and back on, the deleted parts will still be there.'''

Test 10.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Select one prim to be the root and then link the other 10 prims to it.
* Select a few prims and unlink them from the link set.
* Delete the unlinked prims
* Log off
* Log back on and see if the deleted prims are still there.

Results:
* [MW] Passed without any issues.

'''#11 After unlinking and deleting parts (or taking them into inventory) of a linkset, then restarting the region, the deleted parts will still be there.'''

Test 11.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat to create a second linkset.
* Log off, and restart region.
* Log back on and check the linksets are there as they were.
* Create a single prim and give it a random rotation and properties.
* Add that new prim, to linkset #1, with it being a child prim.
* Unlink and delete a single prim from linkset #2.
* Log off, and restart region.
* Log back on and check the changes to the linksets were persisted.

Results:
* [MW] Restarting the region after unlinking and then deleting a prim or taking it into inventory, will result in the prim being back as part of the linkset, after the restart.

'''#12 Large Scale Link Test.'''

Test 12.1:
* Create a prim, and then shift-drag copy it to make four prims in a square.
* Give each prim a random rotation and properties.
* Shift-drag all four prims until there are 64 prims.
* Shift-drag all 64 prims, until there are 256 prims.
* Shift-drag all 256 prims until there are 1024 prims.
* Link all the prims into 4 linksets of 256 prims each.
* Give each linkset a random rotation.
* Link all 4 linksets together.
* Shift-drag copy the whole linkset four times.
* Give all 4 linksets a random roation, and then link them all together.
* Check the rotations haven't changed.

Results:
* [MW] Passed without any issues.

Prim Linking Testing

2009-02-02T11:37:13Z

MW2:

Linking and unlinking of prims seems to be one area of quite a few problems and bugs in OpenSimulator. So to help us track down the issues, we are creating a set of test cases so we can try to see what works and what doesn't work.

The following initial set of test cases has been created to try to test most of the issues (on linking/unlinking) that have been reported in mantis. It will help greatly if as many people as possible try them out and report back their findings. And also add any new test cases they can think of to the list.

----

'''#1 Linking prims one by one into a link set, causes rotation issues on child prims'''

Test 1.1:

* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.2:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Edit each prim to give each one random properties. [Hollow, twist ,etc]
* Give each prim a random rotation.
* Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.3:
* Create four copies of the linkset from test 2.
* Give each linkset a random rotation.
* Link all the linksets together.
* Check rotations.
* Turn the whole set physical.
* Check for artifacts.
* Unlink the whole set.
* Check that the prims are still physical
* And check for any other changes.

Results:
* [MW] All tests passed without any issues.

'''#2 Editing rotations linked parts within linksets causes problems.'''

Test 2.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Select one prim to be the root and then link the other 10 prims to it.
* Enable edit linked parts.
* Select a child prim and rotate it. [Repeat on 4 other child prims]
* Select root part and rotate it.

Results:
* [MW] Passed without any issues.

'''#3 When creating or shift-drag copying a link set of 6-8 prims (or larger) [with a distance bewteen each prim of >10], by linking all the child prims in one go. The child prims will not collide with avatars/other prims.'''

Test 3.1:
* Create a single box prim, and drag-shift copy it to create 8 prims.
* Move each prim so they are separated by at least 10 units from each on all axis.
* Pick a prim that will be the root prim.
* Select all other prims apart from the root prim and link them to the root prim.
* Try walking through the child pims.

Results:
* [MW] Passed without any issues.

'''#4 Changes to hollow, twist and other prim settings, on child prims in a linkset, don't stick once the linkset is moved or unlinked. The prims revert back to old values.'''

Test 4.1:
* Create a single box prim, and drag-shift copy it to create 5 prims..
* Select one prim to be the root and then link the other 4 prims to it.
* Enable edit linked parts.
* Edit the child prims, so that they have random values for twist, hollow, etc.
* Unselect the prim and exit edit mode.
* Check the child prims still have the values that were set.
* Move the linked set and again check values.
* Unlink the whole linkset, and check values on each prim.

Results:
* [MW] Passed without any issues.

'''#5 Extending a linkset breaks the rotation of child prims.'''

Test 5.1:
* Rezz a cube and a pyramid to the right, rotate the pyramid along the Y axis to 270 degrees (top facing the cube)
* Build a linkset with the cube as the root prim and rotate it along the Z axis to 60 degrees
* Rezz another prim and extend the linkset with the new prim as root.
* Check the rotation of the prims is still correct.

Results:
* [MW] Passed without any issues.

'''#6 Sometimes, linking a linkset to another linkset will cause prims to rotate randomly.'''

Test 6.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat the 3 steps above, to create a second link set.
* Link the two linksets together, and check rotations don't change

Results:
* [MW] Passed without any issues.

'''#7 When linking two or more linked sets together and at least one of the linked sets contains hollowed and/or cut cylinders. Prims rotation will “explode”.'''

Test 7.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Edit each prim to give them random properties for hollow and/or cut.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat the 3 steps above, to create a second link set.
* Link the two linksets together, and check rotations don't change

Results:
* [MW] Passed without any issues.

#8 Rotation of child prims become jumbled after adding a rotated prim or secondary link set to an existing link set.

Test 8.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Create another single prim and give it a random rotation.
* Link that single prim to the previously created linkset, with the linkset being the parent.
* Check rotation of child prims.
* Create a second single prim and again give it a random rotation.
* Link the previous linkset to that prim, with the prim being the parent.
* Check rotations of child prims.

Results:
* [MW] Passed without any problems

'''#9 Unlink from >=~500 linked prims end with avatar freeze and slow to respond region.'''

Test 9.1:
* Create a single box prim, and drag-shift copy it to create 10 prims.
* Rotate each prim so it has a random rotation.
* Select all prims and shift-drag copy them and repeat until there are at least 100 prims.
* Link all prims together.
* Shift copy the linkset 5 times and then link all linksets into a single set.
* Enabled edit linked parts and select a group of prims (say 200), and unlink them from the rest.
* Check avatar can still walk.
* Link all the prims back into a single linkset.
* Unlink whole linkset.
* Check Avatar can still walk.

Results:
* [MW] For the user who unlinked the set, he doesn't see the region responding to his movements or commands, but other users on the same region can see him moving around. Also for those other users the region can be slow to respond to any commands.
Plus once the user who unlinked the set, moves to the edge of the region, the region server starts to lag very badly, with repeated console messages. [This was done on a region with no direct neighbours.]

'''#10 After unlinking and deleting parts of a linkset, then logging off and back on, the deleted parts will still be there.'''

Test 10.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Select one prim to be the root and then link the other 10 prims to it.
* Select a few prims and unlink them from the link set.
* Delete the unlinked prims
* Log off
* Log back on and see if the deleted prims are still there.

Results:
* [MW] Passed without any issues.

'''#11 After unlinking and deleting parts (or taking them into inventory) of a linkset, then restarting the region, the deleted parts will still be there.'''

Test 11.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat to create a second linkset.
* Log off, and restart region.
* Log back on and check the linksets are there as they were.
* Create a single prim and give it a random rotation and properties.
* Add that new prim, to linkset #1, with it being a child prim.
* Unlink and delete a single prim from linkset #2.
* Log off, and restart region.
* Log back on and check the changes to the linksets were persisted.

Results:
* [MW] Restarting the region after unlinking and then deleting a prim or taking it into inventory, will result in the prim being back as part of the linkset, after the restart.

'''#12 Large Scale Link Test.'''

Test 12.1:
* Create a prim, and then shift-drag copy it to make four prims in a square.
* Give each prim a random rotation and properties.
* Shift-drag all four prims until there are 64 prims.
* Shift-drag all 64 prims, until there are 256 prims.
* Shift-drag all 256 prims until there are 1024 prims.
* Link all the prims into 4 linksets of 256 prims each.
* Give each linkset a random rotation.
* Link all 4 linksets together.
* Shift-drag copy the whole linkset four times.
* Give all 4 linksets a random roation, and then link them all together.
* Check the rotations haven't changed.

Results:
* [MW] Passed without any issues.

Prim Linking Testing

2009-02-02T11:36:03Z

MW2:

Linking and unlinking of prims seems to be one area of quite a few problems and bugs in OpenSimulator. So to help us track down the issues, we are creating a set of test cases so we can try to see what works and what doesn't work.

The following initial set of test cases has been created to try to test most of the issues (on linking/unlinking) that have been reported in mantis. It will help greatly if as many people as possible try them out and report back their findings. And also add any new test cases they can think of to the list.

----

'''#1 Linking prims one by one into a link set, causes rotation issues on child prims'''

Test 1.1:

* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.2:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Edit each prim to give each one random properties. [Hollow, twist ,etc]
* Give each prim a random rotation.
* Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.3:
* Create four copies of the linkset from test 2.
* Give each linkset a random rotation.
* Link all the linksets together.
* Check rotations.
* Turn the whole set physical.
* Check for artifacts.
* Unlink the whole set.
* Check that the prims are still physical
* And check for any other changes.

Results:
* [MW] All tests passed without any issues.

'''#2 Editing rotations linked parts within linksets causes problems.'''

Test 2.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Select one prim to be the root and then link the other 10 prims to it.
* Enable edit linked parts.
* Select a child prim and rotate it. [Repeat on 4 other child prims]
* Select root part and rotate it.

Results:
* [MW] Passed without any issues.

'''#3 When creating or shift-drag copying a link set of 6-8 prims (or larger) [with a distance bewteen each prim of >10], by linking all the child prims in one go. The child prims will not collide with avatars/other prims.'''

Test 3.1:
* Create a single box prim, and drag-shift copy it to create 8 prims.
* Move each prim so they are separated by at least 10 units from each on all axis.
* Pick a prim that will be the root prim.
* Select all other prims apart from the root prim and link them to the root prim.
* Try walking through the child pims.

Results:
* [MW] Passed without any issues.

'''#4 Changes to hollow, twist and other prim settings, on child prims in a linkset, don't stick once the linkset is moved or unlinked. The prims revert back to old values.'''

Test 4.1:
* Create a single box prim, and drag-shift copy it to create 5 prims..
* Select one prim to be the root and then link the other 4 prims to it.
* Enable edit linked parts.
* Edit the child prims, so that they have random values for twist, hollow, etc.
* Unselect the prim and exit edit mode.
* Check the child prims still have the values that were set.
* Move the linked set and again check values.
* Unlink the whole linkset, and check values on each prim.

Results:
* [MW] Passed without any issues.

'''#5 Extending a linkset breaks the rotation of child prims.'''

Test 5.1:
* Rezz a cube and a pyramid to the right, rotate the pyramid along the Y axis to 270 degrees (top facing the cube)
* Build a linkset with the cube as the root prim and rotate it along the Z axis to 60 degrees
* Rezz another prim and extend the linkset with the new prim as root.
* Check the rotation of the prims is still correct.

Results:
* [MW] Passed without any issues.

'''#6 Sometimes, linking a linkset to another linkset will cause prims to rotate randomly.'''

Test 6.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat the 3 steps above, to create a second link set.
* Link the two linksets together, and check rotations don't change

Results:
* [MW] Passed without any issues.

'''#7 When linking two or more linked sets together and at least one of the linked sets contains hollowed and/or cut cylinders. Prims rotation will “explode”.'''

Test 7.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Edit each prim to give them random properties for hollow and/or cut.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat the 3 steps above, to create a second link set.
* Link the two linksets together, and check rotations don't change

Results:
* [MW] Passed without any issues.

#8 Rotation of child prims become jumbled after adding a rotated prim or secondary link set to an existing link set.

Test 8.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Create another single prim and give it a random rotation.
* Link that single prim to the previously created linkset, with the linkset being the parent.
* Check rotation of child prims.
* Create a second single prim and again give it a random rotation.
* Link the previous linkset to that prim, with the prim being the parent.
* Check rotations of child prims.

Results:
* [MW] Passed without any problems

'''#9 Unlink from >=~500 linked prims end with avatar freeze and slow to respond region.'''

Test 9.1:
* Create a single box prim, and drag-shift copy it to create 10 prims.
* Rotate each prim so it has a random rotation.
* Select all prims and shift-drag copy them and repeat until there are at least 100 prims.
* Link all prims together.
* Shift copy the linkset 5 times and then link all linksets into a single set.
* Enabled edit linked parts and select a group of prims (say 200), and unlink them from the rest.
* Check avatar can still walk.
* Link all the prims back into a single linkset.
* Unlink whole linkset.
* Check Avatar can still walk.

Results:
* [MW] For the user who unlinked the set, he doesn't see the region responding to his movements or commands, but other users on the same region can see him moving around. Also for those other users the region can be slow to respond to any commands.
Plus once the user who unlinked the set, moves to the edge of the region, the region server starts to lag very badly, with repeated console messages. [This was done on a region with no direct neighbours.]

'''#10 After unlinking and deleting parts of a linkset, then logging off and back on, the deleted parts will still be there.'''

Test 10.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Select one prim to be the root and then link the other 10 prims to it.
* Select a few prims and unlink them from the link set.
* Delete the unlinked prims
* Log off
* Log back on and see if the deleted prims are still there.

Results:
* [MW] Passed without any issues.

'''#11 After unlinking and deleting parts (or taking them into inventory) of a linkset, then restarting the region, the deleted parts will still be there.'''

Test 11.1:
* Create a single box prim, and drag-shift copy it to create 11 prims.
* Rotate each prim so it has a random rotation.
* Select one prim to be the root and then link the other 10 prims to it.
* Repeat to create a second linkset.
* Log off, and restart region.
* Log back on and check the linksets are there as they were.
* Create a single prim and give it a random rotation and properties.
* Add that new prim, to linkset #1, with it being a child prim.
* Unlink and delete a single prim from linkset #2.
* Log off, and restart region.
* Log back on and check the changes to the linksets were persisted.

Results:
* [MW] Restarting the region after unlinking and then deleting a prim or taking it into inventory, will result in the prim being back as part of the linkset, after the restart.

'''#12 Large Scale Link Test.'''

Test 12.1:
* Create a prim, and then shift-drag copy it to make four prims in a square.
* Give each prim a random rotation and properties.
* Shift-drag all four prims until there are 64 prims.
* Shift-drag all 64 prims, until there are 256 prims.
* Shift-drag all 256 prims until there are 1024 prims.
* Link all the prims into 4 linksets of 256 prims each.
* Give each linkset a random rotation.
* Link all 4 linksets together.
* Shift-drag copy the whole linkset four times.
* Give all 4 linksets a random roation, and then link them all together.
* Check the rotations haven't changed.

Results:
* [MW] Passed without any issues.

Prim Linking Testing

2009-02-02T11:29:22Z

MW2: New page: Linking and unlinking of prims seems to be one area of quite a few problems and bugs in OpenSimulator. So to help us track down the issues, we are creating a set of test cases so we can tr...

Linking and unlinking of prims seems to be one area of quite a few problems and bugs in OpenSimulator. So to help us track down the issues, we are creating a set of test cases so we can try to see what works and what doesn't work.

The following initial set of test cases has been created to try to test most of the issues (on linking/unlinking) that have been reported in mantis. It will help greatly if as many people as possible try them out and report back their findings. And also add any new test cases they can think of to the list.

----

'''#1 Linking prims one by one into a link set, causes rotation issues on child prims'''

Test 1.1:
Create a single box prim, and drag-shift copy it to create 11 prims.
Rotate each prim so it has a random rotation.
Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.2:
Create a single box prim, and drag-shift copy it to create 11 prims.
Edit each prim to give each one random properties. [Hollow, twist ,etc]
Give each prim a random rotation.
Select one prim to be the root and then one by one link the other 10 prims to it.

Test 1.3:
Create four copies of the linkset from test 2.
Give each linkset a random rotation.
Link all the linksets together.
Check rotations.
Turn the whole set physical.
Check for artifacts.
Unlink the whole set.
Check that the prims are still physical
And check for any other changes.

Results:
[MW] All tests passed without any issues.

'''#2 Editing rotations linked parts within linksets causes problems.'''

Test 2.1:
Create a single box prim, and drag-shift copy it to create 11 prims.
Select one prim to be the root and then link the other 10 prims to it.
Enable edit linked parts.
Select a child prim and rotate it. [Repeat on 4 other child prims]
Select root part and rotate it.

Results:
[MW] Passed without any issues.

'''#3 When creating or shift-drag copying a link set of 6-8 prims (or larger) [with a distance bewteen each prim of >10], by linking all the child prims in one go. The child prims will not collide with avatars/other prims.'''

Test 3.1:
Create a single box prim, and drag-shift copy it to create 8 prims.
Move each prim so they are separated by at least 10 units from each on all axis.
Pick a prim that will be the root prim.
Select all other prims apart from the root prim and link them to the root prim.
Try walking through the child pims.

Results:
[MW] Passed without any issues.

'''#4 Changes to hollow, twist and other prim settings, on child prims in a linkset, don't stick once the linkset is moved or unlinked. The prims revert back to old values.'''

Test 4.1:
Create a single box prim, and drag-shift copy it to create 5 prims..
Select one prim to be the root and then link the other 4 prims to it.
Enable edit linked parts.
Edit the child prims, so that they have random values for twist, hollow, etc.
Unselect the prim and exit edit mode.
Check the child prims still have the values that were set.
Move the linked set and again check values.
Unlink the whole linkset, and check values on each prim.

Results:
[MW] Passed without any issues.

'''#5 Extending a linkset breaks the rotation of child prims.'''

Test 5.1:
1) Rezz a cube and a pyramid to the right, rotate the pyramid along the Y axis to 270 degrees (top facing the cube)
2) Build a linkset with the cube as the root prim and rotate it along the Z axis to 60 degrees
3) Rezz another prim and extend the linkset with the new prim as root.
Check the rotation of the prims is still correct.

Results:
[MW] Passed without any issues.

'''#6 Sometimes, linking a linkset to another linkset will cause prims to rotate randomly.'''

Test 6.1:
Create a single box prim, and drag-shift copy it to create 11 prims.
Rotate each prim so it has a random rotation.
Select one prim to be the root and then link the other 10 prims to it.
Repeat the 3 steps above, to create a second link set.
Link the two linksets together, and check rotations don't change

Results:
Passed without any issues.

'''#7 When linking two or more linked sets together and at least one of the linked sets contains hollowed and/or cut cylinders. Prims rotation will “explode”.'''

Test 7.1:
Create a single box prim, and drag-shift copy it to create 11 prims.
Rotate each prim so it has a random rotation.
Edit each prim to give them random properties for hollow and/or cut.
Select one prim to be the root and then link the other 10 prims to it.
Repeat the 3 steps above, to create a second link set.
Link the two linksets together, and check rotations don't change

Results:
[MW] Passed without any issues.

#8 Rotation of child prims become jumbled after adding a rotated prim or secondary link set to an existing link set.

Test 8.1:
Create a single box prim, and drag-shift copy it to create 11 prims.
Rotate each prim so it has a random rotation.
Select one prim to be the root and then link the other 10 prims to it.
Create another single prim and give it a random rotation.
Link that single prim to the previously created linkset, with the linkset being the parent.
Check rotation of child prims.
Create a second single prim and again give it a random rotation.
Link the previous linkset to that prim, with the prim being the parent.
Check rotations of child prims.

Results:
[MW] Passed without any problems

'''#9 Unlink from >=~500 linked prims end with avatar freeze and slow to respond region.'''

Test 9.1:
Create a single box prim, and drag-shift copy it to create 10 prims.
Rotate each prim so it has a random rotation.
Select all prims and shift-drag copy them and repeat until there are at least 100 prims.
Link all prims together.
Shift copy the linkset 5 times and then link all linksets into a single set.
Enabled edit linked parts and select a group of prims (say 200), and unlink them from the rest.
Check avatar can still walk.
Link all the prims back into a single linkset.
Unlink whole linkset.
Check Avatar can still walk.

Results:
[MW] For the user who unlinked the set, he doesn't see the region responding to his movements or commands, but other users on the same region can see him moving around. Also for those other users the region can be slow to respond to any commands.
Plus once the user who unlinked the set, moves to the edge of the region, the region server starts to lag very badly, with repeated console messages. [This was done on a region with no direct neighbours.]

'''#10 After unlinking and deleting parts of a linkset, then logging off and back on, the deleted parts will still be there.'''

Test 10.1:
Create a single box prim, and drag-shift copy it to create 11 prims.
Select one prim to be the root and then link the other 10 prims to it.
Select a few prims and unlink them from the link set.
Delete the unlinked prims
Log off
Log back on and see if the deleted prims are still there.

Results:
[MW] Passed without any issues.

'''#11 After unlinking and deleting parts (or taking them into inventory) of a linkset, then restarting the region, the deleted parts will still be there.'''

Test 11.1:
Create a single box prim, and drag-shift copy it to create 11 prims.
Rotate each prim so it has a random rotation.
Select one prim to be the root and then link the other 10 prims to it.
Repeat to create a second linkset.
Log off, and restart region.
Log back on and check the linksets are there as they were.
Create a single prim and give it a random rotation and properties.
Add that new prim, to linkset #1, with it being a child prim.
Unlink and delete a single prim from linkset #2.
Log off, and restart region.
Log back on and check the changes to the linksets were persisted.

Results:
[MW] Restarting the region after unlinking and then deleting a prim or taking it into inventory, will result in the prim being back as part of the linkset, after the restart.

'''#12 Large Scale Test.'''

Test 12.1:
Create a prim, and then shift-drag copy it to make four prims in a square.
Give each prim a random rotation and properties.
Shift-drag all four prims until there are 64 prims.
Shift-drag all 64 prims, until there are 256 prims.
Shift-drag all 256 prims until there are 1024 prims.
Link all the prims into 4 linksets of 256 prims each.
Give each linkset a random rotation.
Link all 4 linksets together.
Shift-drag copy the whole linkset four times.
Give all 4 linksets a random roation, and then link them all together.

Results:
[MW] Passed without any issues.

Developer Documentation

2009-02-02T11:20:32Z

MW2: /* Testing */

{{Template:Quicklinks}}

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

==== General ====
* [[OpenSim:Introduction_and_Definitions]] — A work in progress describing the high level components of OpenSim
* [[OpenSim: TechRef]] — A technical description of the simulator operation.
* [[Grid Architecture Diagram]]
* [[OpenSim: Screenshots]] — Various OpenSim screenshots.
* [http://docs.opensimulator.org/index.html The OpenSim API]

==== Development ====
* [[Hacking OpenSim for fun and profit]] — A starters guide for programming OpenSim.
* [[Coding standards]] — Coding conventions for developers.
* [[Automated Testing]] — How to write tests for OpenSim.
* [[Branches]] — An overview of the repository branches and what they are for.
* [[Monodevelop]] — How to use the [[monodevelop]] IDE for editing C# solutions.
* [[Creating New Solution]] — How to create new solution according to OpenSim conventions.

==== Client Stacks ====
* [[Sim Throttles]] — Information on how OpenSim handles throttling of packets to the client.

==== Database ====
* [[Database Documentation]] — A map of grid and region instances used in OpenSim
* [[MonoSqlite]] — How the database model currently works.
* [[LSL:PrimitiveParams]] — Notes on converting SL Edit GUI values and LSL PrimitiveParams to OpenSim PrimitiveBaseShape fields
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.

==== File formats ====
* [[OpenSim Region Archive Format]] - Opensim ARchive (OAR) region archive file format.

==== Grid ====
* [[Asset Server problems]] - list of known problems with the asset server
* [[Teleports]] - some diagrams about OGP and Hypergrid teleport sequences

==== Integration ====
* [[Webinterface]] — How to mashup with the web.
* [[RemoteAdmin]] — How to use the remote admin plug-in.
* [[REST]] — Information about the REST interface to assets, inventory, etc.
* [[4D OpenSim Manager]] — Administration 4D for OpenSim v0.1 beta

==== Modules ====
* [[RegionModules]] — The various modules that are used in the RegionServer and how to write new ones.
* [[How to create a dynamic plugin]] - A tutorial for using PluginLoader
* [[Getting Started with Region Modules]] - This brief tutorial is intended to get people started with developing applications with/for opensim using region modules and the opensim API.
* [[Web Statistics Module]] - The web statistics module documentation and counter wish list.

==== Permissions ====
* [[OpenSim:Permissions(Server)]] — Permissions system as implemented on the region server.
* [[OpenSim: Permissions]] — Notes on how object permissions are handled on the client.

==== Physics ====
* [[PhysicsEngines]] — Options for physics engines in OpenSim.

==== Regions ====
* [[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.

==== Threading ====
* [[OpenSim: Threading strategy]] — How threading is implemented and handled.

==== Scripting ====
* [[Scripting_Documentation]] — How to use scripts and what limitations apply.
* [[LSL_Status/Functions|LSL Implemented]] — A list of LSL-functions that are available in OpenSim.
* [[OSSL]] — Some information about the OpenSimulator Scripting Language, and how to implement an OSSL function
* [[OpenSim.Region.ScriptEngine]] — How the ScriptEngine looks internally.

==== Search ====
* [[OpenSim.Region.DataSnapshot]] - Shiny new data gathering/search system
* [[ImageService]] - Shiny new region module for serving search-related images

==== Testing ====
* [[Automated_Testing]] — Writing Automated tests for OpenSim.
* [[Debugging Unit Tests]] — Debugging unit tests.
* [[OpenSim: Debugging - profiler dumps]] — Dumps of OpenSim profiles to aid in tracking memory leaks.
* [[Prim_Linking_Testing]] — Test cases for in world link/unlinking of prims.

==Proposals==

* [[Opensim: 0.5 Release Target Discussion]]
* [[Opensim: 0.6 Release Target Discussion]]
* [[Opensim: Future Release Discussion]]

* [[A better SimCrossing]] - A work in progress about implementing a smooth simcrossing
* [[OpenID]] - Proposal for using OpenID in OpenSim
* [[AssetServerProposal]] - Proposal for a distributed asset server
* [[SETPCICP|MXP]] - Proposal for evaluation of Metaverse eXchange Protocol as alternative OpenSim protocol.

==== Proposed projects ====

* [[OpenWiredux: Taking the next step]]
* [[Using SNMP in OpenSim]]

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

Hypergrid

2009-02-02T11:17:38Z

MW2: /* Method 2 */

==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.
#
#* 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.
'''[mono] OpenSim.exe -hypergrid=true'''

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
messaging_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
; Port 8005 reserved
messaging_server_url = http://example.com:8006

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

==== Method 1 ====

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 http_listener_port of the simulator where the region is runing you want to link to

==== Method 2 ====

There is also some initial support for reading the links from a xml file.

Use the console command: link-region <URI> [<excludeList>]

The uri can be either the path of a local xml file or a xml document on a http server.

The format of the xml file is:

<Nini>
<Section Name="Region1"> 
<Key Name="xloc" Value="1002"/>
<Key Name="yloc" Value="1006" />
<Key Name="externalPort" Value="9006" />
<Key Name="externalHostName" Value="osl2.nac.uci.edu" />
<Key Name="localName" Value="OSGrid-Gateway" />
<Key Name="real-xloc" Value="10222"/> //optional field that gives the region's real location on its home grid
<Key Name="real-yloc" Value="10265" /> //optional field that gives the region's real location on its home grid
</Section>
<Section Name="Region2">
...
</Section>
...
</Nini>

[Note] The section names can be anything you want, but they all should be different and have no spaces in the name.

ExcludeList:

The exclude list is a single string paramater with the format: excludeList:<SectionName>[;<SectionName>]

This means that while reading from the xml file any sections that are listed in the excludeList will be ignored and no HyperGrid link created for them.

This could allow, link lists to be created on a webserver that everyone could add their own regions to, and then they just make sure they add their own section name(s) to the exclude list on their own region(s).

So for example, someone might create a editable online list for the up coming OpenSimulator's 2nd birthday. Which might look something like:

<Nini>
<Section Name="OSGrid-Party"> 
<Key Name="xloc" Value="1002"/>
<Key Name="yloc" Value="1006" />
<Key Name="externalPort" Value="9006" />
<Key Name="externalHostName" Value="osl2.nac.uci.edu" />
<Key Name="localName" Value="OSGrid-Gateway" />
</Section>
<Section Name="UCIGrid-Party">
...
</Section>
</Nini>

I could then add my own region to the list with the section name "MW-Party". Then when I startup that region that I want to be part of this hypergrid, I use the command: "link-region <URI of xml file> excludeList:MW-Party"

This is so that my region doesn't try to create a hyper link to itself.

==== Method 3 (dynamic) ====

Starting in r8193, if you're in an HG-enabled region, you'll be able
to dynamically link sims, and TP there, in any one of these ways (and
probably more). All you need to know is the target adresse, e.g. from the
list below.

1) Type for example secondlife://ucigrid04.nacs.uci.edu:9007/ in the
chat box, pull up the chat history and click on that link

2) Pull up the map and search for things like
ucigrid04.nacs.uci.edu:9007

3) Using the embedded browser visit pages that have links like
secondlife://ucigrid04.nacs.uci.edu:9007/ (there's one up at
http://www.ics.uci.edu/~lopes/hypergrid/test.html)

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

Please see [[Public Hypergrid Nodes]].

== Hypergrid Lists ==
Please see [[Hypergrid Lists]].