This is modelled somewhat after the same guide for wordpress. Running an OpenSimulator instance is a challenging prospect for many - there are a number of important criteria you should be looking at before purchasing, but the single most important question is “Will I be managing this myself?”.

“Do it yourself”

DIY Hosting OpenSim while relatively easy by comparison to most hosting software, is still not something that should be done by the technically uninitiated. OpenSim requires a healthy amount of maintainence in the form of updates, backups and patching.

Virtual or Dedicated?

For DIY hosting you have two choices in terms of hosting - Virtual Private Servers (VPS) or Dedicated Servers. Virtual Servers are a percentage of a physical server provided inside of a virtual machine. Virtual servers are often significantly cheaper than a dedicated server, however come at a heavy cost in performance.

Virtual server pricing starts at approximately US$15.00 per month. Dedicated servers will start at approximately US$50.00 per month. Virtual servers are appropriate for low performance private sandboxes, Dedicated servers are a must for public or regular usage.

A final note on dedicated servers - the most inexpensive dedicated server will often outperform the most expensive VPS. If you are on the price border between the two, I recommend switching to the lower performance, but dedicated server - than the higher performance but shared VPS.

Linux or Windows?

Unless you have significant investments in using Linux for your hosting, I recommend using Windows 2003 or 2008, especially if you are not familiar with running hosting environments. The reasons for this are fairly simple - Mono has memory management problems, memory requirements under Mono are often doubled or quadrupled.

Unfortunately Windows server is not always availible - especially at the lower price ranges. Microsoft charges hosting companies a $10/month per cpu fee for Windows Server, so this will always be passed on in the form of higher prices. In the highly competitive VPS industry this price increase makes good Windows VPSs a rare niche.

What processor?

OpenSim will very rarely peg your processor - I would not bother investing too much into the processing capacity of your instance or server. (Whether a VPS or Dedicated machine).

My own experience says that “off the shelf” desktop processors are more than adequate. Here at DeepThink we have standardised on Xeon 3220 based machines (Quad Core, 2.4Ghz) and we find these are more than suitable for our higher-end clients. For an average user, a off-the-shelf Core2Duo is more than sufficient.

How much memory?

This is a much more relevant question for OpenSim. If you are running on Mono, I recommend no less than 1GB of memory per region (512MB if it is mostly empty). If you are running Windows/.NET you can use a rule of thumb at approximately 384 to 512mb per region.

A more precise metric is to total up the following: A base cost of 200mb, total size of all textures in the region + 30% in megabytes (average region is around 50mb), 30mb per 1,000 primitives, 50mb per concurrent user and double the sum if you are running under Mono.

So a region with 5,000 primitives, an average number of textures (50mb) and ten concurrent users you should allocate approximately 900MB of memory for .NET and 1.8GB for Mono. Leave at least 100mb on top of this sum for the operating system itself; if the machine runs out of memory page file access will cripple the performance of your region.

Memory should be as fast as possible - the faster you can get the better.

How much hard disk?

None. OpenSim rarely uses more than a few gigabytes of space unless you are operating a large grid (OSGrid.org is only about 120GB of assets currently). Anything over 10GB is sufficient.

How much bandwidth?

This is a slightly tougher question to answer - it depends a lot on your sim, the complexity and texture detail, the number of visitors. We at DeepThink sponsor the servers running the OSGrid.org Plaza’s, which I believe are the six most visited OpenSim instances running. The Plazas are broken up over two physical machines - each uses about 240GB of bandwidth each month - or approximately 80GB per region per month.

In pratice your region should come in significantly under this - but I recommend making sure you have at least 100GB of traffic per region in the event that you create a popular space. Most hosts provide at least 1TB of transfer on dedicated servers, so this should in most cases be a non-concern.

The other side of bandwidth is connectivity - how fast your server can speak with the outside world. I recommend having at least 200kbit per concurrent user. So for a standard ‘10 concurrent’ situation, you should have at least 2mbit of connectivity.

Backup Space

Make sure to have some kind of external backup system - most hosting providers will sell you SFTP access to a backup server, however make sure that they in turn provide good backup policies on your backups (offsite backup, etc.). OpenSim can be very fickle software, so make sure you have a good backup routine setup.

Latency

If you are a non-american user or cater to a foreign crowd, Latency is a very important issue. Latency is the “lag” between when you do an action and when it occurs on the simulation server - unfortunately latency is often best fixed by changing the geographical location of your servers.

