Adam Frisby

MRM Scripting ? Coming to OpenSim soon!

with 6 comments

Scripting OpenSim right now is a chore for the seasoned developer – there’s very few options sitting between ‘write a plugin’, and the LSL/OSSL implementation currently in place. For reasons I wont go into too much detail here, LSL is badly designed – the API in particular places too much emphasis on restricting the programmer rather than empowering them.

While Region Modules are exceptionally powerful, and quite capable of doing all that LSL can (and lots more), they require the programmer shut down the sim and restart it between tests of the module, resulting in a significant loss of productivity. MRM Scripting aims to fix this – MRM is short for ‘Mini Region Module’, and is something I have been adding silently to the OpenSim SVN for the last month. The goal is a very clean documented API similar to a full region module, but includes the ability to add in security features and also compile and edit the modules without shutting down the sim.

MRM Modules are written in C# (like OpenSim itself), but unlike the currently implemented C# engine, contain a vastly different more object-oriented API. It’s probably best illustrated with a couple of examples – below is the obligatory ‘Hello World’ as a MRM module.

Hello World in MRM

As you can see, the entrypoints to an application are the Start() and Stop() events. Unlike LSL/OSSL, you wont recieve an ‘event’ automatically just by declaring the function. Like conventional OpenSimulator region modules, you need to explicitly declare which events you want to listen to via standard C# event syntax

The result is fairly clean – the script engine only needs to give you information that you request, rather than send the event at runtime, only to have it ignored. It also gives you the ability to selectively listen only when you want (by binding and unbinding on demand.). The largest reason for this however, is because of scope – MRM has a much wider scope than LSL/OSSL.

Where on the Toolchain?

MRM’s fill a niche in the tool chain between end-user scripting and region modules, while we can secure MRMs (and plan on doing so), they are designed for ‘World Builders’ who want reasonable amounts of power, and know the repercussions for abusing it (ie, lag, etc). They fit somewhere between OSSL and Region Modules – sharing many of the advantages of both.

To summarise this in a somewhat incomplete table of features, the scope of a MRM can be seen below

The Scope of the Script

Under LSL, your scope is limited to the Primitive the script is hosted in, with some very limited exceptions to say objects in the same link set. There is absolutely no ability whatsoever to listen for events affecting another object, unless that object also contains a script which can communicate with yours. MRM by comparison lives somewhere in the ‘World’, and consequently contains a much wider ‘Scope’. This means, if you want to listen to the touch event on any object in the world, it is quite possible to do.

The above example demonstrates some of the power of the MRM API, the LSL equivilent would require a script in every single one of the objects in the region.

Hosted Scripts

The final point worth noting is that MRM can act as a complete replacement for LSL – a script which for example changes the color of the object it is located in, can be implemented via the Host. Host contains a member called ‘Object’, which dictates the object that the MRM Script resides in. Host.Object conforms to the same IObject interface as World.Objects[], so any function can be done on both the host and remote objects.

Final Notes, Enabling, Security, etc.

The MRM API is presently incomplete, the largest sections currently undesigned relate to events and callbacks. The currently implemented versions (SOPObject.cs, World.cs, etc) are missing functionality, but you can still do some reasonably nifty things with it. Just dont expect this to be a fully ready replacement until we’ve implemented all the members correctly. It’s also worth noting that any MRM compile errors will disconnect your client from the sim, this is a bug and will be fixed. The API however should be 100% capable of wrapping LSL/OSSL functionality – infact it should be possible to write a LSL2MRM cross-compiler (Part of this comes from my discussions with Jim Purbrick about distilling LSL to a simple set of interfaces).

MRM can be enabled via the [MRM] section of the OpenSim.ini, however it is strongly recommended that you be wary with this on a public environment. Presently any MRM script has access to the complete .NET API, this means it would be possible to compile a script calling for your server disk to be formatted. I recommend using this in offline standalone regions only for the moment. Proper security is part of the design, however is currently unimplemented. There is also a few functions which are implemented badly and may cause lag if used repeatably, all on the agenda for being fixed before we hit a beta version.

5 Vote

Feedback

If you found this post useful and want me to write more on this topic, please use the vote button to the left or leave me a comment below.

Written by Adam Frisby

March 13th, 2009 at 8:57 am

Posted in OpenSim

Tagged with , ,

6 Responses to 'MRM Scripting – Coming to OpenSim soon!'

Subscribe to comments with RSS or TrackBack to 'MRM Scripting – Coming to OpenSim soon!'.

  1. [...] MRM Scripting – Coming to OpenSim soon! Adam Frisby Mar.13, 2009 in OpenSim, realXtend (cross-posted fromĀ Adam Frisby’s blog) [...]

  2. This is definitely a gap filler!

    Tony

    14 Mar 09 at 2:56 pm

  3. Adam,
    I’m surprised that you didn’t include server-side scripting languages like RexPython in your taxonomy. The scope of these scripts is the world, and the granularity is determined by the richness of the object model. RexPython has object models for the world, avatar, actors and events. It’s more powerful than a region module, yet as easy to write as an LSL script. As presently implemented it does not require a restart of the simulator but requires a restart of the Python interpreter when scripts are changed. It would be feasible to unload and reload scripts in the future.

    Peter Quirk

    21 Mar 09 at 3:48 pm

  4. Yeah, RexPython definetely sits somewhere in the middle too – it’s got a similar scope. I think where we differentiate ourselves is on a) security model, and b) the API.

    Adam Frisby

    28 Mar 09 at 2:17 am

  5. Adam,
    Have you published you MRM API? I am currently developing some scripts in second life to extract out information about avatar movements and what they do, but seems like the amount of information that we can take out is very limited. Using OpenSim with MRM scripting seems to give out more information (ex. all the detected avatars, more information of Avatars, etc). So would like to have a look at your API.Also, if you know the location of the OpenSim API, please let me know. Links they have given are not working anymore.

    su

    6 Sep 09 at 9:08 am

  6. API documentation is stored as XMLDocs within the DLL itself; so if you use Visual Studio or another IDE, you have full documentation as part of Intellisense. There was some documentation being generated by doxygen, but it got wiped out in some recent DNS changes.

    Adam Frisby

    8 Sep 09 at 10:53 am

Leave a Reply

 

You need to log in to vote

The blog owner requires users to be logged in to be able to vote for this post.

Alternatively, if you do not have an account yet you can create one here.

Powered by Vote It Up