Scripting Features

## Background In the last year, the cost of Gaming hardware like RAM and Graphics Cards has risen dramatically. At the same time, we have users on older hardware that due to the prohibitive expense are unlikely to upgrade their hardware any time soon and intentionally sticking to non-PBR viewers for better performance. We can no longer count on people having newer, faster computers in the future. Companies like nvidia are starting to resurrect discontinued lines of older generation graphics cards due to supply issues. The problem seems likely to last several years. ## The Challenge PBR Materials do not display on non-PBR capable viewers. This means that creators who wish to support these customers should provide fallbacks well into the future. Currently this is quite complex, espescially on things like clothing items with texture changers. Creators of Clothes, and Hair and many other types of products typically need to make texture-changers. Scripting these to have fallbacks runs into all kinds of technical challenges such as permission issues etc. A customer might also edit their PBR material with an override texture that we do not have permissions to. ## Proposed Solution Make it easy to declare to the sim that a face should use the PBR Base Color texture as the Blinn-Phong diffuse color via a script. I propose extending llSetLinkGLTFOverrides to have OVERRIDE_GLTF_AUTO_FALLBACK which has the following behavior:- eg. llSetLinkGLTFOverrides( LINK_SET, ALL_SIDES, [OVERRIDE_GLTF_AUTO_FALLBACK, TRUE]); When set to TRUE , a flag is held on the object. The simulator will immediately set the BlinnPhong diffuse texture and tint to whatever is set on the PBR material, factoring overrides, with the same repeats/rotation etc. Whenever the PBR Material changes, the Simulator will check for this flag, and Sync across the new Base Color settings to the Blinn Phong parameters. It will not check permissions. When set to FALSE (the default behavior), the simulator will no longer automatically sync it across.

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.

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.

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

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.

Ability for a seated avatar to stay relative to the prim they are sitting on when it moves / rotates. E.g default { state_entry() { llLinkSitTarget(2,<0,0,1>,ZERO_ROTATION); llSetLinkSitFlag(2, SIT_FLAG_MAINTAIN_RELATIVE); llSetTimerEvent(0.1); } timer() { llSetLinkPrimitiveParamsFast( 2, [ PRIM_POS_LOCAL,<0,1.5 + llCos(llGetTime()),0>, PRIM_ROT_LOCAL, llEuler2Rot(<0,0,llGetTime()>) ] ); } } An avatar sitting on prim 2 should move back and forth and rotate along with the prim.

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!

Currently, we have no way to rotate the avatar. This function would rotate the owner of the script on the Z-axis and would work as an attachment. With this, we can rotate the avatar to the surface normal of a wall, table, or other avatars without the need to use RLV functions that manipulate the camera or having to sit and unsit the avatar. This would allow for things like wall climbing and a host of other useful applications. https://gyazo.com/7d441967232c304a4fa20ce722ec18ce rotation RotNormal(vector _normal){ vector vLeft = llVecNorm( _normal % llRot2Fwd(llGetRot())); vector vFwd = vLeft % _normal; rotation rRot = llAxes2Rot(vFwd, vLeft, _normal); return rRot; } wall_climb() { vector scale = llGetAgentSize(owner); vector vStart = llGetPos() + <scale.x/2,0,scale.z/2> * llGetRot(); vector vEnd = vStart + <0.25,0,-1.0> * llGetRot(); list CN = llCastRay(vStart, vEnd, [RC_DATA_FLAGS,RC_GET_NORMAL, RC_MAX_HITS, 1]); float FW_Dist = llVecDist(vStart,llList2Vector(CN, 1) + <scale.x/2,0,0> * RotNormal(llList2Vector(CN, 2))); /* Set the position and agent rotation to the surface normal of the detected object. */ }

Add the ability to receive input from game controllers such as joysticks, Xbox controllers, etc. This will allow the creation ofhHelicopters and planes that use analog input from console controllers, attachments that control drones, arcade games, cranes, machinima puppetry, etc. This new feature will be implemented by adding a LSL event game_control(...) which script authors can use to capture and respond to input from users. For further details, see https://wiki.secondlife.com/wiki/Game_control

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)