This tool is a from start-to-finish utility for launching regions, it will automatically negotiate with your router to forward ports as required; and it will handle automatic updates of new versions using the official OSgrid.org Binary Releases. The basic release contains all the features of the default OSgrid binary release (including preconfigured Groups, Physics, Scripts, etc.). Shameless Plug: Obviously this has all the limitations of regions hosted from home – namely bandwidth & network considerations – if you want to host something permanently and reliably with support, come take a look at SimHost.

This new version of the launcher includes the following new features

• Confirmed & Tested Linux Support (and presumably OSX with Mono)
• New Zip Library (uses Ionic.Zip now) – works better on Linux.
• Completely rewritten UI – Now provides a great deal more feedback on what the tool is doing at any specific point in time.
• Ability to manually position a region optionally.
• Basic Input Validation (Bug: Glitchy on Linux – if you cant close the tool, input a few characters into the current field)
• ILMerge’d Release – now just one self-contained .exe

To use the tool, follow the following steps:

1. Drop the .exe in it’s own folder somewhere. Run it.
2. Enter a region name – must be between 1 and 64 alphanumeric characters. Some symbols & UTF8 characters are fine too. Known invalid symbols include: [ ] \r \n.
3. Select either automatic positioning (default), or enter a pair of free coordinate values. X first, followed by Y. Coordinates must be between 0 and 65,535.
4. Enter your Avatar Name on OSgrid.org – Firstname followed by Lastname.
5. Click Launch
6. At this point, the tool will download, unpack and install your region – you may be prompted to perform certain tasks manually (such as if Automatic Port Forwarding fails you may be asked to port forward manually.)
7. Once the OpenSim console appears – you should be good to go.

How to get this tool:

This is an Open Source utility released under a liberal BSD license. The latest source may be obtained via github

Source Code: http://github.com/AdamFrisby/OSGridLauncher

Release Download: http://www.adamfrisby.com/OSGL-r0.22.exe

Enjoy.

It’s important to note here – these were real clients, using SL-derived viewers. By comparison libsl is a lot friendlier on the packet engine than the full viewer, so bots tend to be a less effective test. (Plus users introduce randomness that bots cant quite emulate). Wright Plaza with 85 avatars and their attachments weighs in at a healthy 15,400 prims – so there was no shortage of texture of prim data to be sent to each client – it’s actually probably one of the nastiest sims to do load tests in – which makes it great for this. Furthermore the hardware it is located on isn’t exactly top of the line, or even middle-of-the-line.

The short news is – we’ve made some really impressive progress in the the last week. Earlier we got up to 50 – which was tweaked, tailored and adjusted to get us to where 100 or even 150 isn’t really that out of the question anymore. There’s three big causes for this – first, abandoning OpenJpeg for decoding J2K textures made some very noticable improvements to stability (it’s in progress to abandon it for Encoding too); this means we’re not crashing on the way up – which means we can hit higher concurrencies more reliably. Second – John Hurliman from Intel rewrote our throttle routines and some low-level packeting code, which delivered a big boost to packet performance. Third – multiple efforts to reduce memory use in key places, has at least halved operating memory requirements – at 85 concurrent, memory was peaking at a mere 1.7gb (~20mb/user).

A result of these improvements has been memory IO is no longer such a major bottleneck – we’re actually beggining to hit the point where CPU usage is nearly becoming a more important bottleneck (we were hitting 90% CPU at peak — although the physics interpenetration mentioned above might be distorting this, since it could lead to run-away CPU use) – which is a refreshing change, since it is a lot easier to optimise around, and the tools for CPU use profiling are a lot better than those for memory IO profiling – and produce a lot more meaningful information.

We’d like to continue these load tests – the information the devs have gotten in the last week has been absolutely invaluable. Having a big pool of testers able to jump in on a moments notice has resulted in getting performance fixes tested and integrated a lot faster than usual – it’s also helped stability, each crash has been diagnosed and debugged in series as it is encountered. It’d be very easy to say that performance & stability wise, more has happened in the last week than the last 6 months – and we still need your help to keep going. We’re going to be continuing these load tests next week – there will probably be another major effort at getting 100+ avatars in a sim next Friday (same time, 1PM PST). If you want to know when the next test is planned, and help out – either hang around in #opensim on Freenode, or follow @osgrid or @adamfrisby where I’ll announce them they come.