If you cater to an audience in a specific country - I would recommend searching for servers in countries nearby. Often localised hosting is several times more expensive than in the US due to higher prices for local bandwidth, however most of the time there is a cheaper alternative nearby. For example, Japan has very high local server costs - but Korean or Singaporean servers are cheaper and have similar latency characteristics.

Who?

Dedicated Servers

CariNet (San Diego, CA, USA)

CariNet have been a popular choice for people running regions on OSGrid thanks to great pricing and astonishgly quick setup times. Their live support is pretty good and tends to fix most issues within 30 minutes of reporting. Cari have a highly flexible pricing system - so make sure to remember to include additional RAM and the Windows operating system with your purchases.

CariNet are also an official sponsor of OSGrid.org, providing regular free upgrades to the official servers that are hosted there (Currently the two plaza machines and the one welcome machine). They have also provided some special pricing for OpenSim users - see the italics below.

Pricing: Minimum $50.00 per month (special offer at time of writing).

I spoke with CariNet’s sales department, and we have worked out a few “OpenSim Optimized” configurations -

• High Performance - Windows, 4 Core Xeon, 4GB configuration is US$200.00/mo with no setup fee.
  This configuration is ideal for a “SL-replacement” style region host, you could probably get a couple of regions off this hardware, but the exact number will vary as above. I would estimate approximately 2 “Full Regions” could be run on this hardware configuration.
  If you want this server for only $160/month (but with a $120 setup), contact Cari.net sales via their Live Chat with the discount code “OSGRID”. (Speak with Mike or Shawn)
• Mid-Range - Windows, Core2Duo, 2GB configuration is US$140/mo with no setup fee.
  Expect to get one heavy region out of this configuration (or quite a few “homestead-esque” regions) - as always, this varies based on consumption.
  As above, if you want this server for only $120/month (but with a $60 setup), contact Cari.net sales via their Live Chat with the discount code “OSGRID”. (Speak with Mike or Shawn)
• Low-End - Windows, Celeron 2 Core, 2GB configuration is US$125/mo with no setup fee
  Consider this a homestead replacement, you should be able to get a small number of “homestead-equivilents” running off of this - obviously you dont have primitive limits or things like that, but you will notice degrading performance if you rely on a lot of scripted functionality.
  As above, if you want this server for only $105/month (but with a $60 setup), contact Cari.net sales via their Live Chat with the discount code “OSGRID”. (Speak with Mike or Shawn)

Annual and quarterly discounts are availible for paying more than one month at a time.

Website: http://www.cari.net/

OVH (Paris, France, EU)

OVH are the largest dedicated server host in Europe and provide unbeatable pricing on European servers. English pricing is expensive, however the same servers ordered from their French or German language sites are 10-20% cheaper.

OVH provide large amounts of memory and disk space by default, so very little customisation is required on their default servers. Windows 2003/2008 is an additional EUR 15.00 per month. Their RPS low-end machines may be a suitable mid-way point between a VPS and a full machine, but I haven’t tested one myself.

Pricing: Minimum EUR 49.95 per month. An OpenSim optimized configuration will start at EUR 114.00 per month (fully equipped).

Website: http://www.ovh.co.uk

Virtual Servers

Tektonic (Dallas, TX, USA)

Highly recommended by one of our employees, Tektonic provide good quality Linux VPS solutions - while they only offer Linux based VPS instances, their pricing is affordable and do not appear to oversell their servers in any noticable capacity.

Pricing: Minimum $15.00 per month. A “workshop” quality VPS is US$28.00 per month.

Website: http://www.tektonic.net

Slicehost (St Louis, MO, USA)

Slicehost guaruntee a minimum level of performance on their virtual servers which makes them more expensive than other hosts, however have a solid customer service reputation and a high quality control panel.

Pricing: Minimum $20.00 per month. A “workshop” quality VPS is US$38.00 per month.

Website: http://www.slicehost.com

FsckVPS (Atlanta, LA or Texas)

FsckVPS is often recommend on the OSGrid forums as a potential host - their slices are of a reasonable configuration and have plenty of memory availible. Processing time is more limited and some users have complained about running into processor limits, so their higher end packages are recommended.

Pricing: Minimum $9.95 per month. A “workshop” quality VPS is $19.90 per month, however I recommend the $34.90 plan if you plan on concurrent users.

