Difference between revisions of "SLua Alpha"

From Second Life Wiki
Jump to navigation Jump to search
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Warning|This functionality is in alpha. Instability is to be expected, and there may be very sharp edges. At this point it is expected that Luau can crash regions and perform other types of undesirable behavior.}}
{{Warning|This functionality is in alpha. Instability is to be expected, and there may be very sharp edges. At this point it is expected that Luau can crash regions and perform other types of undesirable behavior.


= Second Life Luau Alpha =
'''🚨 PLEASE NOTE Memory and performance characteristics, and API specifics may change! Scripts are currently being run in unoptimized form for development purposes.'''}}
 
= Second Life Lua (SLua) Alpha =


[[File:Luau.png|720px|thumb|right|Luau logo]]
[[File:Luau.png|720px|thumb|right|Luau logo]]


We're thrilled to announce the launch of the Luau Alpha for Second Life! This significant update introduces the Luau scripting language, offering creators enhanced performance, improved memory efficiency, and a more versatile scripting environment.
We're thrilled to announce the launch of the SLua Alpha for Second Life! This significant update introduces the Lua scripting language, offering creators enhanced performance, improved memory efficiency, and a more versatile scripting environment.


== What is Luau? ==
== What is SLua? ==


Luau is a fast, small, safe, and gradually typed embeddable scripting language derived from Lua. It is designed to be backwards compatible with Lua 5.1, incorporating features from future Lua releases and expanding the feature set with type annotations and a state-of-the-art type inference system. Luau is largely implemented from scratch, with the language runtime being a heavily modified version of the Lua 5.1 runtime, featuring a completely rewritten interpreter and other performance innovations.
SLua is scripting for Second Life based on Luau, a fast, small, safe, and gradually typed embeddable scripting language derived from Lua. It is designed to be backwards compatible with Lua 5.1, incorporating features from future Lua releases and expanding the feature set with type annotations and a state-of-the-art type inference system. Luau is largely implemented from scratch, with the language runtime being a heavily modified version of the Lua 5.1 runtime, featuring a completely rewritten interpreter and other performance innovations.


== Why Luau? ==
== Why Lua? ==


