Scripting Features

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

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.

TL;DR: Allowing scripts to directly open the notecard UI for users would dramatically simplify configuration compared to dialogs, HUDs, or manual inventory editing. --- One of the fallbacks in creating configurable systems for users is how the end user actually gets to configure things. Creating an elaborate dialog stream is complex and often becomes the work of an entire script. Creating a webpage and putting it on a prim is even more complex—and while it’s the prettiest option, few do it since it usually also requires attaching a HUD object. The most typical solution right now is editing a notecard, which entails editing an object, switching to the correct prim’s Contents tab, opening the notecard, and remembering to save when done. If a script could llLoadNotecard (similar to llLoadURL in a touch event) to open the editable version of a specific notecard in its inventory, we could offer an Edit button that conveniently opens the correct notecard for the user on demand. It could also open different notecards for different save states, which would likely be far easier for users to understand and manage.

Suggested a method to reply to a http_request with the contents of a notecard with some simple templating options. llHTTPRespondWithNotecard(request_id, notecard_id_or_name, list_of_tokens_and_substitutions); request_id being the key of the request notecard_id_or_name being a natecard key or name of one in the objects inventory list_of_tokens_and_substitutions being a strided key value pair list of tokens to substitute in the notecards content e.g A script doing http_request( key request_id, string method, string body ) { llHTTPRespondWithNotecard( request_id, "content", [ "%%A%%", "Hello", "%%B%%", "World" ] ); } With a notecard in it's object inventory called "content" containing %%A%% %%B%%!!! %%A%% %%B%%!!! %%A%% %%B%%!!! Would serve the http content of Hello World!!! Hello World!!! Hello World!!! To the request. This sort of feature was discussed a few times a Simulator User Groups

Particle system sorely need an overhaul and additional settings to make the best use of it. I've broken up a list of features to make tracking for each one easier for the devs. Texture Animation for ParticleSystem Easing Interpolation for ParticleSystem Alpha blend mask mode for ParticleSystem Color Noise for ParticleSystem Reverse Target for ParticleSystem Emissive Interpolation for ParticleSystem Select Sprite for ParticleSystem Offset Position for ParticleSystem PBR for ParticleSystem "MID_" Flags for ParticleSystem Follow a chosen attachment point

llGiveInventory and llGiveAgentInventory both allow for giving inventory. However llGiveInventory allows you to give items unrestricted across any region. llGiveAgentInventory is however restricted but is a more useful function with inventory folders. There is a huge demand to unrestrict llGiveAgentInventory as the whole point of the function was to get around "Unboxers" in the first place as the major usecase. Here are two proposals: This proposal - Allow llGiveAgentInventory to work across regions but only if the destination agent is part of the group the object is assigned to Allow llGiveAgentInventory to work across regions but the contents are put into "Received items", same as Marketplace. -- https://feedback.secondlife.com/scripting-features/p/llgiveagentinventory-across-regions-but-has-to-be-put-it-into-received-items Both proposals go toward the same goal for my personal uses but are not exclusive -- they can be both valid and should be considered on their own merits and usecases. ---- Proposal - Part of same group Lets allow llGiveAgentInventory to work across regions, however only if the destination agent is part of the group that the object is assigned to. Usecases: Roleplay / Combat group that wants to give updated objects to their members Shop that has an customer, outreach or support group of customers that have opted in or subscribed to updates to their products Related issues: https://feedback.secondlife.com/scripting-features/p/improve-usefulness-of-llgiveagentinventory SamanthaTekcat Resident's comment in https://feedback.secondlife.com/scripting-features/p/enhancements-to-llgiveagentinventory-for-folder-management-and-depth-expansion

Hard coding link numbers into scripts is usually bad practice. So it's often best to search for something more concrete like the name of a linked prim and assign it to an integer using a loop by using llGetLinkName and comparing it to the link name you want to find. This isn't very friendly to new scripters who want to work with linked prims. A function that checks all of the prims in a linkset and finds the first instance of a specified link name would make scripts like this much easier. If I wanted to find the first instance of 'door left' in a linkset this could look like; llFindLinkNumber("door left");

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.

The server is aware of whom is a child agent. With llIsChildAgent(key user_key), communication apps can better negotiate whether to use llOwnerSay() or the more "expensive" llInstantMessage() function and its 2 second delay. We can currently use llGetAttachedList() to determine child agent status, but it would be great to do so with a simple integer instead of a var list.