So, I have a small announcement to make.

OpenSim has had the capability to run multiple different clients connected to the same world since version 0.3. We translate a large number of our internal programming into a somewhat vendor neutral interface; the big catch has been - in the 21 releases since 0.3, we’ve never actually implemented a true second protocol. As of today that has changed, OpenSim now supports two client protocols that can be used simultaneously at the same time to display the same world with the same updates, avatars and interactivity. This means right now you can use either the LLUDP transport used by Second Life™, OpenSim and realXtend, or the new MXP transport developed by the Tommi over at Bubblecloud.org.

We also have some good news from the guys over at VastPark - over the next few days, I will be working with their team to try write another client transport which allows you to use the VastPark viewer to connect to OpenSim. Watch this space for some information about that.

MX Deck and Second Life connected to the same region (Click to Enlarge)

Why MXP?

The simple answer here is the protocol is reasonably well thought out (it’s very refreshing compared to LLUDP), it’s also pretty simple and easy to understand. There’s a good reference implementation on their website which we were able to utilize extensively. To users, there’s potentially some big advantages in how you can route packets from a region simulator to viewers - possibly eliminating some of the issues people see when trying to host from behind firewalls and routers. This is however conceptual - a decent client will still need to be written to utilize the MXP protocol (right now the only clients using it are for demonstration purposes).

The big reasons were however that it’s appropriately licensed, there’s good reference code out there and the protocol is straight forward. It was also in the right place at the right time — while it gets the crown for first additional protocol, we’re hoping to have quite a few more now the infrastructure is in place and tested to properly support alternate client libraries.

How complete is this implementation?

Not very - we implement at the moment about 5 of 250 “functions” the Second Life viewer can present to us, ontop of the basic connection management. Mostly these are relating to display of primitives, updating their positions and chat. We still need to do a good deal towards displaying avatars correctly (and assigning a ‘ruth’ for each clients display of the other). Given the adapter is however less than 48 hours old - I expect to see some rapid progress here in adding features and capabilities to it. To give some idea of what’s working however below is some screenshots of the same region connected to in each client.

How do I connect a MXP client to OpenSim?

Grab a copy of the Demo Client from Bubblecloud.org (see Downloads -> MXP Demo Client.zip) and a copy of the latest release of OpenSim from the OpenSim Trunk SVN.

In your OpenSim.ini, add the following settings to the end

[MXP]
Enabled = true
Port = 1253

Start up your OpenSim and create a region if you havent already - now go into your OpenSim Region’s directory and open your default.xml - cut and paste the sim UUID (looks like this: b18ddeb1-f3d4-4c05-aa55-f1ca55532220 )

Install the MXP Client and edit the MX Deck.exe.config file - you need to paste your region UUID into the “BubbleID” field, and edit the “ServerAddress” to read “127.0.0.1″

Start MX Deck.exe and you should be connected to your OpenSim region.

Voila!

Last week it came to my attention that the server currently acting as the asset server for OSGrid.org is nearly full on disk space, and at the time, moving to an alternate server was impossible due to certain DNS requirements. The ability to move the asset server onto another machine is no longer a blocking problem, however there are a number of serious problems with the way they are currently being stored.

To enumerate the problems at present, the current architecture needs a little description.

Current Setup

At the moment, Assets are stored and retrieved through an interface called IAssetStore, where it gets stored to is up to the module that implements this interface, although the majority of providers use some kind of relational database as a backend. This works well for small grids and standalone regions where the number and size of assets is small, however OSGrid.org (using the MySQL adapter) has several million asset entries and a 75GB table file. Because of the primary key asset requests are still very fast - however performing operations over the entire table requires a 75GB table scan, resulting in the simplest of queries taking several hours.

It should be noted that there is no duplicate detection, and two copies of the same texture will take up the full disk space and table space, given that there is a very high number of duplicates in the database this accounts for a very significant amount of waste.

OSGrid.org’s Profile

OSGrid’s asset server is currently running on a high performance machine donated by the Electric Sheep Company. It’s disk is a ~140GB SCSI RAID-1 array, which fine for the metadata (maybe even overkill) becomes an issue when raw storage capacity is questioned. The current assets table is around 75GB or so, and growing at a rate of approximately 10% per week. At the current rate of growth, the disk will be full in about 6 weeks time, which means migration to something more scalable in the long term is nessecary.

