justincc’s opensim blog

Hello everybody. This is a short summary of OpenSim development for the past week up until last Saturday, as culled from our source code repository logs. The changes picked out are user visible changes - most refactoring and stability revision are left out, unless they’re of particular interest. The numbers in brackets are the final svn revision numbers in which the work was completed for this week. This is right at the cutting edge so there is no guarantee that this functionality is stable.

So, this week in OpenSim ( r4519 - r4617 )

• Teravus Ousley implemented the DIE_AT_EDGE status flag for objects. He also stopped temporary objects being persisted (r4529).
• Yzh and Melanie Milland contributed patches, further enhanced by Teravus Ousley, to implement llRezObject() (r4530).
• Teravus Ousley moved scripting errors to the DEBUG_CHANNEL (r4531).
• Teravus Ousley improved llApplyImpulse() so that when an impulse is applied to an attachment, that impulse is applied to the avatar (r4535)
• Middelink contributed a patch which fixes a bug where LSL state identifiers could not contain numbers after the initial letter (r4549).
• Xantor contributed a patch to improve our implementation of llParticleSystem() to allow choosing of particle textures by inventory name as well as key (r4551).
• Kurt Taylor contributed a patch so that OpenSim can determine the current SVN build version number, as long as the root .svn/entries file is present (r4553).
• Teravous Ousley implemented llTakeControls() and llReleaseControls() (mostly) (r4572).
• Teravous Ousley made fixes to prim extra params, sculpty handling, light handling, flexi handling and corruption of prims when changing the prim type of a sculpty prim (r4580).
• Alan M Webb contributed a patch which corrects for sim time dilation in llGetTime() and llResetTime() (r4584).
• Neas Bade (sdague) fixed llTargetOmega(), along with a small patch from Michael Osias (r4585).
• Middelink contributed a patch to improve our implementation of llListen() (r4587).
• Middelink contributed a patch which partially implements llGetPrimitiveParams() (r4588 )
• Dahlia contributed a patch which fixes the physics orientation for a triangular hollow box prim (r4596).
• Melanie Milland contributed a patch which fixes int -> bool casting of LSL functions which return an integer (r4598 ).
• Melanie Milland contributed a patch to convert a string to a vector in LSL (r4599).
• Teravus Ousley added experimental proper sculpted prim collision (r4600).
• I made a small refactoring change which means that all servers can now be shutdown with the “quit” command (previously only the region server responded to this command) (r4601).
• Jed Zhu contributed optimizations and collision fixes for the BulletX physics plugin. This should now be functional (r4605).
• Michael Osias contributed a patch to stop compilation errors under Windows on integer equality comparison in LSL (r4606).
• I reverted fetch inventory back from CAPS to UDP for now - the Linden 1.19.1.4 client appears happy to use CAPS, and Linden’s 1.21 servers don’t appear to be using this CAPS service.   This fixes problems with selecting a texture in the prim edit pane (r4611).

Hello folks. Today I thought that I’d write about the modular nature of OpenSim. Modularity is of great importance to OpenSim since its goal is not explicitly to provide a complete Second Life service implementation. While the current Second Life protocol does provide a handy trellis up which OpenSim can grow (a little bit like POSIX did for Linux - though in this case the existing “standard” is both evolving and not very well documented), the guiding philosophy is to make OpenSim a platform for 3D environments in general, as stated on our front page. We hope that OpenSim will ultimately be useable as a base for many systems, covering the range from standalone 3D applications (such as data centre monitoring) to different types of virtual world grids. By changing or extending the OpenSim kernel using various modules and plugins, different metaverse systems and programs will hopefully be able to use the same base platform for different viewers, protocols and region features.

Thus, modularity is a crucial part of the OpenSim system. By a “module”, I mean a class or a set of classes (within a .NET dll) which can easily be integrated with OpenSim in order to either provide different types of core functionality, or provide extensions to the existing codebase. If one doesn’t count alternative grid service implementations, all the modules which I know to currently exist come bundled with OpenSim (such as the experimental SVN module which allows you to periodically backup your region to a subversion control system, and the dynamic texture module which uses .NET libraries to create a texture on the fly using draw commands). However, over time the real power of the system will come in allowing other people or organizations to write their own module code to make OpenSim do pretty much anything they want.

