Category:LSL

From Rosetta Code
Language
LSL
This programming language may be used to instruct a computer to perform a task.


Listed below are all of the tasks on Rosetta Code which have been solved using LSL.

LSL (Linden Scripting Language) is the scripting language developed by Linden Labs for their virtual sandbox world Second Life. Also OpenSimulator along with other Open Metaverse proprietors run a largely compatible superset version of LSL. LSL scripts allow objects rezzed in-world(in-game) to interact with and manipulate the virtual world around them, but also the internet in limited fashion. LSL has many built-in functions, and the ability for inter script messaging, http POST and GET requests, gui dialog boxes, chat channel messaging, java & C like semantics, is turning complete, etc.

In Depth: Syntax Structure

LSL is C-like with scoping of local varaibles and global; strict typing with type-recasting possible; use of {} to encapsulate function blocks, and ; to denote an execution block, and () to encapsulate parameters, and equivalency from right to left and for assignment myint=1-2, variables can be formed as procedures that return a value. Oprands are the same, but there are no pointers nor triple oprands such as +++. LSL is not like C in many ways, there are only 3 basic types, and 4 special types of data structures: integer (unsigned 32bit), float (unsigned 32bit), string (max string length varies), key ( a 32bit base16 UUID often treated as a string),vectors (set of three floats, aka a tuple <0.0,0.0,0.0> ); quaternions or rot ( set of four floats <0.0,0.0,0.0,0.0> ); lists (1D array that can contain any of or a mix of types of data), There is no void as a type! Nor is there any keyword for functions. Simply outside of a script's default loop function called a state, one forms a function with it's name(type prams){;} and can be called anywhere else. Over-loading is not valid, nor is under-loading when calling a function or variable-function that returns a value.

In Depth: Where & when LSL scripts can run

Rezzing is dragging and dropping from the user's inventory into to the virtual world space, or being worn as attachments to one's avatar (including HUDs). These aforementioned objects take the form of built-in 3d models of basic shapes commonly known as primitives or just prims, sculpted prims, and user uploaded 3D models. Each object has in-turn it's own inventory where the scripts run. In truth one can link many objects into a meta-object known as a link-set, each linked object retains it's own inventory instance, and running scripts. When an object is derezzed, that is brought back into the user's inventory, or an attached object derezzes when the user logs off the scripts' current status is paused and saved.

In Depth: LSL basic script structure

Each script must contain a default script state, this is very similar to the default loop found with in Arduino Clike programming. It is possible to switch the currently running state of a script to a knew one, and back again, thus ignoring/clearing any callback functions called "events". (However the timer does not get cleared upon state changes). Each state in LSL scripts can have built in call-back functions known as "event types" which are triggered with interrupt like behavior from a cue that is filled by the current simulator or sim (a sim is world instance, generally a 256x256meter block, although some communication with adjacent sims maybe possible) the script is residing in. Most events are repeatable, but there are logically single fire events such as state_entry, on_rez, on_attach, on_deattach. Aforementioned user functions, variables,

Back-ends of LSL with in Second-Life

In Second-life, one can save & run scripts optionally for the two current back-ends that actually run the code over a server, each with their own pros and cons. LSO exists for backward compatibility. LSO saved scripts are interpreted at runtime by the server. LSO scripts take less initial script memory, they are limited to less available memory as well. In rare circumstances LSO may run faster than MONO. However LSO suffers from memory fragmentation slow downs with list connotation (there are some work around). LSO handles the jump to @location in unexpected ways. Mono saved scripts are compiled under Mono (the most recent) to byte-code ran by the server.

Most scripts will benefit from being set to MONO compilation for greater speed and more available memory, at the cost of higher initial memory used.  

Flavors of LSL

  1. A largely compatible version of LSL that can run in the [[1]] virtual world.

Documentation

There are two popular web sites documenting LSL

  1. Second Life's own LSL Portal
  2. a user supported LSL Wiki

Libraries of Scripts

There exists several open source libraries where users share code

External Editors

There are also many external editors for LSL allowing you to write with highlighting, api tool-tips, syntax check, and (to a limited extent) compile and execute LSL outside of the Second Life environment.

You will need to sign up at Second Life and have a Second Life account to execute LSL in the virtual world. Your scripts can exist by themselves in a folder of your inventory, or in an Object in your inventory, but need to be in an Object that is in-world to execute (if an Object containing scripts is taken in to your inventory, the scripts will be suspended and will resume when brought out in to the world again.)