Next stop, 150.

One racetrack, a little over 4 square kilometers of space (or 4,194,304sqm). This is my first attempt to build something with a bit of scale to it, now that we’ve got mega-regions working in OpenSim. (and vehicles.)

To start with, I need a terrain large enough to encompass the entire area (there’s no way in hell I’m manually terraforming this one) – courtesy of DeepThink, I have a license to World Machine Professional, a commercial terrain editing package that absolutely kicks ass. World Machine builds terrains in a semi-layered manner, then allows you to combine those through a railroad-style filter scheme.

Grabbing one of the World Machine samples as a base (since it had road layers already setup), I modified them and redrew the paths to build a 16×4 sim (4096×1024) terrain and rendered it. You can see the output in World Machine below, of course from this scale it doesn’t really do it justice.

Travelling at 55.5m/sec (200kph, 124mph) – you will cross into another region-sized space every 5 seconds; but the total racetrack length means that even at this speed it will take over a minute to complete, encompassing a minimum of 16 region-sized areas, which in turn is only a small subset of the entire space availible. Taking a picture of the terrain loaded into the mega region, you can see just how insignificant an avatar is at this scale.

This is compounded by the fact that the viewer refuses to put it’s “farclip” beyond about 4 sims distance, so at best you can see 1/4 of the track at once. The ringworld walls are each about 150m tall at this scale; and geographical features are quite recognisable as geographical features.

Of course, we can’t just leave it at that – to quote Mythbusters, “if it is worth doing, it is worth overdoing”, so I pulled up the terrain in world machine again, and decided to go a little bigger. I originally made it at 48×4 sims, however had to crop back to 32×4 due to my machine needing more memory to do the resulting 12,288 x 1024 terrain without swapping on disk constantly (resulting in a multi-hour render). For scale reference, the smaller of the two circles is about the dimensions of a single normal region.

Part 2 will cover texturing and detailing this race track, followed by some first impressions of how it behaves with Kitto’s new vehicle patches. Once I’m done with it, it will go up live on the Hypergrid (and probably OSgrid) for public perusal.

Kitto Flora deserves some major kudos for recent developments with OpenSim vehicles. Not only do they work, but the revised car script I toyed with earlier today – was actually quite usable; and dare I say it? good. All of this is thanks to Kitto’s work refining and improving the vehicle functions and how they interrelate with the internal ODE physics engine.

I could speculate here, and say if you were a decent vehicle coder – you could probably do some amazing things with OpenSim these days. So what happens if you combine these new vehicles, with Teravus’s recent mega regions code, and my sculpty terrain code (with mods from nebadon)? This. (Recommend jumping to about 4:40)

(Edit: Added a new link to the video – 22/09/09)

I probably do not need to go into too much detail here – the above is a 3_x3 megaregion, using 576 physical sculpts, Kitto’s latest ODE mods & vehicle script – running on a home users cable connection; with several people driving around at once. Not only does it work – it suprisingly works well. I expect a more skilled texture artist could pull some amazing things off with the sculpty terrain code – the terrain is just a quick output from L3DT done by Nebadon.

The vehicle code isnt in trunk quite yet – but if you ask around in #osgrid, I’m sure someone can point you to the github account where you can get the ODE patches. I’m sure much like mega-regions, it will be in trunk soon enough.

Credits: Kitto Flora (vehicles), Teravus (megaregions), Nebadon (video, hosting, testing, sculpty terrain), Bri Hasp & Hiro Protagonist (hosting & testing), Myself (sculpty terrain generator).

We’ve just launched our brand-new OpenSim & realXtend hosting service – at what we think are pretty decent rates. $49.95/mo gets you 1024MB of dedicated memory plus a dedicated processor core, including fully managed OpenSim support. James Stallings (a veteran OpenSim sys-admin and grid operator for OSgrid) is managing the operations side and providing full-time dedicated support for SimHost.