UPDATE 9 June 2009: These guys dropped the ball badly on an exploit, while it does look like their upstream provider gets the lions share of the blame, they had an unacceptable amount of data loss that could have been avoided by doing some simple backup precautions when an exploit becomes known.

Website: http://www.fsckvps.com

“Someone host it for me”

As an alternative to setting up and managing your own OpenSim instance, you can pay for someone else to manage it for you. Often this is simply bundled with a grid - however a number of companies (including DeepThink) offer managed hosting services for OpenSim.

On average, an OpenSim instance will take around four hours of maintanence each month - at an average industry salary this is around $80.00 per month to the hosting company in engineering costs. You should expect the margin per-server to be about this size.

OpenSim hosting companies will charge based on one of two methods - the first method is Second Life(r) style limits - Primitive, Avatar and Script limitations. The companies that charge this way are generally those providing regions within a grid.

The second method is charging for the underlying service used - Processor time, RAM usage and Bandwidth. The companies offering this tend to be fairly agnostic as to where your regions will connect.

An important distinction between the two methods is that you will often get more ‘bang for buck’ on the underlying capacity. For instance if you need multiple low performance regions - you will come out significantly ahead by purchasing server time rather than regions. Likewise if you need a single high performance region you can tailor your requirements more specifically.

A final note - many simulators are sold as ’supporting 45,000 prims’. This is not reflective of actual usage - the 45,000 number is the largest number the Second Life(R) client will display, however on the backend there is often no limit. That however does not mean the region is capable of supporting 45,000 prims.

We often find that simulator performance degrades rapidly past the 10,000 primitive limit per region and it requires a significant amount of work to get more than 15,000 prims into a region while the region itself is stable, especially when scripts and multiple users are factored into the equasion.

As an addendum to the above - the per region count is not reflective of the per-simulator count. OpenSim can host multiple regions per simulator instance and we have found that the simulator instance itself can host in excess of 100,000 primitives as long as they are distributed between multiple regions.

A note on SLAs and Uptime

OpenSim is still alpha software. If you expect 99%+ uptime, you will also expect to pay for it. Keeping a region running with guarunteed uptime requires active maintainence and attention by an engineer. This means it is impactical to expect 99%+ uptime unless you can afford a technician 24/7.

Our experience with client projects is between 97.6% and 99.2% uptime over the course of a month. (including scheduled and unscheduled maintainence) - this will vary slightly depending on the version of OpenSim used, number of users and other factors.

If someone claims to offer bug-free and stable deployments of OpenSim, they are probably lying or are very naieve. OpenSim will occasionally run into bugs. If you have a specific project in mind that requires a production deployment it is strongly recommended to hire a consultant who is familiar with the OpenSim project (eg DeepThink, IBM, 3Di, Tribal Media, etc.).

List of companies providing OpenSim hosting (note this is incomplete - there are likely to be others)

Customized OpenSim Hosting Providers

The following companies provide customisation services and will tailor your OpenSim install to your specific needs. These companies all provide pricing on a per-server basis rather than per-region.

DeepThink (Managed OpenSim hosting and Customisation services): http://www.deepthink.com.au

ReactionGrid (Managed OpenSim hosting): http://www.reactiongrid.com

3Di (Customisation services, hosting. Tokyo based.): http://www.3di-opensim.com/en/

Not listed here, but likely to offer these services are IBM, Tribal Media and Genkii.

Grid Hosting Providers

These companies provide hosting within the context of a grid. Most of these companies use very similarly specced hardware, however many of them share multiple clients per server - to use Second Life as an example, Linden Lab charges $295 per “island” which is stacked at 4 per server (or $1,180 per server per month).

While I did attempt to compile an exhaustive list of companies here - finding pricing and stacking ratios for many of them proved a difficult and time consuming process. You can find a more comprehensive list of grids (most of which offer region hosting), here:

http://opensimulator.org/wiki/Grid_List

Stability Remarks

As noted all over the OpenSimulator website - OpenSim is alpha quality software. To quote our downloads page

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

If you are putting OpenSim into a production environment, make sure to speak with your hosting provider about what you plan to do - many of them may be able to make recommendations or tweaks to better suit your demands. If you have clients involved - it is often better to stick to an older more stable release as all releases are not nessecarily equal (eg 0.5.8 was somewhat stable, whereas 0.6.3 had appearance bugs).

