Scripting Features

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.

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() ?

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?

I would love if we could do better menus other than just dialogbox, actually customizable menus for more proficient stuff, make huds that aren't primbased or mediabased. Dialogbox is way too constrained for this.

Currently, most mesh attachments in Second Life come with at least one script to receive commands from HUD's and change primitive parameters such as colors and textures. These scripts all add to region script time, slow down sim crossings and increase operating costs for LL. I believe that if we could remotely get/set primitive parameters from a HUD, the number of worn scripts on an avatar would decrease considerably over time. We would need two functions, similar to the existing llSet/GetPrimitiveParams I Propose llSetObjectPrimitiveParams(key object, integer link, string password, list parameters); llGetObjectPrimitiveParams(key object, integer link, string password, list parameters); The function would only work if both objects have the same owner and the correct password is used. The build window would allow us to set a password for remote editing on an object, which once set becomes a private internal variable that cannot be retrieved. Example - Making a remote object the color red Key myShirt = findAttachmentWithName("Captains Shirt"); llSetObjectPrimitiveParams(myShirt, LINK_SET, "some_password", [PRIM_COLOR, <1,0,0>]); By being able to edit objects directly from a HUD we vastly reduce the number of active scripts required to be attached to an agent at any given time, which will lead to better lag, faster sim crossings and lower operating costs.

As of right now, if you want to test that someone is member of a group, you need this person to be actually wearing the group. Which is fine when dealing with vendors or fidelity. However there are scenario where you want to be able to test if a person is a member of a group without them actually wearing it. For example, accessing something or security or special functionality. In the same fashion as llSameGroup(uid) works, we should have a llHasGroup(uid) which would let you test if someone has the group even if not explicitly "wearing it".

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!

Reading over the wiki, I found that the only way to set the scale, offset, or rotate a texture in a linkset is to use PRIM_TEXTURE, which requires that you supply it with a texture otherwise, it will remove the texture from the face you're trying to modify. llScaleTexture(), llOffsetTexture(), and llRotateTexture() do not have an llSetLink or llGetLink equivalent or flag for setting those values directly for the other links in the linkset. It would be really nice to be able to set those values directly via llSetLinkPrimitiveParamsFast() rather than having to worry about supplying a texture or getting and setting or removing a texture. This should also be extended to work with GLTF materials.

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

In various events, such as listeners, we can only pass a string. We know that we can pass floats or integers as a string, but trouble occurs if the listener can receive both alphanumeric and numeric values. The check for that now would be a separate function that would be circumspect. I request adding a function: integer IsNumeric(string input) The input is a string and the return value is TRUE if the string is a valid numerical value (e.g. 1, -2198, 15.49883) and FALSE otherwise.