Since this is a tech article, I want to go on a brief tour of the modular system as it exists today. I’m going to cover three of the major types of module in OpenSim - database plugins, application plugins and region modules. We’ll take a look at each of these in turn.

OpenSim Database Plugins

These are the plugins which provide an interface between OpenSim and the database system that it’s using to store data. In an OpenSim distribution, these are found in the OpenSim.Data.* namespaces (such as OpenSim.Data.MySQL and OpenSim.Data.SQLite). Each of these namespaces is populated with classes which implement the storage interfaces for the various OpenSim services. So, for instance, OpenSim.Data.SQLite.SQLiteInventoryStore is a class which implements IInventoryData, translating calls to methods such as IInventoryData.GetInventoryFolders() to the necessary SQLite SQL commands required to retrieve the folder data).

This means that anybody can come along and implement the necessary interfaces to make OpenSim use another database. This was done with MSSQL, which also sits in our build tree. However, the problem that we currently have is that a database module writer ends up implementing lots of custom code in order to talk to the backend system - it’s much easier currently to copy, paste and adapt than it is to extract common module code. Getting the code right for the foibles of each individual database is difficult, and means that unless someone is actively maintaining a plugin, it easily falls into disrepair (as has in fact happened for some of the MSSQL plugins).

Luckily, there are various ways to tackle this. Core committer Neas Bade (sdague) is currently working on the production of a set of NHibernate plugins, following preliminary work by developers such as Impalah. NHibernate can handle all the necessary work in persisting our objects to the database. Moreover, it means that in the future, OpenSim should be able to use all the databases which NHibernate supports, which is much larger than the set we could ever hope to reliably maintain. So much of what I’ve just told you should one day become obsolete, unless you want to use a database which NHibernate doesn’t support

OpenSim Application Plugins

These are plugins which act over the whole OpenSim server rather than just for a single region. Application plugins implement the IApplicationPlugin interface which provides just two methods - Initialise(), which passes in a reference to OpenSimMain by which the application plugin can get the information it needs, and Close(). Application plugins are found and instantiated using the Mono.Addins system (which also works under Microsoft’s .NET implementation).

There are a couple of examples of application plugins in the OpenSim build tree. One of these is the Remote Admin plugin, which allows certain OpenSim functions (such as shutdown and region creation) to be controlled by XML RPC calls rather than from the console.

OpenSim Region Modules

These are modules which operate at the region level (hence the name!). As mentioned earlier, these cover both fairly core functionality (such as the Chat module which is needed to allow anybody to say anything!) and extension functionality (such as the SVN backup and dynamic texture modules). The modules are currently a little scattered about the OpenSim tree (though there is now the beginnings of a categorization in OpenSim.Region.Environment.Modules), but they all implement the IRegionModule interface - a simple interface whose most important function is to pass in scene data when the module is initialized.

Apart from this initialization, region modules generally get and send information in one of two ways - either by registering for scene events (which is often done by modules that extend existing functionality and don’t need to pass back any data), or by registering a module using an explicit interface which the core code can later call. An example of the latter is the Permissions module, which registers itself with an IScenePermissions interface. This interfaces contains methods such as CanRezObject() that the scene can invoke when it wants to know whether object rezzing is permitted for a given entity.

You can find others examples of region modules by looking through the OpenSim code tree. There is also some documentation on the OpenSim wiki, though this does need to be updated.

In conclusion

We’ve covered three of the major types of OpenSim modular functionality. In addition, though, there are also other types of modularity (such as the ability to substitute alternative scripting engines) that I haven’t gone through here.

At the moment, the module system in OpenSim is pretty immature. For instance, it’s questionable as to why we’re using different systems for application plugins and region modules. There’s also currently no proper way of turning modules on and off, something which needs to be addressed. But even so, if anyone does get interested in changing or extending a part of OpenSim that can’t be done in the current module system, please do let us know. I am, as I’m sure are other core developers, very interested in providing the interfaces and architecture needed to accomodate further modularity.

