Scripting Features

Please implement the equivalent of Python's re.escape() in LSL. This escapes regex metacharacters in a string. Repeatedly attempting this via a UDF consumes too much script timing. Thanks.

Second Life's interactive objects rely on LSL—a basic scripting language largely unchanged since 2003. This limits creators’ ability to build advanced, dynamic experiences. By introducing Lua, a powerful and widely adopted language, we can modernize scripting and unlock new creative possibilities. Broadens Second Life’s creator base to more easily include developers from Lua-heavy platforms (e.g., Roblox, Garry's Mod). Reinvigorates existing creators who’ve struggled with LSL’s limitations. Enables advanced features like mobile-focused development kits and robust 3D content manipulation (e.g., GLTF). Objectives New Audiences : Attract creators from popular Lua-based UGC platforms. Easier Scripting : Leverage Lua’s built-in features, large support community, and ample learning resources. Re-Engage Creators : Provide a smooth transition from LSL with bridging functionality, encouraging return visits. Advanced Features : Introduce long-requested language improvements (e.g., map-types, index operators). Richer Experiences : Allow for more complex, dynamic scripts to increase retention and drive engagement. Reduced Technical Debt : Replace LSL's difficult-to-maintain system with a modern, flexible alternative. Education Opportunities : Offer a full-featured language that helps new programmers build real-world skills. Links Lua FAQ - Read this if you have questions about "Why Lua?"

Add a new function LSL function named llRenderText or similar, which allows users to dynamically render text, with limited but flexible formatting, onto the face of their choosing. Concept: // Signature llRenderText(integer face, string text, list params); // Basic example llRenderText(ALL_FACES, "Lorem ipsum...", [ FONT_ALIGN, "right", FONT_WEIGHT, "bold", FONT_FAMILY, "sans serif" ]); Rationale Text is ubiquitous, yet Second Life has no way for users to display text other than uploading a texture, setting floating text using llSetText , or using relatively resource intensive solution such as XyText/Furware/et al. This absence precludes interesting features, such as being able to create a responsive interactive terminal in Second Life, HUDs with dynamic text, etc. A scripted and efficient text solution that displays on the face of a prim/mesh would give Second Life the biggest bang for the buck: Limited in scope (easier to implement than grand UI-creation ideas) Easy to kitbash into existing and new creations For inspiration, you can look to how the Text Display widget is implemented in the Playstation game Dreams. It has limited options: a finite number of fonts and formatting options, but the fact that it can be combined with other content makes it rather powerful. Other details Font color, opacity, glow, etc are controlled by prim properties (Example: setting face color to red sets font color to red) Questions Should the background always be transparent? Creators could put another prim behind the text display face to give it a background, or it could be a property of the render params. Possible Parameters FONT_WEIGHT FONT_STYLE FONT_FAMILY FONT_VERTICAL_ALIGN FONT_HORIZONTAL_ALIGN FONT_TEXT_WRAP FONT_LINE_HEIGHT FONT_SIZE Possible Features Markdown / rich text

Rationale We have sit targets to define where an avatar should sit on a linked object. But when standing up, it's always at that exact same position. This is awkward for things like vehicles where the user will unsit inside the vehicle instead of stepping out gracefully. This goes together with a possible unsit event as proposed here: https://feedback.secondlife.com/scripting-features/p/unsit-events Proposal Add a possibility to let us define the exact spot and rotation where the avatar will be positioned/moved to at the moment of unsitting.

Till now there is quite a long trick that makes it possible to set linked prims phantom. The other solution that has been proposed more recently by LL to use the not prim feature is unusable as it can impact LI count in a crazy way leading to a build returning to its owner inventory at best. So why not simply have a llSetLinkPrimPhantom(link number, boolean) ? PS: If it can motivate LL to add such a feature, simply look at how palms are set phantom on the great Aleymart products = it is a phantom script in each item needed to be phantom as the phantom linked prim trick is not permanent in case of link / unlink. At the end it easily makes tens of extra scripts that could have been avoided on each build. It also means that this features needs to work on the viewer edit window too.