If you are planning on using the ‘bleeding edge’ version of OpenSim in production, expect to get cut, or again quoting the downloads page:

There Be Dragons Beyond This Point

If you are truly feeling dangerous, adventurous, or want to help us test the next version of OpenSim you are welcome to grab the latest unstable code out of our subversion trunk. Any warnings previous expressed about the alpha nature of the code go double or triple if you are running directly off of trunk. Never, ever, ever, never run this in production environments, it is not suitable for that unless you are very familiar with the source code, and can hot fix any piece of it (that probably means you are an OpenSim core member). Feedback and testing on the unstable tree is appreciated, as that helps us make the next release better. If this scares you from using trunk, that was intended.

If it breaks, you get to keep both pieces.

Final Remarks

Running an Opensimulator instance can be a perfect fit for your organisation or person as long as you respect the limits. OpenSim can provide fantastic discounts to other commercial virtual worlds software, however it is worth remembering that it is still new and experimental - often this can be an advantage in customisability and features, but at the same time you need to respect the limitations of the software.

If you are unsure about whether to put OpenSim into production or how to do it in a way that fits what you need to do - like every Open Source piece of software, there are a lot of developers and organisations who can provide consulting services. Check the Core Developers List on the OpenSimulator wiki for a full list.

As some of you may or may not be aware, earlier in the year someone [see bottom of post] contracted us to develop a secured currency infrastructure for a ‘hypergrid-aware’ environment. Meaning, something that will work even when you cannot guaruntee the simulators (or their operators) themselves are trustworthy. Within this infrastructure we only have two trusted entities - the user, and the “bank” which holds their funds.

The flexibility of this design allows us to setup currency systems that could work on a completely user-supported environment like OSGrid, rather than relying on a “walled garden” ala Second Life(R). It also could be used for multiple grids simultaneously - that is, several independent grids agree to utilize a single “bank”, and are then capable of grid to grid user transactions (most likely supported over a hypergrid link).

How does it work?

The basic method of operation is fairly simple - in both cases, the user attempts to make a payment from within the viewer (such as to another avatar, into a vendor, etc). Where the HG version differs is, it then sends the user to a website operated by the “bank” to confirm the action. The user is authenticated against the bank (via a password or other login), and is presented with the transaction details (amount, who to, etc). If the user is happy with the transaction, they approve it - and it continues to process on the server like any other normal transaction. If the user denies the transaction, then it reverses itself as if it had never been requested.

The basic process

If you examine the module we ship by default with OpenSim, the “SampleMoneyModule” - it is fairly straight forward when operating in a grid environment. When you make a payment in the region (1), the simulator can check and process the payment via the money server (2), then finally confirm the transaction with the seller (3). The biggest limitation here is that it requires trust on most parties involved - for instance if the simulator went ‘rogue’, then it would be possible to just say you made a payment, without your involvement.

This is essential for some types of payments (eg, llGiveMoney), but completely unpractical in an open environment. Eg - it allows for the ‘credit card fraud’ situation, whereby if the seller knows you exist and your account number, then it is entirely possible to debit from it without your permission. Credit cards are badly designed on this respect - there is no ‘confirmation of identity’ with the bank required. (Something there has been some work into fixing.)

By comparison, the DTL currency processor is a lot more complicated - it requires some “handshaking” between the parties before the transaction can proceed. To the user this is transparent mostly, however on the backend there is a more complicated web of data flow, of which there are six major steps.

The first step is the negotiation step - in this step, the user initiates a payment to an object or user (requests a money transfer). The simulator will contact its registered money server and ask for a link that the user can confirm their intent with (1). The user is then given that link via an IM (we’ve also made it possible to configure so that you can get that link sent to you via email from the moneyserver directly.).

The user should at this point (for anti-”phishing” purposes) check that the link they are given is sent from the money server (we strongly recommend using a recognizable domain with an SSL certificate). This link acts as a verification of intent - the money server will present the user with the details of the transaction, and ask them to login to confirm the transaction (2). Eg, see the picture below:

If the user aborts the transaction, then it simply stops all further processing - only a request for payment was made, and no funds have exchanged hands. However, if the user approves the transaction, then the money server notifies the simulator that the transaction was approved (3), this acts in a similar way to PayPal Instant Payment Notification. At this point, the simulator can execute money() events in scripts, approve an object purchase, or send notifications to buyer (5) or seller (6) that their balance has been updated. The money server also updates the sellers account balance with the new funds (4).