Oh, and if you do write any modules, please feel free to list them on our related software page!

Hello everybody. This is a short summary of OpenSim development for the past week up until last Saturday as culled from our source code repository logs. The numbers in brackets are svn revision numbers in case you want a little more detail. As ever, this is right at the cutting edge so there is no guarantee that this functionality is stable. I meant to write this up yesterday as usual, but a rare gaming session didn’t see me get home until t 3am yesterday (well, this morning).

Anyway, this week in OpenSim ( r4382 - r4518 )

• Teravus Ousley did more work on attachments. He implemented a goodly amount of inventory related attachment functionality (such as attaching and detaching from inventory) (r4384).
• We applied a patch from Melanie Milland to implement the touch_end LSL event (r4385).
• Teravus Ousley implemented 3 to 5 level undo functionality on prim position, rotation and scale (r4387).
• Patches from Dr Scofield added the ability to run OpenSim without a console, controlling it via RPC admin commands (r4390, r4400). For more details, see the opensim wiki page
• Teravus Ousley added the persistence of land sale information over region server restarts (r4422).
• Teravus Ousley made some improvements to the positioning and scaling of objects rezzed out of inventory directly onto a prim in the environment (r4438).
• We applied a patch from Xantor to implement llAngleBetween (and fix llRound to be Linden compatible) (r4440).
• Teravus Ousley made more improvements to in world prim duplication. This isn’t yet complete (r4483).
• Adam Zaius fixed a bug with the Terragen loader on loading terrains which were not sized 256 x 256 (r4516).

There was some instability during the week with executing LSL scripts, but hopefully this has been resolved by r4504.

Hello everybody. This is a short summary of OpenSim development for the past week up until yesterday, as culled from our source code repository logs. The numbers in brackets are svn revision numbers in case you want a little more detail. As ever, this is right at the cutting edge so there is no guarantee that this functionality is stable.

This week in OpenSim development (r4283 - r4381)

• We applied a libsecondlife patch from mjm to fix prim rotation issues on linking (r4374) (mantis 556 and 557).
• Adam Zaius added some more experimental subversion region module commands, including autosave (r4298), specific revision region loading (r4287, r4285) and gzip compression support (r4304).
• We applied a patch from Mic Bowman (further extended by Teravus Ousley) to implement llUnsit() (r4310).
• Teravus Ousley implemented no script areas (r4311) and llScriptDanger() (r4312).
• We applied a patch from Kurt Taylor for llGetSunDirection() (r4330).
• Dr Scofield contributed a patch which fixes load-xml2/save-xml2 crashes when basic physics is used (r4331)
• I made a small fix which means folders created but left as “New Folder” are now properly persisted (r4334).
• Melanie Milland completed the type tables for prim inventory persistence so that it should now be possible to store any item in a prim’s inventory, including objects in addition to the existing storage of scripts, textures and sounds (r4335). In this revision she also contributed a fix for avatar animations.
• Melanie Milland added support for llRequestPermissions(), run_time_permissions() event, llGetPermissions(), llGetPermissionsKey(), llStartAnimation(), llStopAnimation() (r4336). She also added support for llDialog() (r4340), llSetPayPrice(), money(), llGiveMoney() (r4356) and llDeleteSubList(), as well as implementing support for the INVENTORY_ALL selector in ll inventory functions (r4352). Additoinally, she implement llRegionSay(), llSetPrimitiveParams() (r4377) and llListSort() (r4381).
• Melanie Milland contributed a patch which applies linear volume scaling to sounds (r4337).
• tglion contributed a patch so that new prim creation attempts obey parcel permissions (r4342). Unfortunately this check is bypassed by direct drag from inventory.
• Teravus Ousley partially implemented llSetStatus() (r4345) and fully implemented llTarget(), llTargetRemove(), at_target(), not_at_target() (r4366).
• I fixed trashcan emptying on grid and standalone modes so that all folders and items are emptied, not just those which are immediate children of the trashcan folder (r4346, r4354).
• Alan Webb contributed a patch to fix a negative indices bug on llListInsertList() (r4358).
• Teravus Ousley started work on much more extensive support for attachments. Friends can now see attachments, attachments can be positioned and rotated (though not persisted) and detached (r4359). Attachments can now also cross regions and accompany you on a teleport, as long as both regions are at or past r4373.
• I implemented a first draft of prim inventory to avatar inventory dragging. This dragging can now be done, although currently only the owner can successfully drag, even if the everyone permissions are set to “everyone can copy” (r4379). Also, this only works for new prims, not ones which were created before this revision.

