jump to navigation

Educators – what would you most like to see next in OpenSim? February 19, 2010

Posted by justincc in opensim, opensim-applications, opensim-dev, secondlife, virtual-environments, virtual-worlds.
26 comments

Hi folks.  I might not have talked about this much before but one of my chief interests is finding ways in which OpenSim can be better adapted for education and business uses, either as a standalone installation or as part of a larger grid.

I do think that it’s still very early days yet for virtual environments (VEs). Graphically, clients are primitive, especially compared to the latest video games.  Outside of research labs and universities input devices are poor – trying to navigate a 3D scene using a 2D mouse is very unintuitive.  And backend VE infrastructure systems are either proprietary or only just beginning to gather steam (OpenSim, for instance, still being alpha level code with its fair share of bugs).

Perhaps more importantly, I think that it’s also still extremely early culturally.  To me, it’s a bit like the early days of the cinema where people where early films were little more than a fixed camera pointing at a stage.  We’re only just groping beyond the naive ideas of ‘3D websites’ and exact in-world replicas of classrooms and offices.  I think that it’s going to be quite a while before we really know how to use the medium.

Nonetheless, I’m always fascinated to hear of how people are experimenting with OpenSim and other virtual environments, with an eye to using them to achieve their goals.  For instance, it was great yesterday to read Paul Sweeney’s report on a lessons-learned meeting for UK-funded virtual-world education projects, a meeting at which OpenSim was mentioned quite a few times.  Among other things, this adds to the discussions of emerging educational VE uses in last month’s UK Virtual World Watch report and to the earlier activites in this space.

In fact, what I’d like to do today is concentrate on educators (in which I also include trainers, museum curators and anybody else providing a learning experience) and ask them a question.  What would you most like to see next in OpenSim?  Here are a few (!) candidates off the top of my head.

  • Higher stability and reliability.
  • Mesh-based objects instead of/as well as prim-based ones.
  • Easier configuration.
  • Better integration with existing Second Life based educational system such as SLoodle.
  • A proper guest system where users can log in with guest accounts (e.g. Purple Guest, Blue Guest, White Guest) without needing to create an avatar account first.
  • Implementation of missing Second Life features such as the ability to take groups of objects into inventory.
  • Bundling within OpenSim of currently 3rd party-sourced components such as Groups and Search.

Don’t restrict yourself to this list – please feel free to nominate anything you like.  To simulate the limited resources available, it would be really great if anybody commenting could restrict themselves to just one (primary) choice.

I should also make the disclaimer that I probably won’t get much free time to implement any of these soon – already I’ve had to put experiments with updating sculpties from scripts on the backburner.  But I’d be very interested to hear from educational users what their priorities are and this may still influence others in the community both directly and indirectly (that’s one of the great things about open-source).

Talking about OpenSim at the Kopiwa Open Innovation Symposium December 4, 2009

Posted by justincc in opensim, opensim-applications, opensim-integration, personal.
10 comments

Hey folks.  Just a short note to say that I’ll be talking about OpenSim at the Kopiwa Open Innovation Symposium (programme PDF) at Mülheim an der Ruhr in Germany on Monday 7th December 2009.  This is in conjunction with Dirk Krause (Technical Director) and Markus Strickler (Senior IT Developer) of Pixelpark, the largest indepedent digital service agency in Germany (English information here).  We’ll be discussing some of the experimental projects that Pixelpark have created using OpenSimulator, including virtual meeting spaces and training roleplay scenarios based on the OpenSim-In-A-Box project.  OpenSim-In-A-Box is a pre-configured Amazon EC2 OpenSim instance produced by Pixelpark that comes ready-integrated with Freeswitch, a package that enables voice chat within OpenSim.

The symposium itself focuses upon the exploration of “Open innovation” rather than open-source virtual environments per se.  Open innovation is the idea that in order to maintain or gain a competitive advantage in the world today, firms can no longer look chiefly to their own development labs.  Instead, more than ever before they must co-operate with external entities, both the traditional, such as universities, and the non-traditional, such as individual freelancers and competitors.

This is particularly interesting in the context of open-source projects where innovation occurs out in the open and is accessible to everyone.  The OpenSim project, in particular, provides a neutral playground where otherwise fierce competitors such as IBM and Intel co-operate with a myriad of smaller companies and individuals with cool ideas in order to build a common virtual environment platform.  This then forms the basis for the next wave of innovative applications and virtual worlds.

