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.

Motivation I am creating a system of two scripts currently where one script handles menus and other data operation which need a fast response while the other script is used for sending instant messages (which have 2 seconds delay). And one of the operations can potentially create a large number of sent messages. I can not make the one script prepare the message text in LSD and let the other one send the messages from there, because LSD is used to hold the needed data and I can need the full storage. The solution I came up with was to send the text for each IM in a separate link message and send those link messages as soon the comm script is ready. This would lead to using two link messages, one (core -> comm) that takes the body of the IM to send and the other (comm -> core) that requests the new one. This solution, however slows down the process. Ideally would be to send a bunch of link messages with text at once and wait until the comm script has handled them. But that can lead to overflowing the event queue if not used carefully. This leads to a semaphore approach: We use a certain KVP on the LSD, say with a key "semaphore". The value is initialized by "0". Whenever a core script sends a link message it increases this value by 1 and stops doing so when the value reached a certain threshold, maybe 16. When the comm script sends the instant message, it decreases the value by 1. Once it crossed the threshold (we can use a second threshold for example 8) the core script resumes generating link messages to send. This solution even allows to keep the message generating part within one function within one event: the generator would use busy waiting where it observes the semaphore value to know if it can generate new link messages, although this would break the "fast response" idea, but it is good for other applications. The solution has only one problem: To update the KVP, a script has to use the llLinksetDataRead and then llLinksetDataWrite operations and since both scripts would call this couple they can do this in the same moment and corrupt the value. Because of this LSD needs a way of atomic value incrementation. Suggestion The semaphore is a regular KVP which is initialized by an integer value casted to a string, for example "0". For the update of this value we need one unprotected and one protected operation: integer llLinksetDataIncrement(string name, integer increment); This operation replaces this code: integer value = (integer)llLinksetDataRead(name); value = valie + increment; llLinksetDataWrite(name, (string)value); return value; But this code block must be embedded into a critical section not allowing the value to be changed by an other script in between. This single operation allows to increment the value, decrement it (use a negative increment) and also read it (use a zero increment but you may also use a regular llLinksetDataRead here) and I think it is fully sufficient for many semaphore applications. The scripter must be sure not to use the regular llLinksetDataWrite to not to corrupt the semaphore value. The protected operation is similar but it accesses a protected KVP and thus uses a password: integer llLinksetDataIncrementProtected(string name, integer increment, string password);

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!

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.

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!