One of the things I really love about OpenSim is that it gives us a platform for all kinds of experimentation. One of the experiments going on right now is the establishment of “open” grids using the Second Life protocol. An “open” grid, such as OSGrid, is one where anyone (subject to the grid owner’s agreement), can host their own region server and reserve a place for it in the grid map. Once the server is online, it appears in that grid’s world and can be flown/teleported into and out of just like any other region. This is in contrast to “closed” grids, such as the OpenLife and the Linden grids, where all region servers are hosted by a central entity (though it looks like the Linden grid is soon to open up in a limited fashion by allowing IBM to host region servers of its own).

By terming these “open” and “closed” grids I don’t mean that “closed” grids are evil in any way - I think there are very good arguments for running a grid as a “closed” grid. One of these is quality control - if you’re running an “open” grid, large chunks of your world may suddenly disappear if region servers you have no control of unexpectedly go offline. More insidiously, if the software running the region isn’t working as it should then the experience of users may be degraded in various ways. For example, all inventory requests in OpenSim are currently routed through the region server. This gives the region server provider an opportunity to maliciously or accidentally return an empty or garbled response to an inventory request, possibly rendering your inventory invalid until you clear your cache and relog).

Nonetheless, there are a number of exciting things about an “open” grid that I think make it an idea very much worth pursuing. Most of these stem from the fact that it leaves you in control of your own server. Don’t like the performance on your region? Then get more powerful hosting on the open market. Want to allow web users to spectate on events in your sim? Then add in an OpenSim module which streams flash video from a fake avatar acting as a camera (this is just a random idea - I’m pretty sure it doesn’t exist yet for OpenSim!).

So what, then, are the current challenges for an “open” grid? One of the chief problems is that up until recently, it looks like the second life protocol was designed with a “closed” grid in mind. This is manifest in the Linden viewer in various ways. For instance, to go back to the earlier inventory example, once bad inventory information has been passed to the viewer by a rogue region, I believe it can’t be replaced with new information until a relog (and possibly a cache clear). Actually, I’d love to know if this isn’t true but it’s rather difficult to determine since we can’t look at the viewer source (for reasons which have been exhaustively covered elsewhere) and Linden Lab hasn’t published all that much information on the protocol.

Also, to be fair, some of the newer protocol changes may make it easier to host an “open” grid. For instance, with the inventory example above, it certainly would have been true with the old method of sending inventory information directly in the client’s UDP session (which is connected to the region). However, with the new CAPS method of retrieving inventory (see here for an explanation of CAPS), it might be possible to provide a capability which routes inventory requests directly to a grid server rather than via the region server.

Although agent inventories are a challenge for an “open” grid, today I really want to talk about the asset issue. The architecture of OpenSim currently has a very centralized model where all asset data is hosted by an asset service run by the grid operator. For a small scale grid, this could be a single server (for example, the reference asset server provided by the OpenSim distribution), hooked up to a backend database.

As the grid grows and more regions come online, the load on the asset server increases. The chief increase is in texture data - additional regions have neat terrain and objects built on them with lots of interesting textures, and the extra regions attract more people who want lots of individual pieces of clothing.

Here are two possible responses to this problem. The first is to scale up your central asset service - throw a few more servers in and tune up your database. This is relatively nice and simple, but it may mean you have to start charging for uploads to reflect your storage and maintenance costs. This might be a perfectly acceptable business model (an “open” grid isn’t necessarily a non-commercial grid).

The second is to distribute the asset data. Instead of hosting everything yourself, allow asset uploaders to provide an alternative location from which to retrieve textures, scripts, sounds, etc. This could be as simple as placing them on a webserver. This reduces the load on a central asset server and may allow an “open” grid to scale to a much bigger size without needing a commercial or formal donations system.

