Expanded Scripting Engines

The views expressed below are not necessarily those of the Open Metaverse Research Group, but are the author's alone.

Description

Second Life and Open Simulator operate their own unique scripting language compared to other game and virtual world platforms that tend to use more common languages like LUA, Java, JavaScript, C#, among others. LSL has some similarity to C# and Java in many respects, but has quite a few custom functions that are prefixed by the lower case letters 'll' such as llSay(0,string); Similarly, Open Simulator, as it is an open sourced platform using a common viewer with SL, can use all LSL functionality, but has additional OSSL function that give greater flexibility to OpenSim users.

Competing Script Engines in Open Sim

Older versions of OpenSim use the X-Engine script engine up until OS 0.9.x. Subsequent versions use the newer Y-Engine, but there are a number of operational bugs that have caused more cautious grid operators to stick with the older X-Engine, largely revolving around ludicrously stringent syntax rule changes that did not improve the functionality of scripts but made a lot of older scripts exhibit bugs. The additional problem is if you create a script on an X-Engine grid, travel with the script to a Y-Engine grid, recompile the script to function on the Y-Engine grid, the origional X-Engine grid will lose all record of the script and destroy the functionality of the scripted object entirely.

It needs to be set as a standard that all grids on the hypergrid must provide compatibility with all scripting engines available in Open Simulator.

The Threat Rating Problem

OSSL functions all have a unique limitation on them in that they all have "threat ratings" because the OS Devs believed that it was responsible to limit the utilization of certain functions to grid owners, region/estate owners, or estate managers because of a perceived potential of those functions to be utilized for "griefing" a grid or region with them.

The problem with applying such ratings is that the functions that are usually limited by these ratings are no more dangerous than a wide variety of functions that are freely available as normal LSL functions which do not carry such ratings. So it is largely a matter of closing the barn door after the horse has escaped, had kids and grandkids. Therefore eradicating these threat ratings for all users other than those specifically related to grid or region management should be a priority. NPC tools, dynamic textures, among a number of other functions should not have threat ratings on them.

Enabling Other Languages

Having an open metaverse where content is portable across a number of virtual platforms is paramount both for content owners to enjoy full use of the content they paid for or created, and for content creators to enjoy the maximum marketability of their content across the Metaverse. For this reason, enabling common rather than proprietary scripting languages should be a priority. There should also be an effort made to create functions for many languages that have equivalency to specific functions in proprietary systems like LSL so that utilities to port scripts along with content is easy to accomplish while preserving creator IP rights.

Additional Functionality

While we pursue these goals we will also propose here a number of new functions for the Open Simulator platform as OSSL functions as function standards that can also be implemented into other platforms. We also believe that we should create a whole range of OSSL functions to replace all LSL functions so that the LSL standards are no longer required to be complied with, which limit the utility of scripting in OpenSim.

Proposed OSSL Functions

Sound

osMIDIPlay(list NoteSequenceList, float volume);

osLinkMIDIPlay(integer link1, list NoteSequenceList1, float volume1, integer link2, ...);

osGetLinkMIDIBPM(integer link);

Objects

data type "heirarchy" = declares the structure of a linkset armature from a list. such as [Link1,Link2a,Link3a,Link4a,Link1,Link2b,Link3b,Link4b]

osSetLinkHeirarchy(list heirarchy);