So what’s that price get you?

• Fully Managed Support (we’ll deal with sim crashes, and keeping your simulator alive.)
• Regular Updates of the official OpenSim Software (we know you like the latest shinies – so we can provide them)
• Good Quality Hardware – 1GB of dedicated memory + 1 Processor Core is our ‘minimum’.
• Warm fuzzy feeling that money you pay is going to feeding OpenSim developers (our profits are being reinvested in the platform)
• Grid Agnostic Connections – Run your own grid (Standalone), Connect to OSGrid or any other public grid. It’s your choice. We wont force you into our own private grid.

For a little bit extra per month, we have a premium plan that includes 4 regions, the option to use modular realxtend (modrex — not compatible with some other features, just ask us.) and the option for us to run versions that aren’t quite properly tested yet (they require more support on our behalf, hence the higher rate.) – such as megaregions and other more experimental features (we’ll need to talk with you about risks first though.)

If you input the promocode “ADAMFRISBY” (no quotes) you will get a bonus $5.00/mo off the pricing too. (So you can get our standard package for only $44.95/mo).

Web: www.simhost.com
Live & Ticketed Support: www.simhost.com/support

If you have any questions – feel free to contact support and they will be happy to answer them.

OpenSimulator is experimental software. If it breaks, you get to keep both pieces.

OSGrid “map tiles” are only reserved for you while your region is online, if your region is offline it risks having it’s location taken by another user. OSGrid Admins may help resolve map position disputes, however it is not our responsibility to keep your location.

- OSGrid.org “How to Connect a Region”

Connecting a region to OSGrid is a rewarding experience – many users however run into the difficulty of instructions being out of date; and while this set too will eventually go stale – they should at least be current for the next few months. Before getting started – you need to decide on a few things; information about your region (what to call it, where to put it on the map), where you will host it (at home, or on a dedicated server)

OSGrid is a free OpenSimulator network – connecting a region and using the central services is done free without charge (however donations to keep the infrastructure running are appreciated.)

First – this guide assumes Windows, and also assumes you are hosting from home. Users running in more professional setups will need to adapt accordingly. You may be able to skip a large portion of this setup procedure, by using the automated ‘OSGrid Region Launcher’ utility, you can download a copy of this experimental tool from the OSGrid Website; however this has not been confirmed to work with all users (nonetheless, I recommend it as a first step).

Preparing your region

Before we undergo the region setup process, you need to know your internet facing IP address, have setup appropriate port forwards. OpenSimulator by default will use Port 9000 on TCP and UDP; if you are behind a router you need to forward these ports to the machine that will be running the simulator instance. If you don’t know how to do this – see experimental tool listed above; or consult instructions for your router. You will also need to configure your router to enable ‘NAT Loopback’ – some support this by default, some don’t. If yours doesn’t, you may be out of luck and will need to host somewhere else (see my article on that topic).

You will need to gather two bits of information about your hosting environment, first is your internet-facing IP address – if you do not know it, visit this page. The second is some spare coordinates on the OSGrid World Map. If you don’t know them (or dont care to work some out), you can use this page here. Record both of these bits of information, because you will need them in a moment.

Download a copy of the OSGrid Package. It’s usually about 40mb, and can be currently found at this address: http://www.osgrid.org/elgg/pg/utilities/software

Unzip this package; and look for ‘OpenSim.32BitLaunch.exe’ – ignore the other files within the directory (regardless of whether you have a 64bit or 32bit system) – right click on it, and hit ‘Run As Administrator’; text will scroll by for a little while, then you will be asked a series of questions, in the format “Question Name [default]: _” – the following is how to answer these questions.

Questions

• New Region Name []:
  This is the name of the region that you want, it should be less than 64 characters long – and cannot conflict with any existing registered region.
• Region UUID[random]:
  You can ignore this, just hit enter.
• Region Location [1000,1000]:
  Enter here the region coordinates you wrote down above – exactly as printed in the ‘autocoord’ web page – that is, two numbers with a comma between them and no spaces. (The first number is the X coordinate, second the Y)
• Internal IP address [0.0.0.0]:
  Hit enter here – 0.0.0.0 means use ‘any availible IP’; this should be your choice unless you know better.
• Internal Port [9000]:
  This should be 9000, hit enter to use the default.
• Allow alternate ports [False]:
  If you are using port forwarding, leave this setting as ‘False’ and just hit enter.
• External Host Name [SYSTEMIP]:
  For this setting you need to put in your internet-facing IP address (or DNS address); you can use the exact output of the page listed above.
• Master Avatar UUID
  Skip this setting – just press enter.
• Master Avatar First Name
  Enter the first name of your avatar name here – my Avatar Name is “Adam Frisby”, so here I would enter “Adam” (no quotes)
• Master Avatar Last Name
  Enter the lastname of your avatar – eg; “Frisby” (again, without quotes)

With a bit of luck, your region should have registered with the grid and is now accessible. Login to the grid, and try teleport to your region via the world map. If it connected successfully; then that is all you need to do – your region is now online.

Chances are however, something went wrong.

Troubleshooting

The following are the common sources of problems when hosting a region from home

• “Remote Destination Timed Out”, or “Remote Destination is not responding”
  This error means that your port forwarding was not done correctly; and that the grid services were not able to connect to your region on the TCP port. Double check your port forwarding, and that your external hostname is correct.
• “Could not connect to region“, or “(done)“, or “Despite our best efforts, something has gone wrong“.
  This is a more insidious error, it means the grid was able to contact your region server on the TCP port, however the client was unable to contact your region server – double check your port forwarding and check that you have NAT Loopback enabled. If it still gives you problems; your router is incompatible with OpenSim – you may want to read this article on the opensim wiki for additional pointers.

To those developing copying tools, we urge the simultaneous development of standard industry practices that protect against intellectual property infringement. For example, consider the following standard practices for tools copying content from Second Life:

1. Check that the user of the tool is the Second Life “creator” of the content;
2. Do not facilitate the export of an entire Second Life inventory; and
3. Preserve the Second Life “creator” name and information that the content was originally created in the Second Life virtual world.

To summarise in other words, “You may only export content you created, and only if you label them as something you created in Second Life first, with your second life avatar name; and you cannot back up your whole inventory at once – you must do so piecemeal.” – every single one of these restrictions eliminates a large swathe of legitimate users and uses. Let’s go into them in detail.

Check that the user of the tool is the Second Life “creator” of the content

You have now eliminated all the content that is explicitly marked as compatible off-grid; everything licensed under creative commons or Open Source licenses, everything in the public domain. While I concur with ‘Full Permission != Permission to Export’; there is no way right now of programmatically indicating whether you want to allow content to be exported — however there are ways of legally indicating it, such as license files, README notecards, et al.

While Full Permissions are not an ideal situation – the overlap between content allowed off-grid, and full permission freebies is significant enough that a full permission check is a acceptable compromise. I personally would say ‘Full Permission OR Creator’; as both indicate a high level of permissiveness with the content itself (and the creator should always be able to export their own content). It is worth noting that Second Inventory (the popular backup tool) has been using ‘Full Permission’ as its own metric for over a year now; with I believe mostly acceptable results (it is not used as an infringement tool – the infringement part is always done by a illegitimate tool first).

Do not facilitate the export of an entire Second Life inventory

Hello.

The only possible reasoning for this I imagine is simply to prevent competition – by allowing full inventory export; you make it easy to translate content you developed from Second Life, to the numerous third party grids. If someone high profile wants to leave for one of these, these tools definetely help streamline the process. With 50,000+ downloads of the OpenSimulator software since December – I suspect there is an alterior motive for this ’standard’ that is not related at all to helping content creators; infact I cannot see a reason at all where this helps Content Creators.

The unintentional targets of this are now people who perform inventory backups – the Second Life Inventory server is about 99.99% reliable – which means 1 in 10,000 users can expect to lose their whole inventory, and 1 in 10,000 items will mysteriously vanish over the course of a year. There are reasons why Second Inventory market themselves as a backup tool for the unreliable asset & inventory services – and it is distinctly related to deficiencies in the platform itself.

As far as I can tell, this rule makes backups harder – which hurts content creators, because legitimate backup tools are now out of the question. It’s also saying something about the supposed ‘You own your IP’ line Linden Lab has been stating for the last 7 years. If we own our IP, how can you state what we can do with it?

which brings us to…

Preserve the Second Life “creator” name and information that the content was originally created in the Second Life virtual world.

Many probably want to be able to do this optionally; but it is not a mandatory feature. Mandating this indicates that you do not have control over your IP – because Linden Lab is going to demand attribution to Second Life. We at DeepThink developed a whole bunch of content over the last 2 years for use in both Second Life and OpenSim – I dont want that attributed to our content creation account, I want that attributed to:

DeepThink Pty Ltd. <www.deepthinklabs.com> – Copyright©2008, See attached license for licensing information

and not…

Adam Zaius – Second Life

Forcing the latter is stupid, and less effective than the former. The latter does not hold any form of copyright, it does not imply any license – and it does not imply any contact information for the creator or copyright holding entity [especially if they leave SL]. The tools should include the capability to add attribution metadata, and maybe they can default to showing a Second Life name (eg ‘Adam Zaius inSL’) – but ultimately, *I* want freeform legal attribution – which carries a lot more weight in the real world, where copyright matters.

This personally reeks of an disingenous alterior motive – particularly the last bit (Created in SL) – I’m very skeptical that Linden Lab would be able to legally enforce this; Textures and other assets have no ‘creative’ input by Linden Lab. The procedural primitive modelling may have some effect, but since a process is not legally creative – I dont believe the procedural algorithms themselves contribute creatively to the final work significantly enough to give Linden Lab joint copyright — although a legal experts opinion is definetely required here.

Ultimately, I think this is a counterproductive effort.

While I think this came from a earnest and honest discussion internally at Linden Lab – I dont believe it has any real world capacity to solve any real problems. Second Life needs a permission system that is capable of indicating an export permission. It should be clearly marked ‘Allow Export’; and be tied hand-in-hand with full permissions (so you can only check ‘Allow Export’ on existing full permission content — this way people are under no pretenses)

It’s not an ideal solution to the permission model’s deficiencies – but it would be a much better start than the three listed above. Since permissions are implemented as a 32-bit bitflags on the backend, and 28 bits are currently unused, implementing this would require no significant database or architectural modifications to Linden Lab’s backend (if anything it is just a viewer modification.) – it would be a very simple modification to make.

As a administrator on the most popular alternate grid – I dont want content on the grid that doesn’t belong. Infact we do spend a great deal of time making sure that our freebie locations and newbie content is all legitimately licensed (tell us if you find something that isn’t!), and the original creator intended the content to be there; anything that simplifies that process has my wholehearted approval.

Illegitimate content is not just irritating to deal with, it is also a legal minefield – we do have a DMCA process for OSGrid, and we’ve got some pretty sophisticated ways of removing every instance of an asset off the core servers, but it is a painful and annoying process. DMCA takedowns require certain legal procedures to be followed to the letter – which makes things a liability if they are done wrong; and there are significant extra considerations for non-US residents and servers.

Speaking with four hats on – that of a Grid Admin, Software Developer, Copyright Holder and Consumer – my firm response to this proposal is ‘go back, and try again.’ – because it’s not satisfying the requirements; and won’t do squat to solve the problem of content piracy; infact it will likely have the opposite effect where legitimate tools are handcuffed, and users favour of ones of illegitimate design.

There are good solutions to this problem, and I’ve got a proposal of my own in the works (one that I have been working on for a number of weeks already) – but these ‘Standards and Practices’ are complete hogwash; and degrate creator rights by imposing restrictions on what creators can do with their own content.

Let’s start with the basics – the asset server is a gigantic document storage server. In our cases, documents are things such as primitives, textures, sounds, avatars – the works.

Each document is referred to by a specific unique filename called a UUID – which is a 128-bit number (think 3 with 38 zeros behind it – big number) – a UUID looks something like this “d61c1990-79b9-11de-8a39-0800200c9a66″ when represented in hexadecimal notation. You have probably seen them around a lot – just using OpenSim or Second Life.