Naturally, there are problems with such a scheme. Suppose you buy an item from a vendor hosting their own texture data. What happens if their asset service goes offline? If you want to allow other people to come and build on your region, how do you make sure their asset uploads are routed to your asset service (assuming that’s what you want) rather than their own? I don’t know currently whether such problems are surmountable.

Is there any way that a distributed asset system could be implemented in OpenSim today? Using the current Second Life protocol (which is the only one in town right now) this might be possible. All asset requests (whether through the client’s UDP session or via CAPS), are routed through a central point, which means we would have to store a pointer in the asset database in order to tell the client where it can find the data for a particular asset. Under CAPS, I believe this http location could be provided directly to the client, resulting in an interaction as illustrated below.

We still need to contact the central asset service for each request, but at least all the asset data doesn’t have to be stored at, and flow through, this single point. Ideally, one might want to embed the asset’s location directly in the asset metadata so that the request can be made to the external data source directly.

However, I don’t believe this is currently possible within the Second Life protocol.

So far this is just an idea, but it might be one worth exploring in more detail as “open” grids continbute to grow in size. I’ve taken a high level view of the distributed asset approach - almost certainly there will be issues once you get down to the nitty gritty of trying to make such a thing work. Constructive feedback is welcome - particularly in light of that fact that I’m not overly familiar with the plans for the evolution of the Second Life protocol (mainly because of a chronic shortage of time!).

Hello everybody. This is a short summary of OpenSim development for the past week up until yesterday, as culled from our source code repository logs. The numbers in brackets are svn revision numbers in case you want a little more detail. This week in OpenSim development (r4216 - r4282)

• sdague changed the Sim <-> IRC bridge so that only text on channel 0 from the sim is relayed to IRC. Previously chat on all channels was relayed (r4226)
• teravus implemented the ability to transfer land
  parcel ownership in standalone mode. To activate this you’ll need to add

  -helperuri http://127.0.0.1:9000/

  to your list of client startup arguments (r4228 )

• Dr Scofield contributed an Asterisk voice module which should eventually allow OpenSim to be coupled with an Asterisk VOIP gateway. This doesn’t give us voice yet. For more details, see Dr Scofield’s own blog post (r4236).
• sdague made a bug fix which may remove a long standing OpenSim crash characterized by a StartTimer()/invoke_void exception on the console (see this bug) for one example (r4248).
• Melanie contributed a patch to implement landmarks, though you can currently only make a landmark if you enable admin options in the Linden client’s Advanced menu first (r4248). Chris Down contributed an additional fix to the landmarks code (r4258).
• Alan Webb contributed fixes for various LSL list manipulations (r4254, r4255) and llListRepliceList and llList2CSV (r4268).
• Adam Frisby added an experimental Subversion region persistence and restore module. See Adam’s blog post for more details (multiple revisions).
• Melanie contributed a patch which implements llGetInventoryKey with permissions checking. She also improved llSetTexture to allow texture references by name (r4271).
• teravus added object lock persistence (r4272).
• Alan Webb contributed more robust LSL string manipulation code (r4276).
• akio contributed a patch which properly scales linked objects (r4280). Thanks aiko!

Hello there. This is the first in an irregular series of articles about some of the technological basics of OpenSim. Please feel free to suggest further topics in the comments, though as OpenSim is already large enough to make it difficult for a single person to understand, I might only be able to talk about a small proportion of them :). This means I also take no responsibilty for the accuracy of these articles - even if they are correct right now, the rapid evolution of OpenSim might very quickly make them invalid.

I will be assuming a certain amount of OpenSim and general technical knowledge, though I hope to keep this to a minimum.

Anyway, today I want to talk about the letters U, G, A, I and R (also known as S). Apologies for the crappy graphics, by the way.

Don’t worry - I’m not going to launch into some extended Sesame Street metaphor. Rather. these letters represent the different ’services’ in OpenSim. In order,

* U is the user service. This primarily handles user logins and logouts. This means that the user needs to be authenticated, and the region which is going to receive them needs to be told that they are coming.

