Scripting Features

to allow flying or driving over or across edge of parcels without interruption, add a short delay to llEjectAgent() so that the shortest delay is a few seconds. What problems might this cause?

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?"

Ability to teleport a vehicle like a sim crossing, but to arbitrary grid coordinates. Something Like llTeleportVehicleGlobalCoords(vector global_coordinates, vector region_coordinates, rotation direction ); Should either obey the current allow object entry or a new parcel setting "Allow Remote Object Entry"? . Object should be returned to inventory if the parcel teleported to is set to no entry. Possibly only available if object has a seated avatar? Don't really need teleporting objects. This would probably need to be an experience function. But this could lead to heavy fragmentation and incompatible portals. Seeing as gridwide experiences aren't real, and a script in a vehicle would need to have the correct experience for the land its one etc.... Leave behind avatars that have not accepted the experience? A script could give users that haven't accepted the experience a map link to follow along after.. Mostly this would allow for road tunnels for vehicles to other places, spreading the SL road network and increasing connectivity.

A new function, llAttachToAvatarTempFromInventory(integer AttachmentPoint, string ItemName) , that allows an already attached object to temporarily attach items from that object's inventory without triggering a permission prompt. Use Case: Currently, HUDs and wearable objects must pre-attach all possible assets or rely on cumbersome rezzing workarounds to swap out attachments dynamically. This leads to performance issues due to high prim counts and complexity. A smoother system would be beneficial for: Modular HUDs: Hide/show different components without inflating linksets. Helps with keeping resources low when the main hud is worn at all time. Handheld Items: A backpack could let a user select and equip objects (e.g., food, tools, toys) seamlessly. App-Based Wearables: A "smartphone" HUD could swap out apps dynamically without needing excessive link changes or manual updates. Why It’s Needed: Better UX: No unnecessary permission pop-ups for already attached objects. More Flexibility: Allows seamless temporary attachments without excessive preloading. Performance Gains: Reduces linkset size and avoids multiple workarounds. Proposed Behavior: If the calling object is already attached, it can attach another item from the object's inventory without requiring a permission prompt. If the calling object is not attached, it must request attachment permissions as usual. If the user sits on an object, it must still ask for attachment permissions, following existing conventions. This function would streamline many workflows and enhance interactivity in Second Life while respecting user control.

I would like to interface with an external API via LSL, but it only responds with the content type of application/x-ndjson. The response data is actionable data that LSL is capable of processing, however as the content-type is not on the strict list of types that HTTP_ACCEPT permits, it returns status 415 "Unsupported or unknown Content-Type." The header from the API I want to use is Content-Type: application/x-ndjson; charset=utf-8 Sample return data { "id": "9mkQIvL8rnrn", "time": 1740453264, "expires": 1740496464, "event": "message", "topic": "demo", "message": "a demo message" } { "id": "uOim1bYhnisq", "time": 1740453267, "expires": 1740496467, "event": "message", "topic": "demo", "message": "a demo message" } { "id": "wFhpksR0U2Lc", "time": 1740453267, "expires": 1740496467, "event": "message", "topic": "demo", "message": "a demo message" }

Summary: Enhance llGiveAgentInventory to provide better folder management and allow deeper inventory hierarchy, enabling more complex inventory structures for scripted outfit and appearance management systems. Proposed Enhancements: New Flag for Folder Reuse - Introduce an additional flag ( TRANSFER_REUSE_FOLDER ) that, when set, will place items in an existing destination folder if it already exists, rather than creating a duplicate. - This will prevent unnecessary clutter in a user’s inventory when updating or managing scripted items. Increase Maximum Folder Depth - Expand the allowable inventory path depth from 4 levels to 8 levels when using TRANSFER_DEST . - This allows for more granular organization, which is particularly useful for modular outfit management systems where users need to organize appearance layers and accessories effectively. Use Case: A scripted outfit management system needs to store various items in a structured way, such as: #RLV | Product/Region | Outfits | Sci-Fi | Armor | Chest | V1 #RLV | Product/Region | Outfits | Sci-Fi | Armor | Chest | V2 #RLV | Product/Region | Outfits | Fantasy | Robes | Mage | Red #RLV | Product/Region | Outfits | Fantasy | Robes | Mage | Blue The current depth limitation (4 levels) makes this approach unworkable. By increasing the depth to 8, systems that manage avatar appearances dynamically can maintain organization without workarounds like splitting folders into separate deliveries and having the user manually move them. Additionally, without TRANSFER_REUSE_FOLDER , every time a scripted system attempts to add to an outfit folder, it creates duplicates, making inventory organization difficult for users. This flag would ensure updates and additions go into the existing folder seamlessly. Expected Benefits: Improved Inventory Organization – Prevents unnecessary duplicate folders when updating outfits or items. Greater Flexibility for Outfit Management – Allows deeper categorization, benefiting modular and layered appearance systems. Better User Experience – Reduces clutter and streamlines scripted inventory transfers. These enhancements will significantly improve usability for content creators and users relying on automated inventory systems. Thank you for considering this feature request!

Many areas could benefit if the scripts running in them could be notified of impending region restart. For example, Several of the RP games I play could suspend activity automatically to allow agents to exit the region in a more orderly fashion.

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

Currently, the process to obtain group information is extremely limited. For avatars, pulling the UUID via llGetObjectDetails with a list entry given by llGetAttachedList is the only way. Objects themselves being only able to natively return the group UUID via llGetObjectDetails, but obtaining additional details about the group is not possible with any existing function. The only way to pull the name of the group an avatar/object is set to is via the group's webpage which requires running a HTML request, with other things such as the group's texture being pulled the same way. Due to these reasons, trying to set up systems which interface with groups has been largely unintuitive and unreliable beyond a simple true-or-false check. The goal of this request is to create simple functions that can pull group information directly ingame without having to call upon external resources, in addition to adding ways to pull the specific information of a group which there is currently no function for. Examples: string llGetGroupKey(key UUID) - Returns the group UUID active on object or avatar. string llGetGroupName(key Group_UUID) - Returns a string that is the group's name string llGetGroupTexture(key Group_UUID) - Returns the UUID that is the texture set to the group. string llGetGroupDesc(key Group_UUID) - Returns a string that is the description of the group. integer llGetGroupRating(key Group_UUID) - Returns 0 if group is General, or 1 if the rating is set to Moderate. list llGetGroupDetails(key UUID, list flags) - Returns a list containing the information request in 'flags'. Valid flags would be GROUP_KEY, GROUP_NAME, GROUP_TEXTURE, GROUP_DESC, GROUP_RATING.

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