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]

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.