* G is the grid service. When OpenSim is in a grid configuration (which we’ll talk about later on), it handles the registration of region servers with the grid, and is responsible for telling regions about their immediate neighbours. It also handles some of the main map functionality (which doesn’t work all that well at the moment).

* A is the asset service. This is a simple service which just retrieves and stores asset data (scripts, textures, sounds, etc).

* I is the inventory service. This is the service responsible for storing and updating your inventory folders and items.

* R is the region service (or Sim service). This is the big one - it contains orders of magnitude more code than all the other services. As you can probably guess, it’s responsible for actually providing an OpenSim region - so its major roles include handling the client sessions, managing the 3d environment and running scripts. It’s also responsible for telling a neighbouring region that an avatar is on its way when you cross a region border.

So why am I calling these things services rather than servers? This relates to the fact that OpenSim can be run in two configurations, standalone (or sandbox) and grid. In standalone mode, all these services are run as local code in the OpenSim executable. So when you open a script in a prim inventory, for instance, your client thread runs directly through the inventory code to find the asset UUID, then runs through the asset code to retrieve the script itself (ultimately from your local database). However, if you’re running on a region server in grid mode, the same action will

1. Query the local inventory information cache for the asset UUID. The cached information was itself retrieved from the grid inventory server when you entered the region.

2. Query the local asset cache for the asset. If the asset is there, it is returned directly. If the asset is a texture and it isn’t there, then we send ask the asset server for it and place the request on a queue. Once the asset server gives us the data, we take the queued request and use it to send the texture data back to the client. If the asset is not a texture, I have a suspicion we just wait a while to see if it comes in, rather than queueing the request (which is what we should be doing).

So as you can appreciate, what goes on in grid mode is rather more complicated than what goes on in standalone! And this is a major reason why grid mode can be rather unstable with our current alpha codebase. For instance, if when you cross into a region the inventory server fails to deliver your inventory and you then open a folder in your client’s inventory, the region server may tell you that there is nothing in that folder - it might seem that all your items have ‘disappeared’! If you then create new items on that region, there’s then a good chance that they won’t be properly stored in your inventory, and the next time you login, they will have disappeared. This problem is compounded by the fact that the Linden client caches the inventory, so unless you clear your cache - those items may seem to have disappeared permanently (even though they haven’t). We actually hope to address some of these problems soon (probably by popping up a big fat textbox telling you that your inventory has failed and that you need to relog :).

Also, the current configuration of services, and perhaps the basics of the service architecture, will almost certainly change in the future. At the moment, we’re running with something called Open Grid Services 1 (OGS1). This is the first iteration of OpenSim’s grid and inter-region communications standard. However, Michael Wright (or MW), our dear founder, often talks about the need for an OGS2 (or possibly an OGS1.5). I don’t think there’s a firm idea yet of what this will contain, but among possible candidates are changes to make it easier to register custom services (not the U, G, A, I and R that OpenSim has pre-defined), and a move to abstract the standard away from the underlying communications transport.

As ever, watch this space!

Hello everybody. This is a weekly summary of OpenSim development, taken mainly from the changelog entries that accompany each commit to our source code repository. The aim is to highlight new features and significant bugfixes - lower level detail such as code refactorings will, for the main part, be left uncovered. Remember that these changes are hot off the keyboard - there is no guarantee that they actually work 100% yet! Also, while I try to be even handed, it’s possible that the changes I’m familiar with will be the ones that tend to get the most detailed explanations.

Anyway, let’s get on with it. This week in OpenSim (r4108 - r4215)…

