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

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.

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

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 full well understand why llEmail - which can be used to send emails to inside AND outside of SL - has a 20 seconds forced delay. However, when used only inside of SL, using the lsl.secondlife.com namespace for object-to-object communication, the delay seems excessive to me. llEmail is basically the only(!) way for object-to-object communication that is reliable over long periods of time without the need to cache ephemeral URI's like we need with llHTTPRequest, where the URI changes with each restart. llEmail used in conjunction with an object UUID will run come hell or high water. Making llEmail in the lsl.secondlife.com namespace run with the typical 2 second delay (or less even), would allow scripters to keep more communication inworld and rely less on external servers. /me waits for the bot to turn it to "tracked"

There are many animations out there which were uploaded with a low / default priority. These are fine provided other overlayed animations running at the same time don't override their actions. It would be useful to be able to change that priority when starting the animation. eg: llStartAnimationPriority("animation", 6);

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!

I've spent about the last week updating some scripts to handle both PBR and Blinn-Phong updates simultaneously. The scripts work fine, but the current way you have to update PBR values - through llSetPrimitiveParams and the full list of values - is not ideal. In order to avoid overwriting your existing values with blank or incorrect data, you have to have a way to know and store your existing values, modify those values, and send the whole list back in. Adding in some llFunctions for PBR values, so you don't have to modify the entire parameter array to change one value, would make scripting PBR modifications much more pleasant to work with. If llFunctions are not feasible, a way to update individual values in the parameter arrays without data loss (e.g. being able to pass a blank string as a texture and have it skip the value instead of applying it) would be appreciated. I've compiled a list below of how I would personally pop each value out into a Set function (they would have matching Get functions, a la llGetColor and llSetColor): --- For PRIM_GLTF_BASE_COLOR: llSetGLTFBaseTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFBaseColor(vector color, integer face); llSetGLTFBaseAlphaMode(integer gltf_alpha_mode, integer face); llSetGLTFBaseAlpha(float alpha, integer face); llSetGLTFBaseAlphaMask(float alpha_mask_cutoff, integer face); llSetGLTFBaseDoubleSided(integer double_sided, integer face); --- For PRIM_GLTF_NORMAL (this really only has one function): llSetGLTFNormal(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); --- For PRIM_GLTF_METALLIC_ROUGHNESS: llSetGLTFMetalRoughTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFMetallicFactor(float metallic_factor, integer face); llSetGLTFRoughnessFactor(float roughness_factor, integer face); --- For PRIM_GLTF_EMISSIVE: llSetGLTFEmissiveTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFEmissiveTint(float emissive_tint, integer face);