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.

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!

2 thoughts on “Script Engine Component System (SECS)”

  1. Or when is a scripting engine not a scripting engine?I’m joking but I’m failing to see the logic here. A scripting engine is and always has been the “thing that interprets/compiles/executes scripts”.A module that in some way uses a scripting engine doesn’t make it in any way related to the script engine as an architecture.Also your explanation may make the concept overly complex for users and possibly developers. A script engine takes care of things directly related to running scripts.A “module” by nature is a separate concern that tackles a specific bit in its own right, regardless of what it ties into or doesn’t.If a rendering/physics/web/etc engine starts deviating too far from directly handling what it’s named after it becomes “something else”. And so it appears to me with this view of what a scripting engine is.

  2. And “What lies in a name”.Hi AnonymousA script is a script even if it is compiled. The point here is to allow modules that utilize API (events and commands) provided by script engine(s) to run. Though this “script” will be more advanced, written outside of the 3D world and possibly apply for more than one object, I still choose to call it a script.The second point is to allow modules to be added to further strengthen the script engine by providing new API, events, compilers, etc.With your comparison of web servers I can tell you that both Apache 2.0 and IIS 6 and 7 has an architecture that allows it to run any type of daemon by adding modules. It is not limited to only HTTP. We still call it a web server, because that is its primary purpose. Not that I feel the relation to this case is very strong.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: