Objectifying LSL

A few months ago we decided to make a distinction between SL's LSL2 and our own LSL implementation. This mainly because we were planning to add new features to the language. But also to make people understand that the compatibility may not be 100% - at least not for some time into the future. One thing is implementing all ll-commands. Another is to get them all right. So we decided to call our language OSSL (OpenSim Scripting Language.)

Yesterday OSSL took a new turn. In addition to LSL2's straight forward function calls and our own similar os-calls I want to provide a modular aproach.

So now OSSL has a new object "Prim" that can be used in the following ways:
Prim.Position.x += 10;
Prim.Rotation.x += 45;
Prim.Text = "This text floats on top of a prim!";

I'm planning to implement more functions. Especially looking forward to getting for example the particle-system into objectified managed code.

Later down the road people can use Visual Studio to write scripts for OpenSim. If they include some OSSL.dll they will get the benefits of managed code and writing scripts should be a breeze.

So, here is a sample script:

//c#

double x = 0;
double y = 0;

public
void default_event_state_entry()
{
llSetTimerEvent(0.1);
}

public void default_event_timer() {
x += 0.2;
y += 0.1;

Prim.Position.x = System.Math.Sin(x) * 10 + 100;
Prim.Position.y = System.Math.Cos(y) * 10 + 100;
}

New languages

DotNetEngine has received a couple of new languages: VB.Net and JScript.
Just add //vb or //js as the first characters of your script. Examples here: http://opensimulator.org/wiki/OpenSim:Scripting_Languages

LSL support has also been improved to support states and also a minor patch for functions inside . It seems like LSL is starting to run ok now.

New common framework

I have moved most of the code from OpenSim.Region.ScriptEngine.DotNetEngine to OpenSim.Region.ScriptEngine.Common.

Right now we have only one ScriptEngine, and its purpose is to emulate a Second Life script engine by executing scripts put into prims. But in the future I expect different kinds of script engines such as controllers that manipulate in-world game rules or objects from a .dll that has nothing to do with prim scripts.

Therefore I moved parts of DotNetEngine into Common so that Common is an execution framework.

DotNetEngine now does LSL->C# convert and compile. But does not do anything else. It simply hands the compiled .dll back to Common when its done. Then Common does the actual execution of script.

To quote http://opensimulator.org/wiki/OpenSim.Region.ScriptEngine.Common

What do I get for free?
1. Loading/unloading of scripts are queued and executed in sequence. Only one load/unload at the time.

2. What script belongs to what object is automatically taken care of. You just need to provide the scripts classes - nothing else.

3. OpenSim events are translated and given to you as LSL events. Your script functions are executed automatically, no need to hook up to events or anything.If you want to implement your own event handlers, feel free to do so. Look in "OpenSim.Region.ScriptEngine.Common.ScriptEngineBase.EventManager.cs" how its done. Your own events can run together with LSL events without any problem.

4. Whenever an event is executed, the execution is queued. Only one event per script is ever executed simultaneous. But multithreading is used to run multiple scripts in parallel.

5. Errors during script execution is automatically handled and relayed to users in-world.

6. You get all LSL commands in an easy to use object, no need to keep track of scene or objects to execute functions. Running an LSL command from your script engine is as easy as running it from inside any LSL-script.

7. Long LSL-commands that returns with an event is also handled.

ScriptEngine with many regions per server

I have added a whole lot of detailed config options in OpenSim.ini.example that can be used to control DotNetEngine. Many of these are specific to Common, some are specific to DotNetEngine.

You can now control a lot of detailed stuff that you usually wouldn't care about. The reason why these options are there now is because 1) Common will be sharing resources across different script engines (so we can support large amounts of script engines) and 2) who knows what you will be using OpenSim for.

One of the most important new features is the capability of Common to share maintenance, load/unload and execution threads accross instances (read: regions). Today a new instance of ScriptEngine is created for each region. And with 3-4 threads per ScriptEngine ... I guess this is a severe limit to large scale use of OpenSim.

Note! The thread sharing is currently disabled due to some bugs that needs fixing.

ScriptServer

ScriptServer is "almost done". Meaning it is capable of doing everything except communicating from a script to OpenSim. For this I need to abstract the layer between llFunction() and the actual implementation. Which already is in part done.
However ScriptServer has not been a priority lately.

For those who dont know the difference: ScriptEngine is a .dll that OpenSim uses to run scripts. ScriptServer is 1) a ScriptEngine .dll, but instead of executing scripts it remotely communicated with a 2) ScriptServer that uses the same ScriptEngine .dll's as OpenSim to execute scripts.
The advantage of this is that the script execution can happen on a remote machine (or same machine if you want) outside of OpenSim.exe.

Idling

I guess its that time of year again when I write my blog post...

It's been a while... :) I've been busy with RL work. Sadly that work doesn't involve OpenSim just yet. But now I'm back and I thought I'd put some words here.

I've picket up where I left off on ScriptServer. Not so much to report yet. TCP server/client implementation is ready, binary protocol and bindings are not. Server executable is ready, plugin module is ready. So what remains is mainly binary protocol and binding implementations.

Depending on how much free time I have this shouldn't take too long.

Script engine implementation

I just wrote this contribution to AWG: http://wiki.secondlife.com/wiki/Tedds_stand-alone_script_engine

It explains how and why on my opinions on the future script engine implementation.

Communication

Things are a bit quiet right now. But there are things happening behind the scenes.

Some notes on communication between region and script engine.

Region will be the initiator. That is, the one that contacts script server. If an object containing a script moves from one region to another then the next region will contact the script server.

The communication protocol will be a custom binary protocol. As far as I know there are no RPC protocol designed for high volume async function calls. This will allow a continous stream of function calls in both directions. Any reply on commands will be done by attaching an reply ID to the function call package, a reply package refering this ID containing reply data will be sent back.

Scripts will be blocked while waiting for reply, but not while waiting for their command to be sent.

Currently TCP client/server has been created, but the binary protocol is still in design stage.

A peek on new architecture

This is where my planning is at now.
It was very complex, and after redrawing it a few times I neded up at this.
Still not 100%, but getting there...

Major rewrite number 2

I have been doing some thinking on the ScriptEngine. Actually a whole lot of thinking, and planning. Lots of alien squid-like drawings in my notebook.

Trying to run through the process: Idea, required elements, architecture and finally simplification.

The idea is simply: Moving ScriptEngine to a separate daemon, independent from the region.
This has several big advantages and of course some drawbacks.

• Script does not need to be moved between regions when object it is inside does.
• Scripts can run on separate servers and even clusters of servers, offloading the main region server.
• Script source (and binary) can be secured by running it from a trusted server. Even makes it possible with script rental. You can run your own ScriptEngine.
• We can add the option to move script between regions as usual to avoid network lag on time-critical scripts.
• It is easier to write alternative ScriptEngines, developers are not restricted to .Net.
• ScriptEngines can be more complex and allow bigger and more complex scripts than the region would by default.
• Regions can be more secure as they do not have to execute scripts locally.

Disadvantage:

• Each region may have to speak to many different scriptengines.
• Network latency will affect script performance.
• Script reliability is much lower.
• Various problems related to authentication.

Of course all the work done with implementing LSL commands so far will survive. That is independent of this rewrite.

I'll be back with more as it unfolds.