Scripting Features

note: I didn't set the title to "LinkSet" and I have no clue why it's doing that, considering it's "Linkset" in the editor! weird! This suggestion was brought up a year ago and closed a few days later. I think, with respect to Spidey & Lucia, it deserves a second crack with a more well-defined spec, because we are actually missing an important function here. Problem There is currently only one function that returns any useful data regarding the memory usage of the linkset datastore - llLinksetDataAvailable , which only returns the bytes remaining for the entire datastore. It is currently impossible to measure the bytes used by any specific pair(s) without either reading them and running a base64 count (expensive, risky) or deleting them and measuring the change in available bytes (pointless). This is a problem because there is no limit on the size of linkset data pairs. Unless you only have a single pair in the datastore, it is currently impossible to tell if the pair you are about to read will be too large and crash your script. To that end, it is trivial to come up with an extremely tiny script that creates a pair so big that it is practically guaranteed to crash any script that tries to read it. Nor is it difficult to imagine scenarios where this could occur unintentionally. This will become even more likely with Luau support as Lua scripts (and, AIUI, Luau-compiled LSL) will switch back from UTF-16 to UTF-8, changing how strings count against script memory and facilitating bigger pairs. Proposal llLinksetDataBytes( string name ) string name - The key of the linkset name:value pair to count the bytes of. Returns an integer with the number of bytes used by the pair (including its name and 32-byte passphrase hash, if used), or 0 if it does not exist. llLinksetDataBytesFound( string pattern ) string pattern - A regular expression describing which keys to sum the bytes used of. Returns an integer with the number of bytes used by all keys matched by the regex. The point of these function names is to avoid confusing them with counting length as opposed to bytes . Also, linkset data storage is not "memory" per se, so I don't think the previous suggestion of llLinksetDataMemoryFound is semantically correct. Use Cases llLinksetDataBytes can get the bytes used by a linkset data pair without needing an expensive, risky, or destructive workaround. This is a separate function from llLinksetDataBytesFound because LSL lacks a regex escape function (although it can be done manually, just inefficiently) so it is more efficient if you want to check a single pair immediately before reading it. llLinksetDataBytesFound allows you to measure all pairs matching a certain regex at once. For example, say you have two concurrent data schemas in a single object - some pairs start with "array" and are used for a large array-like structure, some start with "config" and store notecard values, whatever. Trying to actually measure the bytes used by either of these schemas individually is potentially memory-intensive and slow, even though we already have llLinksetDataFindKeys and llLinksetDataDeleteFound . The only current practical solution is to run the aforementioned base64 count on every value you write, modify, or delete, and maintain a byte total manually. Additionally, llLinksetDataBytesFound makes it possible to calculate the entire space available to the datastore (128kB as of this writing, though it was once already raised from 64kB). This is currently impossible because there is no function that returns the complement of llLinksetDataAvailable , nor is there a function that returns the entire capacity, à la llGetMemoryLimit . This function fills that gap without needing to provide a function to return what may well be a constant (but not guaranteed!) 131072 forever. Caveats It is possible that someone could consider the bytes used by a protected pair to be sensitive information that this function shouldn't disclose; however, since llLinksetDataAvailable can be used to do this already, the novelty of this risk would be negligible. Since the bytes within the linkset datastore are UTF-8 but get read into Mono-compiled scripts as UTF-16, the bytes reported will not exactly match the bytes the value would use once read, although any value is better than nothing. (This won't be a problem under Luau, and wasn't a problem under LSL-2, just Mono.)

Several of the body vendors include scripts to change the shape of the foot to match the shoe being worn from flat footed to on tip-toes. But when the foot shape changes, the avatar is left hovering in the air, or sinking into the ground and the hover height needs to be manually changed to reflect the new food position. I suggest adding a new LSL command to alter the hover height of the avatar. Thus: llSetAgentHoverHeight(key Agent, float Distance) ( edit to add a key field to the command. Not surf if it would needed or not. but the the behavior that if the agent key is not also the owner key that the command is either ignored, or an error is shouted on the debug channel ) The distance can either be a fixed value, or a relative value based on the current hover value. Examples. When I stand barefoot, my hover height is "0.06" -- as shown on the "Avatar > Hover Height > Set Hover Height" slider. But when I'm wearing heels my hover height is "0.170" So the "llSetAgentHoverHeight" would either need to set the static values of 0.06, 0.170, and any other needed values for the shoes in question, or adding (+0.102) to the "current' value when putting on heels, and subtracting (-0.102) from the 'current' value when putting on flats. The actual values, either static or relative would need to be established either by the shoe maker, or the shoe wearer, depending on how the script maker decides best of course.

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

Something I've had issues with is making stuff that communicates with other stuff easily configurable. It'd be nice if we could utilize build tools in conjunction with LSL to do this. The simulator is already aware of what is selected, so it shouldn't be too difficult to expose it via LSL. Think of the following: I make two teleporters, instead of going through making the resident copy UUIDs or set up channels, they can just select the two teleporters then do /1234 link and they are linked automatically. Ideally, it would return a list of objects (up to a limit, I'm aware large amounts of objects can be selected at once, enough to cause a stack heap collision), with the first entry being the last object someone selected, and the last being the first selected. As for the function signature, maybe something like llGetSelectedList(key agent, list options) . Might want to put it behind some sort of permission though if it is someone other than owner. Might be useful to have a singular llIsSelectedBy(key agent); as well, to avoid having to do loops / list index checking in timers / events.

Currently there's no way to detect if rezzing an object has failed, (e.g. due to being too far away, or an invalid inventory item name) but the viewer does get this information when users screw up. Can we get object_rez_failed(key id) added to LSL (and SLua), by analogy with no_sensor() and experience_permissions_denied() ?

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 pretty sure many of us hate this happening. All kinds of workaround solutions like a script checking on timer() base if another is still running seems quite old school and inefficient too. How to do it, no idea but suggestions welcome. Pure random and probably imaginary idea: a new event function - or even state - that does run regardless, and then can properly do the necessary work?

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!

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.

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