I just lost a lot of time trying to find and fix a non-existent bug, adding debug functions and such in my script, until I finally noticed the "running" checkbox was unchecked (because of a previous compilation failure and save, probably). It would probably have saved me a lot of time if inactive scripts could be identified at a glance in the prim's inventory. My suggestion is to color them in yellow, orange, red or whatever!

I'm not sure why this is still not a thing, but for a long time, Second Life's data in scripts is like playing an RPG without a memory card, and no way to save. There's a lot of valuable information that is relegated to variables, where if something breaks and the script needs to be reset, or something needs to be moved and placing it down resets the script, all of that information is gone. Right now, the only other option is to set up an external data server to send and receive information from, and that's overkill. Implementing a way to store, edit, and erase data from a notecard within an object would grant us the following at the least: Dynamic data storage: Scripts could save and update information without requiring manual editing of notecards. Improved configuration management: Scripts could automatically update configuration parameters stored in notecards, making it easier to maintain and modify object behavior. User data persistence: Objects could store user-specific data, allowing for personalized experiences without manual intervention. Storing with script restarts: Right now, there is no way to restart a script and still store the information inside without the use of an external webhost. Extended variable use: Too many variables can make a script problematic. Notecards could allow for storing and recalling them as needed to a far easier degree. Simplified data sharing: Scripts could generate and distribute notecards with custom content to users or other objects, facilitating information exchange. Reduced script memory usage: By offloading data to notecards, scripts could potentially use less memory for storing large amounts of information. Enhanced debugging and logging: Scripts could write log data or debug information to notecards for easier troubleshooting and analysis. Dynamic content creation: Objects could generate and update notecards with current information, such as player statistics or in-world event details. We need the ability to write to notecards. I'm shocked we don't have this yet but it feels like not having this as an option does a great disservice to creators and customers in Second Life.

Add the ability to receive input from game controllers such as joysticks, Xbox controllers, etc. This will allow the creation ofhHelicopters and planes that use analog input from console controllers, attachments that control drones, arcade games, cranes, machinima puppetry, etc. This new feature will be implemented by adding a LSL event game_control(...) which script authors can use to capture and respond to input from users. For further details, see https://wiki.secondlife.com/wiki/Game_control

I'm posting this here since my original post as a bug was closed with an "expected behavior"-type reply. As referred to by the discussion mentioned in the LSL portal documentation for llGetLinkPrimitiveParams() ( https://community.secondlife.com/forums/topic/486118-only-set-ambiance-on-prim_projector/?_gl=11wd89ez_ga_T7G7P6DCEC*MTcwNjU2MzkwNS4xLjEuMTcwNjU2MzkwNy41OC4wLjA.#comment-2446570 ) the call with PRIM_PROJECTOR currently triggers shouting on the DEBUG_CHANNEL about an unsupported parameter. I understand that PRIM_PROJECTOR is considered, for now, as write only, but I see no valid reason why it could not be readable at all. The current situation is inconsistent in my opinion. While I understand the potential problem with texture rights, I believe the behavior of this parameter should be consistent with that of PRIM_TEXTURE: if the texture is in the prim's inventory, return its name, else if the owner has full permissions over the object return its UUID. Otherwise return NULL_KEY. This is important to be able to "copy" a user-set parameter from one object to another for example, I want to read the parameters and send them to another object. Please make PRIM_PROJECTOR behave just like PRIM_TEXTURE in this regard, as described in the discussion. Thanks!

We have many ways to Detect if an object is (left) clicked on, but no way to Detect if someone rights clicks on that same object, Why? This would be a very useful feature for the SL Racing Community and vehicle enjoyers as a whole, and I'm sure this could have many other uses for scripters in general. The reason for this request is because of the ability of a resident to effect the movement of a car (or any physical object) even if the object doesn't belong to them by right clicking on the object. I am not talking about a resident that has the person's edit rights, or estate manager of the sim they are on. But someone who has no rights to an object can still effect that object by right clicking on it, (often spamming right clicks) it will either make the object micro stutter slowing it down or out right stopping the object in place for a brief moment. Having a function that can detect a right click, much like you can with a left click, so that a script can tell you who is editing it would be very very helpful! And / Or some kind of tag that would stop physical objects from stopping when right clicked / edited would be really cool too.