A UUID is an excellent choice for a filename; because you can make them up randomly and statistically guaruntee it hasnt been used before (the chance of a UUID duplicate for a good random UUID is about 1 in a very very very very large number). This means you can have multiple asset servers on the one grid – each upload can be given an ID randomly, without the need for a central authority to give them out.

They also optimize extremely well – each “bit” is a single yes or no question; to find out exactly where an asset is located, you can play a game of 20 questions, but in this case, with 128 bits – you can ask 128 questions. For example; finding which server an asset is located on, in a server farm with 4 machines (labelled 1,2,3 & 4) could be found with the following question chain…

1. Is the asset on a server labelled closer to 4 than 1? (yes – servers 3,4 still possibilities)
2. Is the asset on an odd numbered server? (yes – located on server 3)

Asset found on server #3. It’s not very long is it? Even with say 300 servers; you can find the answer within 9 questions. Some further searching is needed to be done to locate the asset on the physical disk itself; but even then you will be asking a very small number of questions – far less than the maximum 128 allowed.

To put this into a diagram, fetching an asset directly by it’s indexed UUID is equivilent to something like this:

Fig 1. How asset UUIDs divide and conquer

Given that computers are capable of asking and answering questions very very quickly (several billion per second); and that none of the above questions require a central server; you can expand your asset server farm in a fairly linear fashion without scaling constraints; providing that you structure your data appropriately.

128 questions also means that you can define very very precise questions; so many that if you created 100 trillion assets every second; the sun would be lifeless before you ran out of address space that can be answered by that many questions. (Although a piece of statistical mathematics called the Birthday Paradox does make the address space significantly less usable the closer you get to that point – but for other reasons)

At this point, we know how assets are stored and retrieved – files are uploaded into the server farm, and given a UUID; that UUID can be used to find out where the asset is located precisely, and return the data later. However, when you access an item off the asset server; there’s only a modest chance you are accessing the asset by it’s UUID directly.

A lot of the time, you will be accessing the asset through a layer of redirection called the Inventory Server – if you have a texture within your inventory; there are actually two components; the first component is the data itself (the asset), and the second component is the inventory shell (uploader, time uploaded, permissions, reference to the asset, etc). When you lose an item of inventory (such as during a transaction); it is often not the asset servers fault, but instead the inventory server.

The inventory server exists so that if you give a copy of a texture to a friend; you and that friend do not make a duplicate copy of the heavier portion (the asset) – both inventory items, yours and your friends will have the same underlying asset ID. This also means that copying an item within your inventory will not prevent it from being saved during a asset glitch (as both point at the same data).

In Second Life®, the inventory server is using MySQL (and probably InnoDB), and the asset server uses IsilonFS (a custom hardware appliance based system.); in OpenSim this will vary a lot depending on the providers configuration – most grids use a SQL backend for storing both assets and inventory. By default, OpenSim will use a small embedded database for both Inventory and Assets – called SQLite. For grids, we recommend something more robust.

In grid mode, MySQL is still an appropriate solution for Inventory; however asset data will often exceed the normal operating tolerances of MySQL and lead to frequent table corruption, table locking issues (which in turn make performance suck) and other nasties. No large grid should be using MySQL for assets (small home and private grids are however fine.)

Grids such as ReactionGrid which use MS-SQL can get a bit further than MySQL when storing asset data (for inventory they are fundementally the same); MS-SQL like most sane database engines, store BLOB data seperately in a BSP-Tree indexed system; this means they can scale up pretty far (although at about the point of clustering, things degrade.); Postgres can do the same – however as best I am aware, Postgres is not yet properly supported in OpenSim.

For bigger grids like OSGrid (where we have hundreds of gigabytes of assets) a dedicated solution is ideal – unlike Second Life, we cant afford to purchase high end NAS-equipment for our storage solutions; so we have built a distributed system called Fragstore which has two big features.

1. A configurable backend – it can use distributed storage systems (such as Project Voldemort or Hadoop), or export to a filesystem (which can be a distributed filesystem via projects like KosmosFS.)
2. A duplicate detection system – so files uploaded twice only get stored once.

