Which brings me to the following pretty screenshot:

This is a fresh install of Gridmix – one of the main aims of the package has been to make it so it requires very minimal configuration to look good, and do what you want. It’s pretty easily adapted for either a private or a public grid with a host of settings suitable for each.

For example – Signup & Registration, for private grids you might not care about verifying email address. In which case, you signup form is configured like so:

But if you are running a public grid – and you want to ensure signups are legitimate, you will want to verify email addresses, enable a captcha — and assuming you are in beta, you might want to say enforce a ’signup code’ to limit who can create accounts. Your signup form might look like this instead:

The entire skin is very customisable – not only can we easily substitute alternate themes in, but the entire default skin has been setup so that all the images and CSS can be HSL shifted at any time (allowing you to easily recolour your grid with minimal effort)

In addition, we’ve implemented a Mediawiki-Syntax parser into the content management system – allowing you to edit each page on the site using wiki-syntax. This allows you to ensure a consistent appearance across all pages – and keep that in the event that you choose to change the theme.

Finally – there’s a bunch of features in there which I know many people will find a big improvement over what Wi supports; such as Google Maps based world maps (which are generated in realtime – and include live positioning of all online agents on the grid – see the green dot.)

Cost, Availibility, etc.

We’re providing GridMix as an alternative to Wi for all current (and new) SimHost customers who have private grids. This will be a private beta for a period of around three months while we work in any specific feature requests and bugfixes that our customers bring to us – if you are a current customer, just contact support and we can get you setup with GridMix fairly quickly.

We’ll be releasing a limited “core” version as open source software sometime in the future (once we’re out of beta) – we’ve built this all using a MVC framework and have spent some time ensuring that it is both secure, functional and a lot more useful than Wi was. One of the big improvements has been the implementation of an ACL system based on the godLevel – you can now delegate users with a range of roles which grants them certain powers to ban or edit users or change grid settings.

It represents a complete ground-up rewrite, no-code has been copied from the original Wi (or anywhere else), the only foreign code is the base MVC framework. We’ll be adding new features fairly regularly as time goes on – some of the features we plan to implement include some compatibility with the search system, events calendar support & some analytics.

The full version will be available for a fee to non-customers, and a hosted version will be free to all current and future SimHost customers, who have one of our hosted grid packages (or a dedicated server). If you are a current (or potential) SimHost customer and wish to participate in the beta – as I said above, please contact us via support for more information.

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.

I see on a fairly regularly basis reports that OpenSim supports 45,000 prims versus Second Life®’s 15,000. It’s rubbish; but it comes from a somewhat logical source. The viewer itself will not display more than 45,000 objects in the ‘prims parcel supports’ field. There’s no technical reason for it – it just clamps the value (and I’m not entirely sure why). If OpenSim is set to unlimited prims (or 99,999,999), the viewer will show it as ‘Supports 45,000 Prims’ and not what it really is (’Supports “99,999,999″ prims’).

But, you can go well above that boundary. Some of Shenlei’s Leviathan builds are now breaking the 160,000 primitive count mark (and I have no doubt she intends to push it further!), but those builds are incredibly intensive on other aspects of the system, particularly memory usage. Primitive counts as a resource delimiter have never been accurate as far as underlying consumption goes; how they evolved goes straight back to when SL was still a MMORPG with nifty building tools (circa 2002-2004).

This is evident in SL – certain scripts cause “lag”, popular clubs can block other users from accessing the region (by eating up the whole max avatar count) – neither of these is factored into the current resource limits. This is applicable in OpenSim too – an unscripted region will behave better than a scripted one, an empty region will have uptimes measured in months, a popular one in days (or hours).

So, with this entry I aim to do two things – first dispell the myth that OpenSim supports 45K primitives. That is incorrect – OpenSim supports whatever you tell it to handle, whether it behaves is up to the underlying consumption required for your build, and what you are hosting it on. And second – clarify where the limits really are, and how you can optimise them.

With SimHost, we needed to give a number to our potential customers that is indicative of their usage, in a manner that can be understood like prim counts, but reflects the actual capacity used. We decided to go with RAM usage – this is because memory is the primary requirement of the OpenSim software. The amount of memory a region needs is pretty much directly proportional to all the other requirements (scripts need a roughly equal amount of memory as CPU, so do avatars, prims, etc.). There are other limits too – network bandwidth, processor usage, etc. All of these can become a bottleneck depending on the design of a region.