Many thanks to PixelPark and in particular Dirk Krause, a long-time OpenSim enthusiast, for involving me in this.  And apologies for the very short notice if anybody would have been interested in attending – I wasn’t too sure if I would be able to make it until very recently.  The papers themselves will be released in book form early next year and I will be sure to link to any material that comes out on the web.  Of course, I’m also very happy to discuss any of ideas in this blog or elsewhere 🙂

The Parallel Selves Message Bridge February 4, 2009

Posted by justincc in opensim, opensim-applications, opensim-modules, psmb, secondlife.
25 comments

Introduction

Late on Monday evening (GMT) I published my first external OpenSimulator region module (i.e. one that is not bundled as a core OpenSim component).  This module is the Parallel Selves Message Bridge, and it’s available in binary and BSD licensed source code form at the OpenSimulator forgeShenlei has already written about it from a user’s point of view – this post is to give some more background and technical information as to exactly what it is.  I’ll also write again soon about my experiences in creating the module itself and where I think OpenSim’s region module system needs to improve.

The Basics

The Parallel Selves Message Bridge (PSMB) can be used in a standalone OpenSimulator instance to exchange instant messages with people in another Second Life compatible target system.  The target system can be another OpenSim standalone, an OpenSim grid or even the Linden Labs Second Life grid.  The bridge works by relaying messages through an avatar account that you already have on the target system (hence the name Parallel Selves).

For instance, suppose that I have an avatar called Fenn Meredith on the Linden Labs grid.  Fenn has a very good friend called Lulworth Beaumont on that grid whom she would like to keep Instant Messaging throughout the day.  However, Fenn also wants to do some building work on a local standalone OpenSim instance and doesn’t have a powerful enough machine to keep two Second Life clients open at once.

How can Fenn keep chatting to Lulworth?  One way is to use a text only client to remain connected to the Linden Labs grid, such as Katherine Berry’s AjaxLife or Linden Lab’s own forthcoming SLim client.  But in this case Fenn really wants to be immersed in the building work that she is doing – he doesn’t want to have to flip between applications every time a new IM comes in.

This is where the Message Bridge comes in.  Once the module is installed (which involves copying a dll to OpenSim’s bin/ directory and making a few configuration changes), Fenn logs in to her local OpenSim.  She then types

/bridge co mySLPassword

into the client’s chat area (this chat is intercepted by the PSMB module – it doesn’t get spoken in world).  The module uses the password to login the existing Fenn Meredith account on the Linden Labs grid using libsecondlife.

psmblogin

Once that avatar is logged in, the friends list from the Linden Labs grid is imported into the local OpenSim instance, creating an entry for Lulworth Beaumont in the client’s Contacts window.  Fenn can then work in her OpenSim standalone but still send and receive instant messages from Lulworth using the normal Second Life client IM interface.

psmb-from-os

psmb-from-sl

Limitations

We’ve had this module running internally with Black Dress Technology for a few weeks now and it has been working pretty well.  However, it does have quite a few limitations, some minor that could be overcome with a bit more coding, some much more major.

Among the minor issues is the requirement that both the target the source system avatars have the same name.  The module also only allows one target system to be specified rather than multiple.  Problems like these can be overcome with a little bit more coding.

The more major issues stem from the fact that the module requires you to connect parallel avatars in order to relay Instant Messages.  This is a kludge – a much better way to transfer Instant Messages would be through a proper gateway that didn’t require a user account on each individual system.  As far as I recall the Linden Lab sponsored Architecture Working Group was looking into this, though it could be some time before we see any results.

The parallel avatar requirement makes it difficult to get this approach to work from an OpenSim grid (rather than from just an OpenSim standalone).  Quite a lot of extra coding could get it to work from a single region server on a grid.  A lot, lot more coding again could probably get it to work for an entire grid.  However, there are major trust concerns in getting this to work on a grid – region servers either end up with your target avatar password or have access to the connection you establish.  On a completely private grid this might be okay (presuming that you trust the grid operators completely or you run the grid yourself).  On a commercial closed grid or an open grid where third parties are operating region servers the trust issue is probably insurmountable.

The future