In the long term however, moving to a new server every 6 months is not an ideal situation, especially so since osgrid is a nonprofit enterprise and hence relies on donations. This creates a nessecity to switch to something in which capacity can be more easily added without bringing the grid down, or relying on moving to bigger and better hardware constantly, especially so if it ever hits the kind of scale where it simply becomes impossible to buy hardware big enough. Ignoring any associated problems with RDMS’s and table size.

The second large concern is the inability to run queries against the table due to it’s size - while this will always be a concern, it can be limited by application of appropriate indexes and limiting the table size where possible. Running things such as garbage collection obviously becomes impossible when the table is too large.

Candidates for a Solution

For the last week I have been investigating some possibilities for scaling the asset cluster, without spending anything other than development time (see ‘relies on donations’ above). Some of the commercial solutions, such as the one Linden Lab employ - Isilon OneFS appear to fit most of the requirements, but the cost is simply too prohibitive, there are also some limitations on them - such as difficulty in garbage collection, duplicate linking, etc. Thus our requirements look something like this:

• Partial Replication - Scaling should be achievable by adding new machines into the cluster, rather than hopping from one to another.
• Inexpensive - the total cost for setting this up should not exceed the donations osgrid recieves to keep running. Ideally it shouldnt any new monthly expenses.
• Handles large datasets - while OSGrid only has 75gb of assets, the Second Life grid has 200tb+. This means whatever solution is chosen, it needs to have good scaling prospects and remain useful. Moving from one provider to another is a time consuming and difficult process - so it should not need to be done too often.
• CAS - The DB should utilize content addressable storage to eliminate problems associated with duplicate files - ideally these should be handled completely transparently.

Optional requirements (’would be nice if..’)

• Fault Tolerance - if an individual system goes down, the system should be able to compensate automatically without downtime.
• Caching - Frequently accessed items should be cached for more speedy access in future.
• Read Replication - assets should be requestable from multiple seperate machines to increase scaling properties.
• Very speedy access on a primary key - KeyValue stores tend to be ideal here (eg, BDB) since data access is well controlled.
• In Production Already - Ultimately there’s a lot more confidence in a system if it’s been proven to scale elsewhere already.

There’s a number of solutions which fit this bill - there’s the hosted variety, Amazon S3 / SimpleDB, Bitcache, Custom Hackery of the Routing Asset Server variety, Custom Hackery of the write-your-own-DB variety, etc. Evaluating these options through the above criteria, most of the options were invalidated.

Amazon, or (the hosted option).

Amazon’s S3 is a well known option for storing large  numbers of images for popular websites - it effectively says “Dont do this, we’ll do it for you.”, and if the price was right, it’d definetely be my selection. Unfortunately the math doesnt quite add up for OSGrid to utilize S3 in the long run, at the current rate of bandwidth and size, OSGrid would be paying around $300.00/month - growing 10% per week and running the resulting 7100 GB is a minimum $1,100/month without any transfers or requests. By comparison, the same amount of space on plain hard disks is a mere $2,500 once-off ($10,700 savings over a year is enough justification to skip this one).

Bitcache

After mentioning the problem on IRC, Bitcache was suggested as an option. For those who havent seen it before - it’s a storage engine that operates on REST principles - the main limitation is it requires an additional database setup to store the URLs of where assets are stored if you wish to start moving assets over multiple machines. Not a huge limitation and it’s definetely easier to integrate into the current solution than writing one yourself. The other downsides is it doesnt appear to be used in production anywhere ‘large’ and the backend is written in Ruby which isn’t well known for scalability.

Custom Hackery of the Routing Asset Server variety

This option involves writing a special version of the asset server which instead of processing the request, does a UUID lookup, then sends the asset over to another server which has that asset stored. This allows assets to be shifted around using standard database migration tools. It’s an option, however fault tolerance is an issue as it’s possible to lose a section of the database and suffer the consequences thereof. This was the option I was considering until only yesterday, albeit using a new custom BDB-based adapter for the final asset store to increase speed and scalabilty.

For those who like pretty pictures -

Custom Hackery of the Write-your-own-DB variety

Bad. No.

Enter Fragstore

Fragstore is similar in principle to how a number of the above systems work. Fragstore utilizes a pair of databases at it’s core - one contains information such as access times, hash information, etc. The other contains the data itself - I use the term ‘database’ here rather loosely, since the data datastore is actually a piece of technology called (ugh) Project Voldemort. PV is a Java project used by LinkedIn for their own internal database - it’s similar in principle to Amazon’s SimpleDB and Google’s BigTable - and has similar properties to them in terms of scaling. It has a number of useful properties which match up to the above - including fault tolerence, partial replication, high speed access, caching and more - plus it’s been put through it’s paces at LinkedIn already.