The duplicate detection is achieved via a secondary layer of indirection; when we allocate a UUID, we hash the incoming data (256-bit SHA1) and store the UUID and the Hash into a small database table (currently MySQL based); when we recieve future uploads; if the hash matches, the result is only stored once on disk.

The final point I would like to touch on is asset transmission and security – assets are transmitted in both SL and OpenSim over HTTP; the reason this works and is secure is because the UUIDs used in the requests are unguessable. Even by a computer making millions of guesses per second; the chance of hitting a valid address is very very small (same probability as generating a duplicate UUID).

From the asset server to the region server, the request is something in the form of http://assetserver.com/<uuid>/data – which will return the asset in a encoded container (usually packaging a little bit more information about the asset such as the content type, etc.) – using /metadata instead of /data will get you a JSON-encoded package with a bit more information about the asset (creation date, specific asset type, etc.)

From the region servers to the users – this transmission can vary a little. In both SL and OpenSim, the region servers act as proxy caches for the asset server; because assets cannot be updated (and instead are replaced) – this works fairly well. If twenty users in a region see a texture – it only needs to be fetched off the core asset service once; because the region will send it twenty times to the users; rather than twenty users hitting the core server.

In the case of OSGrid, this means we have 2,500+ reverse proxies sitting infront of the asset server (albeit in a somewhat suboptimal layout.); it reduces the bandwidth on the core asset server by approximately 90%+ (you can see our asset stats here); which means we can get away with much lower operating costs (since asset delivery costs are shared with region operators).

We’ve been experimenting with Vivox, so the entire presentation was streamed via the new VivoxVoiceModule; running on the latest trunk code for OpenSimulator; both for the most part performed pretty admirably. A lot of the improvements from IBM and Intel lately into OpenSim’s packeting have been paying dividends. Mono’s previous concurrency “record” was about 40 users (for comparison .NET’s current record is 65).

So, what’s in store in the future and near-future for OSGrid? I had a couple of announcements at the opening presentation.

First – Hello General Store

The general store is the first “webshop” based on OpenSim that integrates directly into the grid itself. Listing of items, setting of permissions, etc are all done from within the viewer – directly integrated with your inventory itself.

This has one major advantage outside of the improved convenience – it means you do not need a region to mediate the transaction. Every transaction can be done directly on the inventory server (infact this is exactly what we do.); but what does this exactly mean?

When you create your general store – a special undeletable folder is created in your inventory called ‘My General Store’, items placed into this folder that are marked ‘Allow anyone to copy’ are listed on our website automatically, providing you are the creator of the item in question (and have copy/trans permissions on it).

Purchasing of items will have them sent to your inventory directly via the inventory server (although you will need to relog after a shopping trip for the items to appear.); saves a bit of time and effort doing the transfers – and you dont lose a transfer because you were in busy mode.

User Achievements

Many of you spotted our new achievements system located on the OSGrid website – it’s mostly a bit of fun right now (and probably will always be), but we are going to be opening achievements up to region operators across the grid. If you have something open to the pubic (some form of competition, game or other activity that is ‘achievement-worthy’) you can offer achievements as rewards.

The exact process is yet to be exactly finalised – but you will recieve a bit of LSL at the end you can include which allows you to award your achievements to specified users. There will be some caps on who is eligable to be able to award achievements (particularly so that people do not just set them up for friends)

“More information soon”

Acknowledgement of Direction

OSGrid has traditionally been a test grid for OpenSimulator – that has been good and bad – in our case however, we’ve definetely moved on from those roots – OSGrid today is now more of a social space than a testing one. As a group, the admin team has decided to acknowledge this as part of OSGrid’s long term direction – and include those aspects in our mission statement (while preserving our current roles too).

While the testing aspects will always be present, we’re going to be focusing on making the social aspects more useful; such as improving our events calendars and website integration features. We would definetely like to see more live events – and will help promote any regular events to our wider communities.

Some of these changes will be more profound, which is actually tied to…

Continents