To give you a rough estimate of capacity-by-memory, one of our heavier customers has a 10,000 prim sim which hosts weekly meetings; it’s somewhat scripted – memory use for this region is between 405MB (Resident) and 1070MB (Total). Each avatar to the region adds between 20 and 50mb to the “resident” figure (and when occupied, some of the paged memory moves into the resident as it is accessed). If you use this as an example – 1024MB of resident memory should get you a “standard region equivilent”; if you want to start pushing on it further, then you might want to allocate 2GB dedicated to the region.

Network bandwidth is directly tied to # of avatars plus, # of primitives plus, # and size of textures. You can drop your bandwidth requirements fairly dramatically simply by building more efficiently, encouraging texture re-use, optimising your textures, etc. Sculpties actually work to your benefit here – since they can replace many prims with just one; and that one is ‘instanced’ – so that every copy you use, is only downloaded once by the viewer.

Processor usage is generally not a problem; to avoid any issues – giving a region a dedicated core will let it do it’s own thing. Scripts are about the only thing that can really push this figure (and physics to a much lesser degree). With recent updates to OpenSim enabling much larger concurrencies – processor usage is beggining to appear; but an average user will often struggle to push an average CPU core usage of more than 10%.

So, next time you see the claim that ‘OpenSim supports 45,000 prims’ (as I often do) – think of it not as a hard limit, or even a ballpark figure that is remotely accurate. OpenSim will try serve whatever you tell it to — but whether it does so successfully is more likely to be up to other factors relating to the underlying hardware; than the software itself.

What is being described below is dealing in real currency – you owe it to yourself if you plan to use this, to understand how it works, and perform your own risk assessment. The module is completely unsupported and unwarrantied. Use it at your own risk.

Suppose you are a user of one of the Open Grids or Hypergrid system – and you want to purchase an item, pay into an object, or otherwise transact business where a real currency transfer occurs somewhere down the line. Up until now, in all environments you are reliant on trusting a third party to act as a middleman, providing some currency-equivilent (such as say V$, L$ or whatever.).

The problems with this scenario is that that currency is at best backed by a single corporate entity (and even then they may not choose to ‘back’ it at all) – leaving you exposed in the event something goes wrong. This is compounded by the general trading size of these operators – tending to be sole-traders or small-business; the best scenario is one where neither the user nor the merchant needs to rely on a third party beyond the credit card processor.

Which is where DTL-PayPal comes in, this is a free (3-Clause BSD), open source module we’ve developed to solve this explicit problem. It uses PayPal as the backend for the transaction, and prices inworld goods in US cents. You pay me, OS$100 – and you get a bill for US$1.00 from PayPal. Every transaction needs to be confirmed by you with PayPal thus adding security into the system; in addition you don’t need to carry existing balances of ‘currency’ in order to buy items – each item can be bought individually with a seperate transaction on your Credit Card for each purchase.

The transaction is a 2 step process for the user – which is illustrated in the diagram below. Step one, you ‘negotiate’ the payment size — this is basically filling out the payment or ‘buy’ dialog that the vendor or merchant has setup already. Step two is you will be asked to visit a special webpage (which links to one at PayPal) which sets up and pays the transaction. From a users perspective you need to do nothing more.

Steps 3 and 4 occur when PayPal has confirmed the transaction for you – once the payment is confirmed (usually within 10 seconds), PayPal notifies the module, which in turn completes the transaction, finally PayPal deposits the balance in the vendors account for immediate use.

Obviously the problems with inventory server issues, vendor malfunctions, etc still exist – but to a customer PayPal does allow you to dispute charges on non-delivery grounds (however beware doing this to scam the system – the merchant gets a chance at rebuttal and it can be a complicated process)

From a vendor perspective – the main drawback to this solution is cost, PayPal will charge you roughly $0.28 plus 2.2% for a standard account in order to process the transaction. On tiny transactions (such as one for $0.50, fee would be $0.31) this can add up to a significant portion of the transaction. For users using this exclusively, I highly recommend using a PayPal MicroTransactions account which has much lower fees (but certain additional terms & conditions).

So, where can I get the code for this? It’s on my personal GitHub account (along with a few of my other goodies) – http://github.com/AdamFrisby/DTL-PayPal – I will add some further notes, first this module is currently somewhat hard coded to present a warning to the user about it’s experimental nature, remove this at your own risk. Second – OpenSim is still alpha software, you may run into other issues, so be prepared to handle them if you want to accept payments from users in it. This software has only been tested on the PayPal sandbox so far (and I recommend you do the same), however should work with the live version fine.

Enjoy.

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.

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.

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.