Scripting Features

Currently, if you want to walk, you have to hold down the W/↑ key, which can get annoying and - for people with arthritis, for example - painful. Many modern platforms therefore have an auto-walk feature which makes walking a toggle. For SL, this would also be a nice feature. You can assign a key, tap it, and you walk until you hit the toggle, W/↑ or S/↓.

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!

Add the option to show an "Open" style dialog that lists content, and has an accept / discard button on receiving items via llGiveAgentInventory This would be a huge enhancement to the user unpacking experience, being able to see and accept inventory transfers. I would suggest that the process flow like this - llGiveAgentInventory(llGetOwner(),"Product",["item1","item2],[TRANSFER_SHOW_PREVIEW,TRUE]) - Items are delivered to user in specified folder just as they are now (prevent loss if dialog ignored) - A dialog similar to the "Open" dialog shows with contents given. - Accept button just closes dialog - Decline button, moves folder to trash, and closes dialog

Thud... thud... thud... I think it would be nice to be able to set a custom avatar collision sound from a script. Some of us float, some of us have more padded bodies.. some of us are heavy, some of us are light.. Being able to customise the default collision sound would just add an extra bit of personlisation to the avatar. I'd expect that if such a feature were implemented, the custom collision sound would play when the avatar collides with any object that doesn't have a custom collision sound. If the avatar collides with an object that has a custom collision sound, the objects collision sound would play instead

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!

With Lua becoming a thing on the viewer, having a way to directly communicate with a object or script would be nice. We do have game_control, and others have suggested midi. It'd be nice if we just had a general purpose "send a object / script some data as part of a ingest" or "send the viewer a message". For example, one of the major issues with RLV is that you have to "ask" the viewer in llOwnerSay, in which the viewer may or may not have RLV implementations. Asking it over a Script Message would be very useful. Or if you want to control more than just 6 axises. This provides a universal approach for developers to interface viewer side scripting with server side scripting. For example, I tried using my leap motion controller in Second Life using the new game_control messages: https://www.youtube.com/watch?v=wsmbyWWvQG8 A problem I encountered is I am limited to 6 axises. Being able to specify (N) number of data entries would allow me to add information such as finger positions/rotations as well, instead of just the palm position. Another example I did was a voice visualizer: https://www.youtube.com/watch?v=ytx-g2j-Y_Q Again, the limit of 6 axises limits what can be done here, being able to stream 8-bit bytes would reduce bandwidth, as well as let me specify additional frequency bins. This can very easily contain other types of user supplied information, such as midi notes, RLV commands, etc. A channel UUID might be useful, but that can also just be the first argument as a signature or something. I'm thinking along these lines: { ScriptMessage Medium ? NotTrusted Zerocoded { AgentData Single { AgentID LLUUID } { SessionID LLUUID } } { MessageTarget Single { TargetType U8 } // 0 = Script, 1 = Object, etc { Target LLUUID } } { MessageData Variable { Type U8 } // LSL Type { Data Variable 2 } // Binary data } } default { state_entry() { llMessageViewer(llGetOwner(), ["Hello, world!", llGetKey()]); } viewer_message(key agent, list params) { } } IN theory, this can be extended to avatars, say like having a target of type avatar and sending it there to allow script to script communication.

key llGetRegionWorldMapTile(string region_name) A LSL function to return the UUID of the current world map tile for a named region, so that it might be placed on a face using PRIM_TEXTURE. This could also be added to llRequestSimulatorData Currently the only ways I know to accomplish this depend on MOAP and voodoo to get an image from slurl.com , or pulling the CDN UUID from gridsurvey.com via a HTTPRequest. Which all seems pretty hacky and unfun.

In order to maintain and upgrade legacy and hybrid contents, it is important to be able to determine whether a face has a PBR material applied. This is currently not possible unless the object owner has full perms -- a highly unlikely case for most products. Whether this is done via a new flag for llGet/SetPrimitiveParams() or a new function is not important. But this functionality is urgently needed and will remain so for years, even after all viewers are PBR capable. Please give this some priority, as it is essential for transitioning current products to PBR.

These days, we have to resort to bots when we want to send another user a group invitation. This is pretty annoying and uses additional resources while scripted objects are pretty cheap in comparison. I propose: llInviteToGroup(key target_avatar, string group_role); group_role can be either the name of the role or its key. Limitations: The object must be set to the group it should invite others to, so no group name/key needed in the command. The object inviting the avatar must be owned by someone who is a member of the group and has the necessary group role ability to invite others to the selected role. The object must be in the same region as target_avatar. The object can not be an attachment. The object can only send invites inside a touch_* event. The object will sleep 10 seconds after each invitation (optional? not sure if it's needed)

This feature request is for a llGetObjectDetails()-like function, but one that gets details for an object's face-based prim properties. Proposed syntax: list llGetObjectFaceDetails(key object_id, integer face_number, list params) Optionally, accepts the ALL_SIDES constant for face_number, which would return data for each face of the target object. Proposed first parameters: OBJECT_FACE_ALPHA - returns a float for alpha. OBJECT_FACE_GLTF_BASE_ALPHA - returns a float for GLTF base alpha. Collision and castray based applications have needed access to the alpha value of a prim face for some time now. Like with llGetObjectDetails(), the proposed function allows future expansion. If anyone has ideas on what additional constants should be included and why, feel free to comment.