To the end user, the exchange can be shown in the following screenshot (the user webpage is a slightly old version now, also ignore the spelling mistake.)

Disclaimer of liability

The above does not guaruntee security - we’ve made as many steps as possible to make this usable in a public environment, however OpenSim is alpha software, and this code does not provide any kind of guaruntee of mechantability or usefulness. If you are planning on starting a virtual bank with “Real Money Trade” allowed, then you need to do a lot more work into fraud prevention and audits of this code before thinking about using it. You use this strictly at your own risk.

Final notes

This is not the final version yet, we still have work to do in that department, however you can access a alpha version on the OpenSimulator forge (Please note, there are no NAnt build files for this project yet - it’s on the TODO list, but Linux users will need to generate them if you want to use this, or get a Visual Studio user to compile for you.)

http://forge.opensimulator.org/gf/project/currency/

Credits

This was developed with funds provided by Michael Huntington - credit to him for sponsoring this project.

Development was done by DeepThink’s Shanghai development team (Korey Wan, Leon Zhu and Jed Zhu [in our plush SH office shared with SineWave]), planning was done by Korey and Leon, with the master architectural design done by yours truly. We’re planning on finishing this project up this week, once we have done so - we will be moving onto a Groups implementation, also sponsored by Michael Huntington.

As many of you know - we’ve been doing a little bit more content development than usual lately. If you have attended one of the Sine Wave Pub Quizzes on OSGrid, you will probably recognise some of the items above. It’s part of our DeepThink content collection - something we’re licensing to people who need to get some nice looking content onto OpenSim grids quickly.

It’s all very low prim (most of the items are either 1 or 3 prims - the majority just a single prim), it’s all professionally rendered and sculpted by our artists, and up until this week, it hasnt really been availible in Second Life itself (with the exception of the halloween content pictured below).

It is now. You can find our content individually packaged and for sale now on OnRez and XStreetSL. We’re still lagging a little bit behind on our OnRez deployment, but we’ll get there eventually (we do seem to find the OnRez interface significantly more thought out). We’ve so far released only a portion of the total content we have developed, and we’re adding more regularly - so expect some new releases fairly often.

We’ve also started to add a little bit of holiday content to our mix - we did a little bit of Halloween content in October which is availible, that content also has some general purpose bits and bobs which would be useful for any gothic or vampiric castle. (Coffins, Tombstones, etc.)

Finally, a small preview of some of the content we’re adding to the mix for Christmas this year, this is still a very early preview (there’s a lot more coming) - but we’re hoping to have it all ready and availible by December 1st.

Where to get it

• OnRez - [Somewhat] Availible now at http://shop.onrez.com/Content_Cyanic
• XStreetSL - Availible at http://www.xstreetsl.com/modules.php?name=Marketplace&MerchantID=210300
• In World - Coming soon to Kuipers.

Pricing

Most items range between L$100 and L$300. Most permissions are copyable / no-trans (although a couple of items are no-copy/trans - check before buying).

Running an OpenSim Grid?

We’ve also got this all availible in a convenient OAR format for OpenSim operators. We provide the content to you under a few restrictions (mostly relating to distribution) as a flat yearly subscription fee for access to our entire library. We also have a bunch of content suitable for realXtend and Multiverse (and probably other virtual worlds). Contact us for licensing details.

Previously…

For those who havent been reading up on the OpenSim IRC channels or mailing list, your probably not aware of the work we’re doing at DeepThink for the realXtend team.

For the last month and a half, we’ve been working with the realXtend team to convert their version of OpenSimulator, to something that closer resembles a suite of OpenSim plugins rather than a fork. Part of this work has been some sponsored contributions to improving the modularity of OpenSim itself with alternate clients (like the IClientAPI changes that are currently in progress), the other part has been conversion of the current realXtend server into a single plugin DLL called ‘ModularRex.dll’ which encompasses all the previous internal changes.

The single biggest bit of news however is, once this is done - realXtend is no longer a fork of OpenSim. It’s not opensim stock, but it’s not a seperate codebase either. Patches from realXtend can be applied fairly smoothly towards OpenSim-trunk and vice-versa, because the core files are unchanged.

Now we’re not done yet, but we’re making some pretty steady progress to getting there by the end of the year - today marks the date at which the core architectural bits and pieces are mostly done and the realXtend server developers can get onboard and help finish the rest.