• Teravus implemented the AgentPause and AgentResume packets, with AgentPause extending the timeout for a client by 3x. I’m not sure exactly where these are used in the Linden client, possibly this means that using the set away option increases the amount of time your client can idle.
• Adam made various terrain engine fixes and introduced new terrain commands, including loaders for bmp, gif, png and tiff. Bug Adam for more details
• I made an initial rough implementation of direct avatar to avatar item transfer. In other words, the wonderful gift of giving has now come to OpenSim (by dragging an item in your inventory onto another avatar). Use at your own risk, though I haven’t heard of any problems yet. Many things are unimplemented as this stage, including permissions. Also, received items always end up in your root folder.
• I fixed an issue with rezzing items containing any inventory to the region under Windows. Thanks to various people for information on this, including thomas.
• Diva Canto and KMeisthax contributed a DataSnapshot module to OpenSim. If enabled (it is disabled by default), it will produce a summary of your sim at regular intervals and send the information to a data service. This is being used by Diva and KMeisthax to implement an experimental OpenSim search capability which can be queried here by selecting the OpenSims dropdown. I’m not sure how well this is working yet - more details can be found on a post in the OpenSim mailing list. Though a Metaverse Ink url appears in the OpenSim.ini.example configuration file, the module is a generic one that any organization can make use of - it is not intended to be tightly linked to Metaverse Ink.
• I made a small fix which means that items that have their name or description changed while in your inventory should retain those details when they are rezzed to a scene.
• Teravus added some primitive support for ellipsis, including strechable ellipsoid support. In other words, you can now stretch spheres into oblong shapes and watch them roll around like a football would (when using the included Open Dynamics physics engine).
• Teravus added twist support for cubes, cylinders and prisms.
• Following a change suggested by A_Biondi, I believe the Linden client is now caching OpenSim folders, as it does for the Linden server. This is better in the long run, but it does mean that if you have inventory issues, you may want to clear your cache before logging back in.
• A patch from Michael Osias implemented llDetectedKey for the touch_start event.
• Teravus enhanced the BetaGridLikeMoneyModule to allow ‘charging’ for uploads in order that these can be limited. Please note that this is not an actual grid wide money module.
• A patch from Lulurun means we now support the secondlife client’s -url sim/x/y/z option.
• Teravus fixed a bug which was causing the sim restart option (both from the region console and the estate tools) to fail.
• Teravus added a little more support for the friends module, such that you will now be notified when someone comes online if they come on in sims neighbouring the one you are in. A proper grid wide implementation is waiting on more grid comms maturity.
• A patch from Kurt Taylor fixed a bug in llDetectedName() and llDetectedKey(). See this mantis 821 for more details.
• A patch from Dr Scofield added supported for saving dynamically generated regions to the filesystem.

There’s been a huge amount of interest in OpenSim recently, ranging from organizations using it to form prototype grids, through to individuals looking to exploit it for educational purposes. For my own part, I love the idea of anybody being able to take our software and run their own grid for their own community.

However, amidst all the excitement, I think it’s important that we don’t forget that OpenSim is still alpha quality software, as stated on our frontpage. Lots of the features in the Linden client are not yet implented. Indeed, some may never be implemented, at least not by us - but that’s an entirely different blogpost. And sometimes features get broken in the course of development, which will always impact those using code taken directly from our Subversion repository.

In addition, some of the code is very much a first hack job to get certain functionality working. For my part, I very much like this iterative approach, but it does mean that OpenSim is currently inefficient and insecure in places. At some point, some of the code which is underneath our feet will need to be dug up and an entirely different set of plumbing buried, plumbing which is all the better for having been designed in light of our experience with more primitive algorithms.

At this point I could point towards the release versions. And they should generally be better, being effectively snapshots of the main line taken when the code seemed stable. However, because we don’t really do any quality assurance on these, they do contain bugs. For instance, 0.5.4 contains a bug where rezzing a prim to the environment will cause the rez to fail unless you’re using the OpenDynamicsEngine physics engine in OpenSim.ini.

So what am I saying? Well for me, this is really a request for patience If you’re following trunk, sometimes it will break. As OpenSim is alpha software, I would say we tend to favour taking risks to make fast progress over conservative code changes. And this is good, but the downside is that things will break a little more often. So please feel free to continue providing bugs reports (and filing patches!) but don’t forget that we need sometimes need time and space to pin down what’s going wrong. Let’s not try and get the toddler to run before it can really walk.

Viva la OpenSim!

– justincc

Hello. I’m one of the core committers on OpenSim, an effort to build a modular virtual worlds server, which is currently best known for supporting a Second Life environment. I’m going to use this blog to publish information about the things in OpenSim that I have a reasonable knowledge about. My posts will probably alternate between the chin-stroking and the technical variety, hopefully more towards the technical