The downside however is that it running queries on say access time would be ridiculously expensive. Likewise it lacks CAS-support so duplicate files would be difficult to track down and link together. It’s also written in Java and lacks a .NET connector (something thankfully IKVMC was able to fix with the help of dmiles).

Fragstore builds upon the strength of PV by utilizing it as a raw data store, but then integrates in a traditional DBMS for handling of metadata and querying the tables. We also connect in access to the old database so assets uploaded to the old system can still be accessed while the conversion is taking place. The result looks something like this:

There’s a couple of key changes to note - first is, we’ve switched from a UUID-based primary key to a Integer one, this is done because of MySQL’s internal lack of a UUID datatype and the speed at which string based primary keys are searched (several orders of magnitude slower). While not used in normal operations - it will allow us to run the garbage collector on a slaved machine and produce a list of redundant ID’s which can be eliminated significantly faster. Likewise, we can eliminate all copies of an asset at once by eliminating the hash value - useful for instance in handling DMCA takedown requests.

When will this be done? I’m aiming for the next few days to have a beta version availible, if it performs adequetly, we will run a test by converting the entire osgrid asset database over to it. Keep your eyes peeled for more information soon.

A picture is of course worth a thousand words.

How to get it?

Please remember, this is alpha software. Not like OpenSim ‘it sort of kinda works’ alpha, but really early code. It may break. It may trash your sim. It may kill small children. You have been warned. Please note, this requires a working realXtend authentication server - if you have a dedicated server on a public IP, you may use the ‘users.realxtend.net‘ service, otherwise a copy of the auth server is included with the standard realXtend server package.

SVN - ModRex is only availible via SVN at the moment.
svn checkout http://forge.opensimulator.org/svn/modrex/branches/0.2-alpha/

Known Issues

This version is not compatible with the Second Life viewer at all due to the Auth server dependency, installing modrex will disable SL based logins. This is a known issue and will be fixed in the next release.

Final Note

This is a preview release and does not construe a final public version not something in search of widespread testing, we’re still actively working on this - a more polished final version is currently in progress which I will encourage widespread testing. This version is not feature-complete with realXtend 0.4 - if you want to use realXtend features in a production or semiproduction environment, I would recommend using the standard server software for the moment.

So, we’re hitting the point where our current work is nearing closure with the Modular Rex code - the biggest thing worth noting right now is some new extensions to allow extra rex properties to be attached to objects. This wasnt implemented quite how I originally envisioned - I ran into some issues where subclassing something simply wasnt practical. While it was possible to do - the number of workarounds required to keep it running in the long term pushed the work in another simpler direction.

The above shows an object stored in ModRex with the additional properties set — to handle this, we’re actually using a second Entity array inside of a module, which monitors agent connections and feeds the array to anyone who can parse it (ie Rex-derived clients). Why not subclass? The short answer here is we ‘construct’ SceneObjectPart classes in a wide variety of places - including serialisers. Replacing all those references with a ISOPFactory class required making a few too many changes for me to be comfortable with. I’d argue it needs to be done from an architectural perspective, however we’re also discussing doing a SceneObject overhaul, and it would be foolish to do such a work when the replacement is nearby.

So - what still needs to be done? Well there’s still the matter of the CommsManager - right now we can use the local comms manager to access inventory ala standalone-mode, however this does require a degree of database synchronisation between your OpenSim UserDB, and the authentication server. In the long term some bigger changes are needed - most notably, I would like to ‘do away’ with the use of UUID’s as usernames and move to the more logical (and unique) Rex Account schema (user@host).

Finally - there’s some nifty parts to ModularRex which I hope to expose to configuration options soon, and that’s breaking up the features more thouroughly. There’s a number of people who want to use Rex features like their avatars and/or meshes, but dont want to rely on the Rex Authentication system — internally this is quite possible to do and once the main pieces are all signed off, that’s one area we’d like to work on.

Update #1: Better Screenshot

OK, so I managed to get OpenSim’s asset system working with modrex again, so Meshes are now sort-of working with modrex (albeit buggy). [Clicky]

So I accidentally didn’t notice my domain was running close to expiring until it actually had expired. Doubly unfortunate has been all the deadlines coming up at the end of the year and my inability to recover my domain host’s username/password becuase the email was linked to said expired domain and their support was unresponsive over the holidays. (Of course).

Mad props to Will for getting it fixed for me before I had to fax documents to france.

Introduction