The decision to integrate Luau into Second Life was driven by its ability to meet all the requirements for a scripting engine within the platform. Luau offers a high-quality scripting experience to creators, addressing many of the limitations present in the current LSL (Linden Scripting Language) environment. Its lightweight nature and performance optimizations make it an ideal choice for enhancing the scripting capabilities in Second Life. For more information on why Luau was chosen, please see the [https://wiki.secondlife.com/wiki/Lua_FAQ Lua FAQ].
The decision to integrate Lua into Second Life was driven by its ability to meet all the requirements for a scripting engine within the platform. Lua offers a high-quality scripting experience to creators, addressing many of the limitations present in the current LSL (Linden Scripting Language) environment. Its lightweight nature and performance optimizations make it an ideal choice for enhancing the scripting capabilities in Second Life. For more information on why Lua was chosen, please see the [https://wiki.secondlife.com/wiki/Lua_FAQ Lua FAQ].


== How to Get Started with Luau in Second Life ==
== How to Get Started with SLua ==


In order to play with Luau, you'll need to download our Lua project viewer, and log onto our [https://lindenlab.freshdesk.com/support/solutions/articles/31000156725-accessing-aditi Aditi beta grid].
In order to play with SLua, you'll need to download our Lua project viewer, and log onto our [https://lindenlab.freshdesk.com/support/solutions/articles/31000156725-accessing-aditi Aditi beta grid].


* Access the latest build of the Luau-enabled Second Life Viewer from [https://releasenotes.secondlife.com/viewer/7.1.12.13526902562.html here].
* Access the latest build of the SLua-enabled Second Life Viewer from [https://releasenotes.secondlife.com/viewer/7.1.12.13526902562.html here].


Once you've got the new viewer and have logged onto the beta grid, head over to these Luau-enabled regions:
Once you've got the new viewer and have logged onto the beta grid, head over to these SLua-enabled regions:


* [secondlife://Aditi/secondlife/Luau%20Yardang/241/235/27 Luau Yardang]
* [secondlife://Aditi/secondlife/SLua%20Yardang/241/235/27 SLua Yardang]
* [secondlife://Aditi/secondlife/Luau%20Tombolo/241/235/27 Luau Tombolo]
* [secondlife://Aditi/secondlife/SLua%20Tombolo/241/235/27 SLua Tombolo]
* [secondlife://Aditi/secondlife/Luau%20Mesa/241/235/27 Luau Mesa]
* [secondlife://Aditi/secondlife/SLua%20Mesa/241/235/27 SLua Mesa]
* [secondlife://Aditi/secondlife/Luau%20Tideland/241/235/27 Luau Tideland]
* [secondlife://Aditi/secondlife/SLua%20Tideland/241/235/27 SLua Tideland]


When editing a script in the new Lua project viewer, you'll notice a new '''Compiler''' drop-down near the save button. This drop-down will allow you to select which compiler will be used, as well as which script runtime will be used (LSO2, Mono, Luau).
When editing a script in the new Lua project viewer, you'll notice a new '''Compiler''' drop-down near the save button. This drop-down will allow you to select which compiler will be used, as well as which script runtime will be used (LSO2, Mono, Luau).
Line 36: Line 38:
* '''LSL: Legacy (LSO2)''' - Scripts written in LSL, to be run on the old LSO2 VM
* '''LSL: Legacy (LSO2)''' - Scripts written in LSL, to be run on the old LSO2 VM
* '''LSL: Mono'''- Scripts written in LSL, to be run on the Mono VM
* '''LSL: Mono'''- Scripts written in LSL, to be run on the Mono VM
* '''Lua''' - Scripts written in Lua, to be run on the Luau VM
* '''Lua''' - Scripts written in Lua, to be run on the SLua VM
* '''LSL/Luau'''- Scripts written in LSL, to be run on the Luau VM
* '''LSL/Luau'''- Scripts written in LSL, to be run on the SLua VM


=== Transitioning from LSL to Luau ===
=== Transitioning from LSL to SLua ===
* '''Function Namespacing:'''
* '''Function Namespacing:'''
** In Luau, Linden Lab functions have been moved under the '''ll''' namespace.
** In SLua, Linden Lab functions have been moved under the '''ll''' namespace.
** For example:
** For example:
*** ''llSay'' becomes ''ll.Say''
*** ''llSay'' becomes ''ll.Say''
*** ''llGetPos'' becomes ''ll.GetPos''
*** ''llGetPos'' becomes ''ll.GetPos''
* '''Lists'''
* '''Lists'''
** Luau indexes begin from 1, unlike LSL where indexes begin from 0.
** Lua indexes begin from 1, unlike LSL where indexes begin from 0.
** Luau uses <code>{}</code> for ''tables'', unlike LSL where <code>[]</code> is used for ''lists''.
** Lua uses <code>{}</code> for ''tables'', unlike LSL where <code>[]</code> is used for ''lists''.
** When calling LL functions in Luau, lists often have type-strict requirements, unlike Luau in general.
** When calling LL functions in SLua, lists often have type-strict requirements, unlike Luau in general.
*** For example, <code>ll.SetPrimitiveParams({PRIM_GLOW, 0, 1})</code> will cause a type-error because <code>0</code> is a Luau <code>number</code> type, instead of the LSL <code>integer</code> type expected by [[llSetPrimitiveParams]]. For cases like this, there are special functions which provide the correct data types.
*** For example, <code>ll.SetPrimitiveParams({PRIM_GLOW, 0, 1})</code> will cause a type-error because <code>0</code> is a Luau <code>number</code> type, instead of the LSL <code>integer</code> type expected by [[llSetPrimitiveParams]]. For cases like this, there are special functions which provide the correct data types.
*** Correct: <code>ll.SetPrimitiveParams({PRIM_GLOW, integer(0), 1})</code>
*** Correct: <code>ll.SetPrimitiveParams({PRIM_GLOW, integer(0), 1})</code>
*** Similar functions exist for: '''integer''', '''uuid''' (key), '''vector''', '''quaternion''' (rotation)
*** Similar functions exist for: '''integer''', '''uuid''' (key), '''vector''', '''quaternion''' (rotation)


=== Luau Libraries ===
=== SLua Libraries ===
* '''Coroutines:'''
* '''Coroutines:'''
** Luau supports coroutines, allowing for cooperative multitasking within scripts.
** SLua supports coroutines, allowing for cooperative multitasking within scripts.
** Key functions include:
** Key functions include:
*** ''coroutine.create''
*** ''coroutine.create''
Line 62: Line 64:
** Refer to the [https://luau.org/library#coroutine-library coroutine library documentation] for more details.
** Refer to the [https://luau.org/library#coroutine-library coroutine library documentation] for more details.
* '''Bitwise Operations:'''
* '''Bitwise Operations:'''
** Luau includes a ''bit32'' library for bitwise operations, enabling more efficient data manipulation.
** SLua includes a ''bit32'' library for bitwise operations, enabling more efficient data manipulation.
** Refer to the [https://luau.org/library#bit32-library bit32 library documentation] for more details.
** Refer to the [https://luau.org/library#bit32-library bit32 library documentation] for more details.
* '''Standard Library:'''
* '''Standard Library:'''
** Luau comes equipped with a standard library of functions designed to manipulate built-in data types.
** SLua comes equipped with a standard library of functions designed to manipulate built-in data types.
** Explore the [https://luau.org/library Luau Standard Library] for a comprehensive list of available functions.
** Explore the [https://luau.org/library Luau Standard Library] for a comprehensive list of available functions.


== Feedback and Support ==
== Feedback and Support ==


We encourage all creators to explore the new Luau scripting capabilities and provide feedback. Your insights are invaluable in refining and enhancing this feature. For more information and to share your experiences, please refer to our [https://wiki.secondlife.com/wiki/Lua_FAQ Lua FAQ].
We encourage all creators to explore the new scripting capabilities and provide feedback. Your insights are invaluable in refining and enhancing this feature. For more information and to share your experiences, please refer to our [https://wiki.secondlife.com/wiki/Lua_FAQ Lua FAQ].


== Example Scripts ==
== Example Scripts ==


To help you get started, we've assembled some example scripts that demonstrate the capabilities of Luau in Second Life. These scripts cover various functionalities and can serve as a foundation for your own creations. Please feel free to propose changes to these scripts, or modify them to your heart's desire!
To help you get started, we've assembled some example scripts that demonstrate the capabilities of SLua. These scripts cover various functionalities and can serve as a foundation for your own creations. Please feel free to propose changes to these scripts, or modify them to your heart's desire!


=== default_script.lua ===
=== default_script.lua ===
This script is roughly equivalent to the "new script" that gets created.
This script is roughly equivalent to the default "new script" that gets created for LSL.
<source lang="lua">
<source lang="lua">
function state_entry()
function state_entry()
Line 154: Line 156:
</source>
</source>


=== dialog_coroutine.lua ===
=== user_input_coroutine.lua ===
This script demonstrates how one could use coroutines to handle dialog responses, with multi-user support.
This script demonstrates [https://www.lua.org/pil/9.html coroutines] and how they can simplify the overarching logic of a script, enabling us to write the bulk of our multi-event code within a centralized function instead of fragmenting across separate event handlers.
<source lang="lua">
<source lang="lua">
-------------------------
-- Wait for user input mid-function before doing something useful with it.
-- Minimal EventLoop
main = function(toucher)
-------------------------
    local handle = ll.Listen(0, "", toucher, "")
local EventLoop = {
    local event = touch_start  -- save function for later
     -- Coroutine -> eventName it’s waiting for
    touch_start = nil          -- disable touch_start
     _coros = {},
 
     running = false
    ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
}
    local clothing = coroutine.yield() -- pause the routine's execution here
     ll.RegionSayTo(toucher, 0, "For men or women?")
     local gender = coroutine.yield()
    ll.RegionSayTo(toucher, 0, "Favorite color?")
     local color = coroutine.yield()
    ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)


function EventLoop:create_task(func)
     ll.ListenRemove(handle)
     local coro = coroutine.create(func)
     touch_start = event -- restore touch_start
     self._coros[coro] = false
    self:_run_coro(coro)
    return coro
end
end


function EventLoop:kill_task(coro)
function touch_start(total_num)
     self._coros[coro] = nil
     local toucher = ll.DetectedKey(0)
     if coroutine.status(coro) ~= "dead" then
     routine = coroutine.create(main)   -- new coroutine
        coroutine.close(coro)
    coroutine.resume(routine, toucher)  -- run coroutine (with one argument)
    end
end
end


-- Internal helper: resumes a coroutine
-- When the coroutine is suspended, incoming events can be handled
function EventLoop:_run_coro(coro, ...)
-- and we can resume() execution of the routine
    if coroutine.status(coro) == "dead" then
-- and pass any number of arguments to be returned by yield()
        return
function listen(channel, name, id, message)
    end
     coroutine.resume(routine, message)
 
    local old_running = self.running
    self.running = true
 
     self._coros[coro] = false
    local ok, eventAwaited = coroutine.resume(coro, ...)
    self.running = old_running
 
    if not ok then
        ll.OwnerSay(`Coroutine error: {eventAwaited}`)
        self._coros[coro] = nil
        return
    end
 
    -- If still alive, 'eventAwaited' is the next event it wants
    self._coros[coro] = eventAwaited
end
end
</source>


function EventLoop:handle_event(eventName, ...)
=== multi_user_input_coroutine.lua ===
    ll.OwnerSay(`Handling event {eventName}`)
Following from the above example, how can we handle multiple users? This is where coroutines shine.
    local snapshot = table.clone(self._coros)
    for coro, waitingFor in pairs(snapshot) do
        if coroutine.status(coro) == "dead" then
            self._coros[coro] = nil
        elseif waitingFor == eventName then
            ll.OwnerSay(`Dispatching event {eventName} to {coro}`)
            self:_run_coro(coro, ...)
        end
    end
end


-- Coroutines use this to yield until an event
Instead of disabling touches to prevent others from interacting with the object, we can create new copies of the coroutine each time an avatar touches the object. We can then resume whichever coroutine is needed, based on the avatar, while all of them track their own progress separately and automagically.
local function await_event(name)
<source lang="lua">
    assert(EventLoop.running, "await_event called outside a coroutine!")
-- Key: avatar uuid; Value: coroutine thread
    return coroutine.yield(name)
routines = {}
end


-------------------------
main = function(toucher)
-- Script Logic
    local handle = ll.Listen(0, "", toucher, "")
-------------------------
local buttons = {"-", "Red", "Green", "Yellow"}
local dialogInfo = "\nPlease make a choice."


-- Use the chat listener to feed the event-loop
    ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
function listen(channel, name, sender_id, message)
    local clothing = coroutine.yield()
     -- We handle all 'listen' events via the event-loop
    ll.RegionSayTo(toucher, 0, "For men or women?")
     EventLoop:handle_event(`listen_{channel}`, channel, name, sender_id, message)
     local gender = coroutine.yield()
end
     ll.RegionSayTo(toucher, 0, "Favorite color?")
    local color = coroutine.yield()
    ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)


-- Called when the script starts
     ll.ListenRemove(handle)
function state_entry()
     routines[toucher] = nil -- Remove from collection
     -- Seed math.random so each new script run doesn’t repeat the same channels
    math.randomseed(ll.GetUnixTime())
     ll.OwnerSay("Script started with random channels for each user.")
end
end


-- A coroutine function for a single user's dialog flow
function touch_start(total_num)
local function handle_dialog_for_user(userId)
     local toucher = ll.DetectedKey(0)
    -- Use a random channel
     local routine = routines[toucher]
     local channel = math.random(0x1, 0xFFFF)
     if not routine then -- New user needs new routine
    -- Create a listener for that channel
         routine = coroutine.create(main)
     local listenHandle = ll.Listen(channel, "", "", "")
         routines[toucher] = routine -- Add to collection
 
         coroutine.resume(routine, toucher)
     while true do
        -- Show the user a dialog
         ll.Dialog(userId, dialogInfo, buttons, channel)
 
         -- Wait for the next 'listen' event (channel, name, sender_id, message)
        local c, n, sid, msg = await_event(`listen_{channel}`)
 
        -- If this "listen" event isn't for our channel/user, ignore it
         if c == channel and sid == userId then
            -- If user pressed "-", re-display the menu, else they picked a final color
            if msg ~= "-" then
                ll.Say(0, `{n} selected {msg}`)
                -- Now that they've chosen something else, remove the listener and finish
                ll.ListenRemove(listenHandle)
                return
            end
        end
     end
     end
end
end


-- Called when the object is touched
function listen(channel, name, id, message)
function touch_start(num_detected)
     coroutine.resume(routines[id], message) -- Resume a specific coroutine
     for i=0, num_detected-1 do
        local toucherId = ll.DetectedKey(i)
        -- Create a separate coroutine for each person who touches
        EventLoop:create_task(function()
            handle_dialog_for_user(toucherId)
        end)
    end
end
end
-- Run state_entry on load:
state_entry()
</source>
</source>



Latest revision as of 15:55, 13 March 2025

Warning!

This functionality is in alpha. Instability is to be expected, and there may be very sharp edges. At this point it is expected that Luau can crash regions and perform other types of undesirable behavior.

🚨 PLEASE NOTE Memory and performance characteristics, and API specifics may change! Scripts are currently being run in unoptimized form for development purposes.


Second Life Lua (SLua) Alpha

Luau logo

We're thrilled to announce the launch of the SLua Alpha for Second Life! This significant update introduces the Lua scripting language, offering creators enhanced performance, improved memory efficiency, and a more versatile scripting environment.

What is SLua?

SLua is scripting for Second Life based on Luau, a fast, small, safe, and gradually typed embeddable scripting language derived from Lua. It is designed to be backwards compatible with Lua 5.1, incorporating features from future Lua releases and expanding the feature set with type annotations and a state-of-the-art type inference system. Luau is largely implemented from scratch, with the language runtime being a heavily modified version of the Lua 5.1 runtime, featuring a completely rewritten interpreter and other performance innovations.

Why Lua?

The decision to integrate Lua into Second Life was driven by its ability to meet all the requirements for a scripting engine within the platform. Lua offers a high-quality scripting experience to creators, addressing many of the limitations present in the current LSL (Linden Scripting Language) environment. Its lightweight nature and performance optimizations make it an ideal choice for enhancing the scripting capabilities in Second Life. For more information on why Lua was chosen, please see the Lua FAQ.

How to Get Started with SLua

In order to play with SLua, you'll need to download our Lua project viewer, and log onto our Aditi beta grid.

  • Access the latest build of the SLua-enabled Second Life Viewer from here.

Once you've got the new viewer and have logged onto the beta grid, head over to these SLua-enabled regions:

When editing a script in the new Lua project viewer, you'll notice a new Compiler drop-down near the save button. This drop-down will allow you to select which compiler will be used, as well as which script runtime will be used (LSO2, Mono, Luau).

Compiler selection dropdown

Compiler drop-down options:

  • LSL: Legacy (LSO2) - Scripts written in LSL, to be run on the old LSO2 VM
  • LSL: Mono- Scripts written in LSL, to be run on the Mono VM
  • Lua - Scripts written in Lua, to be run on the SLua VM
  • LSL/Luau- Scripts written in LSL, to be run on the SLua VM

Transitioning from LSL to SLua

  • Function Namespacing:
    • In SLua, Linden Lab functions have been moved under the ll namespace.
    • For example:
      • llSay becomes ll.Say
      • llGetPos becomes ll.GetPos
  • Lists
    • Lua indexes begin from 1, unlike LSL where indexes begin from 0.
    • Lua uses {} for tables, unlike LSL where [] is used for lists.
    • When calling LL functions in SLua, lists often have type-strict requirements, unlike Luau in general.
      • For example, ll.SetPrimitiveParams({PRIM_GLOW, 0, 1}) will cause a type-error because 0 is a Luau number type, instead of the LSL integer type expected by llSetPrimitiveParams. For cases like this, there are special functions which provide the correct data types.
      • Correct: ll.SetPrimitiveParams({PRIM_GLOW, integer(0), 1})
      • Similar functions exist for: integer, uuid (key), vector, quaternion (rotation)

SLua Libraries

  • Coroutines:
    • SLua supports coroutines, allowing for cooperative multitasking within scripts.
    • Key functions include:
      • coroutine.create
      • coroutine.status
      • coroutine.resume
    • Refer to the coroutine library documentation for more details.
  • Bitwise Operations:
    • SLua includes a bit32 library for bitwise operations, enabling more efficient data manipulation.
    • Refer to the bit32 library documentation for more details.
  • Standard Library:
    • SLua comes equipped with a standard library of functions designed to manipulate built-in data types.
    • Explore the Luau Standard Library for a comprehensive list of available functions.

Feedback and Support

We encourage all creators to explore the new scripting capabilities and provide feedback. Your insights are invaluable in refining and enhancing this feature. For more information and to share your experiences, please refer to our Lua FAQ.

Example Scripts

To help you get started, we've assembled some example scripts that demonstrate the capabilities of SLua. These scripts cover various functionalities and can serve as a foundation for your own creations. Please feel free to propose changes to these scripts, or modify them to your heart's desire!

default_script.lua

This script is roughly equivalent to the default "new script" that gets created for LSL.

function state_entry()
    ll.Say(0, "Hello, Avatar!")
end

-- Called when the object is touched.
function touch_start(total_number)
   ll.Say(0, "Touched.")
end

-- Invoke state_entry on startup, since simulator doesn't invoke 
-- it like it does in LSL
state_entry()

dialog.lua

This script demonstrates how one can interact with dialog menus.

-- Define the menu buttons and dialog message.
local buttons = {"-", "Red", "Green", "Yellow"}
local dialogInfo = "\nPlease make a choice."

local ToucherID = nil
local dialogChannel = nil
local listenHandle = nil

-- This function is called when the script first starts.
function state_entry()
    -- Get the object's key and compute a dialog channel number.
    local key = ll.GetKey()
    -- Extract the last 7 characters of the key and convert it from hex.
    dialogChannel = -1 - tonumber(string.sub(tostring(key), -7, -1), 16)
end

-- Called when the object is touched.
function touch_start(num_detected)
    ToucherID = ll.DetectedKey(0)
    -- If there is already a listen handle, then remove it
    if listenHandle then
        ll.ListenRemove(listenHandle)
    end
    listenHandle = ll.Listen(dialogChannel, "", ToucherID, "")
    ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
    -- Set a 60-second timer for response.
    ll.SetTimerEvent(60.0)
end

-- Called when a dialog response is received.
function listen(channel, name, sender_id, message)
    if message == "-" then
        -- Redisplay the dialog if the "-" option is selected.
        ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
        return
    end
    -- Stop the timer, and stop the listening handler.
    ll.ListenRemove(listenHandle)
    ll.SetTimerEvent(0)
    -- Let the user know what they selected
    ll.Say(0, `You selected {message}`)
end

-- Called when the timer expires.
function timer()
    -- Stop the timer and clean up the listener.
    if listenHandle then
        ll.SetTimerEvent(0)
        ll.ListenRemove(listenHandle)
        ll.Whisper(0, "Sorry. You snooze; you lose.")
    end
end

-- Invoke state_entry on startup, since simulator doesn't invoke 
-- it like it does in LSL
state_entry()

user_input_coroutine.lua

This script demonstrates coroutines and how they can simplify the overarching logic of a script, enabling us to write the bulk of our multi-event code within a centralized function instead of fragmenting across separate event handlers.

-- Wait for user input mid-function before doing something useful with it.
main = function(toucher)
    local handle = ll.Listen(0, "", toucher, "")
    local event = touch_start   -- save function for later
    touch_start = nil           -- disable touch_start

    ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
    local clothing = coroutine.yield() -- pause the routine's execution here
    ll.RegionSayTo(toucher, 0, "For men or women?")
    local gender = coroutine.yield()
    ll.RegionSayTo(toucher, 0, "Favorite color?")
    local color = coroutine.yield()
    ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

    ll.ListenRemove(handle)
    touch_start = event -- restore touch_start
end

function touch_start(total_num)
    local toucher = ll.DetectedKey(0)
    routine = coroutine.create(main)    -- new coroutine
    coroutine.resume(routine, toucher)  -- run coroutine (with one argument)
end

-- When the coroutine is suspended, incoming events can be handled
-- and we can resume() execution of the routine
-- and pass any number of arguments to be returned by yield()
function listen(channel, name, id, message)
    coroutine.resume(routine, message)
end

multi_user_input_coroutine.lua

Following from the above example, how can we handle multiple users? This is where coroutines shine.

Instead of disabling touches to prevent others from interacting with the object, we can create new copies of the coroutine each time an avatar touches the object. We can then resume whichever coroutine is needed, based on the avatar, while all of them track their own progress separately and automagically.

-- Key: avatar uuid; Value: coroutine thread
routines = {}

main = function(toucher)
    local handle = ll.Listen(0, "", toucher, "")

    ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
    local clothing = coroutine.yield()
    ll.RegionSayTo(toucher, 0, "For men or women?")
    local gender = coroutine.yield()
    ll.RegionSayTo(toucher, 0, "Favorite color?")
    local color = coroutine.yield()
    ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

    ll.ListenRemove(handle)
    routines[toucher] = nil -- Remove from collection
end

function touch_start(total_num)
    local toucher = ll.DetectedKey(0)
    local routine = routines[toucher]
    if not routine then -- New user needs new routine
        routine = coroutine.create(main)
        routines[toucher] = routine -- Add to collection
        coroutine.resume(routine, toucher)
    end
end

function listen(channel, name, id, message)
    coroutine.resume(routines[id], message) -- Resume a specific coroutine
end

More Examples