Scripting Features

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

Please implement a REZZED_BY_ME filter for sensors. This results in the sensor() event returning a list of only objects rezzed by the host the script is in. Thanks for any consideration.

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!

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.

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.

With the creation of llRezObjectWithParams, which offers far more flexibility and scalability than the llRezObject/llRezAtRoot functions, I felt that it would be an excellent idea to re-visit a couple of old classic's as well: llSensor and llSensorRepeat These two have been a staple in this program for many years, however with the advent of llCastRay, as well as the Combat 2.0 suite of functions coming soon, it would be fair to at least revisit these two functions and give it a proper facelift and some TLC. In a similar spirit as llRezObjectWithParams, I would like to propose the creation of llSensorWithParams. The principle is the same as its predecessor, which will do a scan and it will return a list based on the filtered results. llSensorWithParams(list params ); *An empty list should only trigger a no_sensor event Parameters should include, but not limited to, the following: SENSOR_NAME - Object or avatar name SENSOR_KEY - group, avatar or object UUID SENSOR_TYPE - mask (AGENT_BY_LEGACY_NAME, AGENT_BY_USERNAME, ACTIVE, PASSIVE, and/or SCRIPTED) SENSOR_RADIUS - distance in meters from center, [0.0, 96.0] SENSOR_ARC – the max angle between the object's local X-axis and detectable objects, [0.0, PI] SENSOR_RATE - how often a scan is performed SENSOR_RC - Performs similar to llCastRay, however start/end vectors could be offset of both endpoints. A TRUE/FALSE flag should be made for the offset based on Global Position or with Rotation factored in. The start vector is the prim calling the Sensor event, while the end is the llDetectedPos. All other RC flags should still apply from llCast Ray SENSOR_HEALTH - Prims/Objects with OBJECT_HEALTH set. (See https://feedback.secondlife.com/combat-20/p/new-llsensor-flag-mask-object-health ) A practical application of this new function is for combat/fantasy role play sims. For example, if a player wants to do a melee attack, throw something explosive like a rocket or fireball, you could call the function as follows for a wall-safe detonation what will filter out those that are in range, but are behind cover: llSensorWithParams([ SENSOR_TYPE ,AGENT, SENSOR_RADIUS, 10, SENSOR_ARC, PI, SENSOR_RC, ZERO_VECTOR, TRUE(global), //start vector ZERO_VECTOR, TRUE(global), //end vector OTHER_FLAGS ]); These are some of the applications that can be involved with this new function. More folks might want to chip in to expand the functionality of it.

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");