The PSMB module has proven useful already, and with a bit more work it could become useful to more people.  Even where it isn’t useful, there’s always a chance that it might add a tiny bit more impetus towards the eventual goal of a proper IM exchange system between virtual environments.

In the mean time, patches and feedback on the PSMB project page are most welcome.  I would consider the code to be at an alpha level right, so any information about bugs would be appreciated.

I can’t guarantee how much additional work I’ll be able to put in for features unless there’s something that I really need, but I always find that constructive user feedback and requests provide a great motivation for doing additional work.

Preventing user script execution in OpenSim applications December 5, 2008

Posted by justincc in opensim, opensim-applications, opensim-tech-basics.
4 comments

opensim-logo-short-padlockOpenSim aims to be a general virtual environment platform, useable as a basis for software applications as well as public virtual worlds.

However, for an application to use OpenSim with the Second Life protocol and client there are some restrictions that we may want to apply that would either not be desirable or would be impossible to enforce in a public virtual world.

For instance, suppose that you wanted to use OpenSim as part of a virtual business conferencing application.  You may want to allow users to be able to copy and execute pre-existing scripts (for example, so that they can display and flip between slides on a projector screen) but not let them be able to create scripts that send any user within range their business card.  This might be done to perserve the user experience or for various other reasons.

How might the ‘no auto-sending business cards restriction’ be enforced?  In this particular case, one could stop LSL methods such as llGiveInventory() from executing (this can’t currently be done in stock OpenSim but it would be easy enough to patch the code such that this method doesn’t do anything).  However, one might want to go a step further and stop any user script from executing.  The rest of this blog post explores how we can currently do that.

Of course, there are various trade-offs from going down this route.  On the plus side, preventing user scripts entirely would make scripting engine performance more predictable.  Support costs could be reduced since there won’t be any scope for user scripts to interact with other scripts and avatars in unpredictable ways.  This reduction in unpredictability would also make the user experience more uniform.

The flipside of a reduction in unpredictability is a lower level of direct customization for ordinary users.  They would no longer be able to directly write their own scripts to provide functionality that the original designers never thought of, either for public consumption or for personal use (e.g. huds).  It would still be possible to get these scripts in via an administrator but this is often a painful barrier to cross.

Suppose that you did want to go ahead with stopping users from running their own scripts.  In this case we can’t simply stop scripts belonging to ordinary users from executing at all since in the business conference application we still want them to be able to run pre-canned scripts.  One approach is to only allow scripts to execute that have certain checksums (which acts as fingerprints).  This could be quite good in a finalized application where no new scripts are being created or introduced.

However, the approach that we’re going to explore here is one where ordinary users are prevented from editing existing scripts or creating new ones in the first place.  In OpenSim (as of r7623, post 0.6), this can be done by tweaking some settings in the OpenSim.ini file.  First of all, you have to have permissions enforcement turned on with the following entry (it is actually turned off by default).

serverside_object_permissions = true

In order to allow administrators/gods to still be able to edit and create scripts, one also needs to make a setting to allow god mode.

allow_grid_gods = true

Finally, there are two settings to affect who can create and who can edit scripts. To restrict script creation, the settings need to be changed so that only administrators/gods have these abilities

allowed_script_creators = gods
allowed_script_editors = gods

save-permission-deniedNow when OpenSim is restarted, only users that are gods can create and edit scripts.  For other users, selecting the new script option in the Linden Labs client interface will have no effect and saving edited scripts will not be possible (this is a situation where one could possibly remove these options from a client altogether).

There’s currently no good core OpenSim way of conferring and removing god status from users, though external projects may provide one.  At the moment to make a user an administrator you have to directly change a setting in the user database, with an SQL command such as

update users set godLevel=400 where username="Justin";

400 is the magic number where a user is considered an administrator.

As this solution for stopping user script execution relies on preventing them from creating or editing scripts, it is not really useful in situations where the region is connected to a public grid where the are region or grid servers controlled by a third party, as scripts can then be inserted at the grid servers directly or simply be imported over the border from other region servers (this is a situation where a fingerprinting approach may be more useful).

At the moment I would regard this approach to preventing user script execution as experimental.  Although the obvious routes to creating and editing scripts have been sealed off, there may still be some obscure method that remains viable (though I hope this is unlikely).  Any help in plugging gaps that exist would be much appreciated.