Script Engine Component System (SECS)

What is a script engine?
Currently I see people define a script engine very simply as: The thing that runs the scripts.
This is a narrow definition that I never intended with DotNetEngine (see previous posts).

Instead I would say the script engine is the most important component of OpenSim. I am a humble person when it comes to my own doing and do not see DotNetEngine as anything more than a script executor. The greatness lies in the potential and what other people will make if we can offer them some good interfaces.

Instead of giving this complex explanation that required several of your neurons to connect I will use examples:

• Second Life LSL2 script support. Events and commands. Execution.
• OSSL script support. Other events and other commands. Execution.
• Additional command modules to for example give scripts SQL-access, Webservice acces, shared memory, etc.
• A plant module that grows grass/trees randomly around the region
• A bombterrain module that makes holes in the ground when bombs are detonated and fill them slowly back up over time.
• NPCs
• Bridges: Examples: “Contact us” module that allows sending of e-mail when someone drops a message in your region, IRC chat bridge, MSN chat bridge, etc.
• Complete game systems that allows a single system to control some or all aspect of the region/grid. Multiple modules can be loaded simultaneously to cover all aspects (one covers NPCs, others covers inventory stuff, swords, lazer guns, etc etc).

This was the original idea behind DotNetEngine, and the reason for the design of inheriting only what you need from the engine. I do not want OpenSim to be limited to in-world scripting only.

SECS
So how can we support all this?

Note! This is work in progress!

I imagine in the future we will want to download a good NPC module and install it independently of what script engine we are running. Lets face it, if each module had to be adapted to a certain script engine then it would put some heavy restrictions on us.

Instead I propose we redefine what a script engine actually is, and allow it to co-exist with other script engines. We may not want to run DotNetEngine and xengine simultaneously, but we may want to run a whole bunch of other “engines” (game control systems, AI-bots, etc) along with a script engine. And while these systems are running they should be able to benefit from the services the script engine already offers such as event hookups (into OpenSim) and the scheduler – IF they want.

To achieve this I have been looking at different models, all with their advantages and disadvantages. Though I have not landed at a perfect model yet I am closing in.

Basically it is a loader. It loads modules (.dll). The modules are registered in a central location with a name (string). Some of these modules will be of well-known base types (event hookups, schedulers, etc). Because they are well-known base types an alternate module should be able to utilize it even though it wasn’t made for that distinct type.

When a script engine is loaded it will create instances of whatever it needs to do its job. This is pretty much exactly how the script engines work today. The only exception is that we (probably) need to register the instances globally.

Any other modules that are started are now free to either instanciate what modules they need. Example of what they may load: OSSL commands, SQL commands. They can also access main script engine scheduler if they want to associate a custom class with a prim for example.

Note! This is work in progress!