As many of you know, there’s a number of projects now out there to help build a reasonable complementary viewer to the Second Life(R) one. There’s a couple of reasons for this, going from licensing difficulties, to general code quality, to modularity and adaptability. I won’t mention realXtend or Meerkat here - both are reasonably interesting projects, but both are still derived from the SL viewer with all the problems that brings.

All of the following are under a BSD license - although the programming language and 3D engines do vary a degree between the projects.

Xenki

OK, so it’s probably been a little while since I’ve mentioned Xenki still exists. Well, it does - and it’s had a fulltime developer on it for now several months. You can check out Albert’s work log on the forge site for it, but as the saying goes, a picture is worth a thousand words.

(Pic taken in Abbotts) Now obviously, there’s still work to be done - specularity and lighting obviously need some adjustment, but there’s some things there that havent been shown working before - like textures for instance. There’s also some primitive communications features now in place which are worth taking note of - eg Area chat, etc.

OpenViewer (PyOv)

On the other front - we’ve got a small announcement to make - one of our other developers (Leon) has been working quietly with the guys from Genkii to make the OpenViewer project work under an ActiveX control - mean it now runs in the browser as well as on the desktop, using the same Python code.

The goal here is to make something that can be embedded in a website, but share code across multiple different platforms - eg the same code that runs the website control also runs the desktop standalone application. It also means porting and adding support for other platforms and browsers is quite possible to do - the only code in need of maintainence is the ‘glue’ layer between the host operating system and the Python core.

Finally, we’ve got another new entrant…

IdealistViewer

Teravus - one of the OpenSim developers started this project a few weeks ago, and it’s been making some pretty rapid progress. It’s written in C# with the Irrlicht 3D engine and already looks fairly impressive. The following was taken about thirty minutes before our pub quiz last sunday.

Summary

Now at the moment, all these projects are in their early stages - but we hope in the long run it will be possible to get some of these new viewers off the ground, and in a way which represent significant user-friendly as well as developer-friendly improvements.

If you have the time availible - all of them are accepting outside patches and contributions, all are reasonably worthy projects that target their own niches, and ultimately any work done for one can be ported to the others without any licensing hassle.

Links

Xenki - http://forge.opensimulator.org/gf/project/xenki/ (use SVN for latest versions)

OpenViewer - http://www.openviewer.org/

IdealistViewer - http://forge.opensimulator.org/gf/project/idealistviewer/ (use SVN)

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.

An issue becoming increasingly apparent with the OpenSim platform is that user scripting is a hammer - it works fine if you only need a couple of them, but lots of them running in conjunction and the operating system begins to start running poorly. The common key to fixing this is to use something such as Fibres - small lightweight threads that perform better in mass numbers to full blown Operating System threads.

The problem is - there’s no cross platform way to access Fibres, and we have the additional problem that scripts under OpenSim should be transportable from one server to another - meaning the ability to pack up an execution context, move it to another machine, then resume is a feature we want to support.

Linden Lab’s Jim Purbrick wrote in 2006 about their work to use a modified version of Mono to achieve this - unfortunately with OpenSim we do not have the luxury of using modified runtimes, nor do we plan on dropping support for the official .NET runtime either. This means solutions such as Mono Continuations dont work for us very well.

(Update 26/11/08: I had a chat with Jim after showing him this article - apparently Linden is doing something fairly similar to this proposal already, without the aid of a modified runtime.)

The solution, is ideally something we can run on both .NET and Mono, runs reasonably quickly (but obviously some overhead is acceptable) - it needs the ability to save and restore the current execution state, and it needs the ability to suspend and resume. Suspension and resumation should be fairly fast to allow it to be used in a microthreading context.

These requirements unfortunately knock out a very large number of options - the options we considered ranged from using IEnumerator and ‘yield’ to handle threading (no save/restore or return values), to using reflection to emulate an instruction pointer and stack (too slow and complex).

The idea I am currently developing manages to avoid most of these problems, but requires a degree of runtime code mangling - the result however is something that is generally applicable to generic .NET applications that desire save/resume functionality (or microthreading).

The result centers around Mono.Cecil - the runtime analysis library written by one of the Mono developers. It has a very nifty feature however in that it is capable of changing a CIL stream, then writing back out the resulting assembly - meaning we can at the CIL level, begin to manipulate the results and hook in accessory functions to handle our save/restore worries.

Shadowing Variables

The first thing we need to consider trying to save the state of an in-execution script is that unlike Java, C# doesnt have a MethodInfo.LocalVariables.Get() method - to the C# programmer, the current Method’s stack is completely inaccessible. It does however, have the ability to list the local variables within this method.