We are going to be introducing two new continents into the OSGrid ecosystem; so there will be three major continents in total. For lack of a name so far, they will be ‘Terra Alphus’, ‘Terra Betus’ and ‘Terra Gammus’ (subject to change). The current continent centered around 10,000×10,000 is ‘Betus’; and will not be changing.

Alphus will be the most structured of the continents – and subdivided into three zones based on the server geography – US, Europe and Asia. Regions connected to Alphus need to be approved by a small committee, and subject themselves to a few construction limits. Alphus will:

• Consist only of regions on dedicated server hosts (or good quality VPSs)
• Have a reasonable uptime (that is they are significantly likely to be online)
• Follow a master terraforming pattern.

Regions in Alphus will be organised so that servers located in the US are grouped with other US servers; EU with EU and Asia with Asia — meaning border crossing between Alphus regions is a lot more likely to be successful. The goals with the Alphus area is to ensure a more consistent user experience [especially for new users] and can be thought of as a ‘grid within a grid’ of sorts.

Betus is the current continent – it’s not going to be touched (other than perhaps by a few regions moving into Alphus); the current strategy of nearly-anything-goes is not changing here. You can place your own regions in this section without any considerations at all.

Gammus is the final section, and also a new continent – this will be tied to our new highly experimental region launcher. Regions hosted from home using our launcher will end up here. Because these regions are less likely to be online at any given moment, we are conglomerating them together away from other regions – so that the other regions on the grid are not affected by constant neighbour checks.

In summation:

• Your current regions arent changing or moving. If you want to setup a new region on any random coordinates, that’s fine too.
• The new continents will be fairly close to each other in coordinate terms (within 500 coordinates; or within reasonable scroll distance)
• The goals of the introduction of the two other continents are to improve user experience (especially with border crossing, etc.)
• This is not a grading system; Alphus regions are not better than Gammus – only that Alphus voluntarily comply with a tighter set of user experience restrictions.

New Orientation Sims

We’re going to be working on some new orientation island sims with OSGrid; particularly to aquaint people with what OSGrid is and isnt. These are going to be seperate from our welcome area (LBSA), but we are going to look at ways we can integrate them together (such as providing a chat bridge with a helpers group, etc.)

Again, more information coming soon.

If you haven’t popped your head over onto OSGrid in a while, you might want to take another look. We’ve made some reasonably big improvements in recent weeks; above pictured is part of the new LBSA Plaza (welcome area); but the real improvements have been in our website.

I mentioned previously the development of Elgg integration on OSGrid – we put that into production just over a month ago, and have since spent quite some time refining the integration. Initially when we deployed, there were a couple of deficiencies in features over the old website – we’ve quickly gone past there, and the new website integrates a whole bunch of shiny new features.

Many of these features are or will be linked to popular places inworld – such as the website event calendar being visible on billboards inworld (using PHP+GD+osSetDynamicTextureURL). We’re working on doing some of the reverse too (such as each region getting it’s own “Page” automatically — similar to how each avatar has it’s own profile page.)

OSGrid itself has grown pretty dramatically in this period too – it grew on almost every metric by a full 25% in the last 4 weeks. Regions, users, active users – all shot up. Infact, using the stats on the OpenSimulator.org grid list (skipping grids with missing data) – OSGrid now represents between 48 and 56% of OpenSimulator grid users; it’s by far the largest and busiest OpenSim grid. OSGrid currently has about 2,100 active regions (by comparison, the Second Life mainland is approximately 5,000 regions)

Some of the other improvements we’ve added was a new achievements system (pictured above), which we will be expanding to encourage exploration and participation in OSGrid events. We’ll be rewarding people with ‘achievements’ for various things such as participating in official (and some unofficial) events, exploring, building and more.

Which brings me to OSGrid itself – it’s nearly turning 2. On the 22nd of this month, we’re going to be celebrating our second birthday. We’re still sorting out what exactly the celebrations will be – but you can find them on OSGrid’s Event Calendar closer to the 22nd.

So if you haven’t already – come register an avatar and take a peek.

[Apologies to readers for the lack of updates in the last 3 weeks - I've been buried in work, I'll be posting June's commits wrapup in the next few days -Adam]