The code for the modular rex DLL’s is located on the forge project for it. It may not always represent the latest testing versions (since we’re working offline a lot), but we’re doing checkins every now and then - if you’re interested in following progress, that’s the best spot to go. Future development will be going on on the forge exclusively however.

Multiple Concurrent Clients

One of the largest feature’s we’ve now got with the latest version is the ability to insert clients into the scene while bypassing the normal login routines. This may not sound like much - but the technology needed to support this, is the same technology that will allow you to login with two completely different virtual world clients and have a conversation between them, while viewing potentially the same content.

The new ModularRex code skips all the current login methods and actually has a new subclassed and derived version which it enables entirely through a shared region module. In future - we may be able to take this same methodology and convert the current login and protocol handling routines into their own modules which allows them to be replaced without effort.

ModRex Support Table

Features

• Rex Avatars - We support all the packeting for the avatars now, however we do not automatically send this on login yet. If you know your rexav address, you can just type “/rexav http://somewhere.com/myav” in chat to set the parameter manually - or you can wait a few days now that we have login implemented and we can get to setting it automatically.
• Rex Logins - You can now login with a traditional rex username, that is you can login with “username@hostname.com”, and your authentication server will authorise you instead of a direct login.

Infrastructure

• Rex Packet Handling via RexClientView - We implement a IClientNetworkServer compatible interface which deals specifically with the modified realXtend protocol. This is subclassed from LLClientView / LLUDPServer / LLPacketServer but contains overrides and new methods to represent realXtend features.
• Rex Methods and Events on ClientView - We now process a number of the realXtend events and packets and fire new ‘OnRexXYZ’ events that you can use to send specific things to users. This does not effect IClientAPI, rather these are members of RexClientView which means you need to check the client supports features before using them. Currently, we’re sitting at about 13 of 36 handlers - however we’re 13/13[?] if you exclude methods related to RexPython (as of 0.31, there are likely going to be new things to support with the upcoming Rex release).

The TODO List

• Conversion to IClientCore - We started a lot of the conversion work before 0.6.0 was tagged, this means that the realXtend modules use a older method for checking client capabilities. We need to convert it to the new IClientCore interface to allow us standardised access to extension capabilities in modules.
• Finish SceneObjectGroup/SceneObjectPart Overloads - We’re inheriting and extending from the SOG/SOP interfaces to add additional rex-only properties to objects. There’s a degree of difficulty involved here which may nessecitate additional metadata fields in SOG/SOP. A post to OpenSim-dev will be coming shortly no doubt with some suggestions there. This is needed to be able to get rex meshes and other special object features working.
• Provide RexCommsManager - One of the limitations right now with the modular rex code is that Rex Logins (see above) dont provide a valid UserProfile class, because the Rex protocol there is different to OGS1. We need to provide an additional comms manager to allow Rex avatars to be handled correctly, or abstract OpenSim to allow ClientView to indicate the type of CommsManager it needs. This will also allow the global inventory features to be re-enabled (however moving them to the client may be a smarter long term move).
• Write generic LibRexAuth - A problem with the current dealings with the authentication server are that they are fairly hard coded for specific features. It would be nice to add a library or static class which can provide simple functions such as ‘GetProfileByAccountName’ or ‘IsUserAuthorised’ - this allows us to communicate better with the authentication server, saving hassle and headache and centralising things so that problems are more easily fixable. A similar class may be useful for the avatar server - however the simulator’s dealings with that server are very limited.
• Python - This needs to be converted a module, but shouldnt be too difficult as most of the code is presently abstracted and modular. With a little bit of work it may be possible to make realXtend python scripts editable in a similar manner to the LSL/C#/etc scripts, which would be very cool.
• Voice - As with the above, the Rex Voice Daemon is fairly seperate from the main codebase, so porting this should be a fairly quick and painless job.
• Update protocols to 0.35 - We’re currently sitting at the 0.31 release of realXtend which means there might be issues when the 0.35 realXtend viewer goes mainstream.
• Minor bits and bobs - Getting things such as the ODE Mesh Collisions working with realXtend collision meshes may nessecitate some additional work (and probably a subclassed version of our current ODE DLLs with additional functionality). There are probably a number of minor features and fixes that will need to be ported over once the main items on the TODO are done.

So overall, we’ve still got a lot of work to do - but the great news is all the architectural bits are just about done, and we’ve proven that such advanced functionality can infact be done entirely with the current OpenSim region modules.