And that’s where we enter the shadow variables - the goal of the shadow variables, is to dynamically build a Struct that contains a corresponding entry for each local variable within the method, at runtime we use Cecil to swap references to the local variables, to references to the Shadow equivilent - then saving and restoring becomes as simple as serialising and deserialising the shadow container.

Internally, the shadow container should be created before the method call is begun and passed in as an argument - for something that isnt resuming, it would simply be containing null values.

Resuming Execution

The next consideration is the ability to save and resume from an execution point within the code - this is handled through gratuitous use of the CIL equivilent of a ‘GOTO Label’. After each statement, we place a new label - and at the beggining of the method call, we also add a new argument (”InstructionPointerStartPoint”) and a switch statement that will ‘goto’ the appropriate label.

Since we’re passing the shadow container in via the arguments - we do not need to do anything special in terms of copying data back, as all the code references the shadow container directly ‘as is’. This basically emulates the instruction pointer within a standard x86 processor.

Handling Return Values and the Stack

The final consideration we need to make is recursive calls. Suspendable user methods are allowed to call other suspendable user methods - so we need to implement our own call stack manager to make sure we can save the context of a previous call leading to the current one. (Otherwise resumption would effectively fail).

The solution to this is thankfully fairly simple - we create a new ‘StackItem’ class which contains: A reference to the virtual instruction pointer (where we are currently in the execution), a reference to the function call for this method, and a reference to the current shadow container, as well as an optional reference to a decendant stack item for nested calls.

Before proceeding into a nested call, we need to create a new stackitem for it, and launch it within that execution context, but otherwise it falls together fairly simply.

By folding the stackitems together from the initial execution context, we’re able to then package up a copy of the running execution at any single point in time, transport it, then bring it back later. The whole thing ends up looking something like this.

Optimising

Under this situation, we do have some fairly expensive penalties when it comes to calling into a recursive function, but at the same point there are a number of relatively easy fixes. Functions for example can be inlined - only a very tiny number of functions (such as self-recursive functions) need to be handled fully. The vast majority can be inlined, thereby reducing the need to setup nested function calls in a large number of cases.

One of the goals of the 0.6.0 release is to replace the current IClientAPI interface with something that will improve compatibility down the road with alternative clients. Instead of our current model where we dictate the features that clients must support, the new model will allow clients to pick and choose features we handle, and then implement them.

The basic way this is handled, is through the new ‘IClientCore’ interface. We introduced the IClientCore interface within a few hours of version 0.6.0 being tagged - however switching to the interface internally will take some time - probably a month or two, so any projects using IClientAPI are still safe.

As many of you who have played with writing region modules will know, IClientAPI represents everything you can do to every possible client - as one may guess, this doesnt scale when you begin adding multiple different clients into the mix. It also makes things difficult when two clients have the same feature in radically different ways.

As you can see in the diagram above - all the particulars of IClientAPI are bundled up together as one common interface. It is convenient - but it’s also problematic when it comes to implementing a new client, as you need to stub out every single function - and modules cannot tell whether a particular event or function was simply ignored by the client as unsupported.

Enter IClientCore

IClientCore is presently a very narrow interface - we’re defining it as everything a client must support, whether it likes it or not. As a consequence - we’re sticking to things that every single client has and implements in a common manner.

In practice - this means IClientCore dictates only the Name, ID and other very common internal parameters. It also needs to support two new ’special’ interfaces - Get<IFace>() and TryGet<IFace>(IFace out). These last two are the keys to how the new system works.

Under the new system - we implement interfaces for Chat, Primitives, and each seperate functionality group. It’s then possible to use, ‘IClientCore.TryGet<IClientChat>(…)’ which returns an interface to this clients IChat interface. If the client doesnt support chatting - then TryGet returns false.

The first most obvious question to arise here is related to how this looks more complicated than it used to be, and that’s definetely true - where we differ is that the new model means you need to check a client supports something before attempting to use it.

Previously we had no way from modules to indicate whether a feature was supported on clients - and we also had no way of handling extensions. This also means that if you choose to implement a new Client adapter for OpenSim, you dont need to implement the previous 350 functions and ignore any custom ones. You can write new interfaces for your custom features, and only implement interfaces from the Linden Viewer where you think you share enough functionality to make it useful.

In most cases - the changes arent fairly significant, you can see a comparison of two functions under the old and the new in the porting guide I wrote.

If anyone has any comments or questions relating to this, please let me know.

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.