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.

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?

Currently, the PBR overrides set by llSetLinkPrimitiveParamsFast() PRIM_GLTF_* allow the use of an empty string as a special value to only alter one property of the affected texture. However, doing so actually clears the property. It would be so useful to have a simple way to tell a property should not be touched by a specific call. For example, if you want to alter the alpha property of the base color texture without clearing a previous override set on the tint_color component (maybe by another script), you are required to first use llGetLinkPrimitiveParams() to extract the components and then alter your intended component, then reapply the whole thing with llSetLinkPrimitiveParamsFast(). This is way too much overhead just for that, and there is the problem of getting NULL_KEY as the texture property if there is a permission problem. In that situation, if another script set an override on the texture component, then you're stuck. This happens when designing plugin scripts for existing systems. My suggestion is that PRIM_GLTF_(BASE_COLOR|NORMAL|METALLIC_ROUGHNESS|EMISSIVE) allow, in addition to the empty string (to clear a component), another special string that would mean "preserve existing overrides on this". This special string could be something simple like "-", "\n", NAK or whatever does not have a risk of colliding with a string of another meaning in this context. Thanks to your attention to this matter ;)

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!

Hello. I am reporting a persistent and critical instability issue with the Second Life Viewer (this occurs on both the Official Linden Lab Viewer and Firestorm Viewer). The application experiences an immediate crash upon the very first launch after a system boot. The Viewer then runs completely stable on the second attempt without any system changes. This bug is consistently reproducible across different Viewer versions. This issue occurs on the following system configuration: Operating System : Windows 11 Pro 64-bit Processor AMD Ryzen 5 7600 Graphics Card : NVIDIA GeForce RTX 4060 NVIDIA Driver Version: 555.99 System RAM: 32 GB DDR5 Windows Power Plan: AMD Ryzen Balanced. To achieve any kind of stability upon initial launch, two specific workarounds must be applied simultaneously: VSync Must Be Disabled: Vertical Sync (VSync) must be explicitly DISABLED within the NVIDIA Control Panel for the Viewer application. Run as Administrator: The Viewer client must always be launched with Administrator privileges. All standard and advanced troubleshooting methods have been exhausted. The following critical tests confirm the issue is software-based: Hardware Stability Confirmed: Power Supply Unit (PSU) and GPU stability have been verified. The computer successfully passed a full 15-minute GPU stress test using FurMark (running at 100% usage, even with VSync on) without any system shutdown or crash. This rules out hardware failure (PSU/Overheating). Software Scope: The problem is confirmed to occur on the Official SL Viewer, Firestorm Viewer, and older Firestorm versions. Other Steps: All drivers/OS are updated, cache has been cleared multiple times, and various graphics debug settings (VRAM detection overrides) have been attempted without success.The issue appears to be rooted in the Viewer's core initialization process (likely VRAM allocation or system file access) during its initial cold start on this specific hardware configuration.I have included the Crash Logs from a failed first launch attempt. Please use this information, particularly the log files, to diagnose why the core Viewer code is unstable upon initial launch on a system running the NVIDIA RTX 4060. I didnt do picture. because dont show me only just close me all game and computer. i have that from one week, before did work normal and without problems. A rigorous, clean reinstallation of the NVIDIA drivers (using DDU) has been performed. Following this process, the complete computer shutdown issue has been resolved, but the game still crashes on the first launch attempt. I must use the workaround (Run as Administrator + VSync OFF) for stable operation. This definitively confirms that the bug lies deep within the Viewer's core code and requires your intervention. With close Vsync and I'm starting as an administrator game close too. close me again but after 3 h. i did try too take off my all avatar and wear old from firestorm but is same. i send one picture what show me after close game.

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