The Inaugral Sinewave Pub Quiz on OSGrid.org

The initial pub quiz (pictured above) was a success, we got a lot of people to show up - many of whom who have never been onto OpenSim or OSGrid before. We’re so happy with the results that we’re going to go ahead and schedule another one - we’re aiming at Sunday, the 19th 26th of October at 9PM GMT (1PM PST) with a Halloween theme. (Sorry, typo! - edit)

The structure of this event was a three part quiz - a picture round, including naming hollywood movies from a still image (some tougher than others), a music round (name the track from a small clip) and finally a ‘google fu’ round with recent history. There were 24 questions in total - our two first place winners getting 19 of them right (and sharing the $500 in prize money).

Q&A was handled by our bot-in-residence Chinzy Quizmaster running the Sinewave Quizbot code, some suggestions for improvements we’ve added to the development roadmap.

We hope to see everyone who participated at the next one - we had a lot of fun running it and want to make this a regular occurance.

As Promised - The Technical Writeup

Technically the Pub Quiz was overall a success - we got a lot of interesting data out of the test (and a 17mb log file), including the fact that OpenSim seems to scale pretty damn well under a tightly controlled environment. We also managed to isolate and fix three critical bugs with OpenSim which have been contributed back to OpenSim already. In addition we have some information about how OpenSim is handling packets internally which I’ll be interpreting this week to try improve general performance with.

We also learnt some other interesting things about running these kinds of profiled events in future which might be useful to other people

• JetBrain’s dotTrace profiler doesn’t work on OpenSim very well - infact the chances of getting a  “completely random MS Visual C Runtime error” while under their profiler goes up about infinity% (ie, from zero to once every minute). We’re going to try another profiler next time around. A slight shame since we wanted to do a memory profile next time vs re-doing the performance one. That being said, if anything’s going to kill a profiler - we’re it, the Mono profilers dont even start when profiling OpenSim.
• For the most part OpenSim seems to behave pretty well these days, however we do need to get some kind of mechanism inplace to handle when things do occasionally crash to somehow get users into another backup region. EventQueueGet makes this now rather difficult, but it might be possible to do still somehow.
• We’ve still got “Grey Avatar Syndrome” showing up on a number of avatars - however we think these are being caused by simply not having an avatar equipped, or having an avatar that was built with local assets enabled. We definetely need to work on providing a nice default avatar in these cases as the simulator should be able to tell the avatar is using a inaccessible asset.
• Windows 2003 still performs significantly better than Linux/Mono it seems. Our servers didnt hit above 5% CPU usage for the entire event, except during one stack heap (which was fixed). Memory use fluctuated a little bit, but for the most part was sitting comfortably around 230mb of RAM plus a little bit of page.

SineWave (with a little bit of help from DeepThink) is running a big Pub Quiz, this Friday on OSGrid.org. For those who are outside of Britan, read the wikipedia article for an overview on what this is, the rules and format.

The short

It’s on OSGrid.org, in the SineWave Region - 5PM GMT / 12PM EST / 9AM PST, Friday the 10th of October (this friday!). Total runtime is expected to be fourty minutes or so. You should register your avatar in advance on this page.

The rest

You should try test logging into SineWave sometime before the event, as we’ll be trying to start promptly. There’ll be other prizes including some hosting from DeepThink and maybe a little more. Performance will be a little slower than usual since the region will be operating under a performance profiler, but should still be acceptable.

As usual, we’ll publish the profiler results to help other developers - if you want to bring friends, feel free as the more avatars logged in, the better the quality of the results we get.

FAQ

Why are you running this, $500 is a lot to give away randomly? We’re doing this as a load test on OpenSim - we’re looking to get about 100 avatars or so and see where OpenSim stresses so we can optimise and fix those areas.

I need to get onto OSGrid - how do I connect? We recommend you grab the Hippo Viewer, it’s free and will connect by default to OSGrid (although it has support for any modern opensim grid)

Here’s three screen shots from a OpenSim demo that DeepThink is working on to exhibit at Virtual World Expo in LA. If you want to see more, you will just have to come show up at the OpenSim booth and play around with it in real time. (We’ll also put it up online somewhere after the conference is over).

If you are very familiar with the operation of OpenSim (actual developers will be prioritized here) I have a couple of free tickets available for people to man the booths with. Contact me for details.