LINDEN SCRIPTING LANGUAGE Kyle Stark February 17 2010

LINDEN SCRIPTING LANGUAGE Kyle Stark February 17, 2010

Table of Contents • Second Life and LSL • LSL Development Example • Language Design • Strided List • Implementation Basics • States • Communication • Security

Second Life and LSL • Second Life is a virtual world developed by Linden Lab • Almost entirely player-driven • Players (or “residents”) can create and alter the appearance and functionality of objects • Users retain copyright for their content • LSL is the scripting language used to add functionality to in-game objects

LSL Development Example

LSL – Language Design • Similar to C/Java in syntax and type system • Statements end in ; • Comments begin with // • Code blocks surrounded by { } • Strongly typed • Library has over 300 built-in functions, user can define more • All built-in functions begin with “ll” (standing for Linden Lab) • Has several common data types • Integers, floats, strings • Also has some less common types • Key (UUID), vector (tuple of 3 floats for coordinates), rotation (tuple of 4 floats for quaternion), heterogeneous lists • No arrays • Can be approximated using lists • Multidimensional arrays are implemented with “strided lists”

Strided List • Example w/ stride of 4: 1 Bob 3. 4 0 2 John 9. 7 1 • Approximates multidimensional array using one dimension • Several library functions work with strided lists • Can sort, randomize, convert

LSL – Implementation Basics • Although similar in appearance to C/Java, very different type of language – not object-oriented • State and event driven • Works as a finite state machine • Each script has states and a number of functions used to respond to events issued while in that state • System sends events to script (user interactions, sensors, timers, collisions, email) • Scripts are bound to objects in the Second Life world • Multiple scripts can be bound to each object and alter the state of the object • Scripts begin running immediately and execute simultaneously

LSL – States • LSL script acts as finite state machine • All scripts start in default state, and other states are user- defined and user-controlled in response to system events • States can be created, but events and event handlers cannot • E. g. , a user could create their own state “levitating_off_ground” but not their own event “levitation_requested” • State definition consists of the state keyword followed by the name of the new state and curly braces: state levitating_off_ground { } • Inside, one or more event handlers are defined • Changing states is as simple as • state levitating_off_ground;

LSL – Communication • LSL has support for communicating via email, XML-RPC, and HTTP requests • Some actions have mandatory delays • Email has 20 second delay • Purpose is to avoid unnecessary resource usage, either accidentally or maliciously • Allows LSL scripts to communicate with real-world servers and extend functionality of Second Life • Allows developers to connect Second Life to their business or app • Some examples are RPGs with persistent stats, banks

LSL – Security • Second Life has a complex user-driven economy and real estate system • USD and L$ can be exchanged, resulting in real-world profits from SL businesses and deals • Requires high built-in security • Because of this, LSL automatically requires permission for certain actions • Taking money, controlling the avatar, controlling avatar animations, etc.