Scripting Features

Currently the function rotates the avatar and camera, I think it would be useful if we had a flag to enable or disable the camera being rotated with the function. llSetAgentRot(rotation rot, ROTATE_CAMERA); I Believe this would add useful functionality

Simple one this. Add a new flag to the llGiveAgentInventory command: [TRANSFER_IMG,key] This would allow a folder to be given with a pre-determined folder image. That would be great for unpacker huds as typically used in clothes purchases. Shops that used this would be giving a useful service to customers and the servers wouldn't have to store a unique image for each person updating that folder with their own folder images.

What I want is a region-wide datastore, a very simple API like llLinksetData*. It is not required to be persistent -- scripters could reinitialise it on region restarts. It's ok if it's attached to an object (and therefore acts like a remote llLinksetData). It needs to support high read and high write usage and be synchronous. The usecase is for sharing data between objects at a higher level of abstraction. For example large region projects like games, weather systems, procedural life like pedestrians and cars / NPCs, etc. For example a game would often need to share a lot of data between scripted objects, such as vehicles, players, interactive objects, HUDs and temp attach objects. This often means the data also needs to shared across different objects of different ownership or active group settings securely. The security should be tied to a "project" (RSA keys, passwords and/or pins) or even experience compiled scripts. If the datastore is tied to an object or an avatar maybe all you need to know is the objects or avatar key and a script compiled to an experience to access and read from that region-wide datastore tied to that object or avatar. (E.g. like having a "mana" resource on an avatar and being able to actively manipulate that resource for passive mana regeneration or active/maintained spells from rezzed objects, HUDs or across multiple attachments, e.g. a wand that casts spells which drains the mana and a hud that shows current mana and has passive mana regen) Sometimes higher level of abstractions are needed for projects, such as a game manager that controls the overall state of a game and information such as who the players are and on what team they are / what teams there are, as well as objectives and resources. You should be able to make many of these region-wide datastores as you need in a project. Maybe several game managers/directors. Maybe one per avatar. Maybe one per major game object. Same limit of 128KB of LSD per datastore would be fine. Note that Experience Persistent Storage completely fails the above criteria: It's not high write / high read (I think it would be a bad idea to massively spam exp storage with fast timer reads to make sure to show an updated value on a HUD; What about small constantly changing updates like position, acceleration that may need to update at a very high frequency and be read immediately?) It is not fast / synchronous (how am I supposed to read/write a resource changing at milliseconds by multiple objects in a realtime game? Exp would keep accidentally overwriting values at critical moments as realtime games have action happen in bursts) It is an external server instead of in-memory (there is no reason for this complexity, latency and storage, I just wanted to share critical data (0.5-128KB) between objects in the same region or at least direct neighbouring regions/estate) Nice to have: Datastore being able to optionally/opt-in work cross-region or Estate-level / direct neighbours or 1-2 regions away, e.g. 3 regions in a line or a 2x2 square, just like how some data can be shared across region borders like llGetObjectDetails. This also avoids users having to create overly complicated/engineered systems of scripts to synchronise data between regions if they are all part of the same game/experience

I feel this has to have been discussed before.... but can we get a version of llGetTimestamp() that returns SLT so we're not reduced to adding 70+ lines of code and the associated overhead just to get the same timestamp that's showing up in every viewer?

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

Add the the texture coordinate system to the projector and allow it to be animated just like llSetLinkTextureAnim() so we can project sprite images.

Limits on strings are in bytes[1] everywhere it matters. llStringLength returns a count of characters (code points, presumably). Luau already gives us string.len() utf8.len() to distinguish between the two. ll.OwnerSay("bytes: " .. string.len("abcdᴥ")) // 7 ll.OwnerSay("points: " .. utf8.len("abcdᴥ")) // 5 The suggested approach to getting the byte length of a string in LSL is to convert it to base 64, parse that to a list to strip padding, cast the list back to a string, get the length of that string (since the code point count will now (nearly) match the byte count), and do some math to clean it up. For complexity, performance, and GC, It would be nice if we didn't have to do that. Mono having a utf-16 soul might complicate things? - although vm 2025 certainly uncomplicates them again if so. [1] https://wiki.secondlife.com/wiki/Limits#Communication https://wiki.secondlife.com/wiki/LlGetNotecardLine https://wiki.secondlife.com/wiki/LlHTTPRequest https://wiki.secondlife.com/wiki/LlEmail ... etc ---- Also related- https://feedback.secondlife.com/scripting-features/p/functions-to-get-byte-count-of-a-notcard-line-as-well-as-total-bytes-used-availa

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!

While certain gesture triggers exist to activate if a given user is speaking on voice (/voicelevel1. /voicelevel2, /voicelevel3) it appears that there is no LSL analog to detect these states (or any voice use state). Adding AGENT_SPEAKING to llGetAgentInfo would be analogous with voice, to the long-existing AGENT_TYPING detection. The creative uses for such a trigger are nearly endless, from scripted a multi-camera setup for an interview program, with a camera that could automatically change position to the person currently speaking (useful for vlogs like Lab Gab!), to debate and open mic performance timers, recording cues for editing machinima, scripting a mesh head with custom bones or other nontraditional 'mouth' designs to animate the mouth while the wearer is speaking, or even silly things like a microphone that appears in your hand when speaking (similar to the classic magic keyboards). This seems like a simple to implement feature, that could add a wide variety of creative options.

There are times when the LSL scripter wants the script to remove the currently-display llDialog, and maybe put up a new one instead. My idea: when calling the llDialog, have it optionally return a value to identify it. The obvious would be key K = llDialog(key avatar, string message, list buttons, integer channel ); So the script could save key K, and if the specific dialog needs to be disabled, in the very least have a new function: llCancelDialog(key k); where all that's needed is to send the Key K value back (possibly having to supply the avatar key, too) and on the viewer, the llDialog could vanish. Or turn to a light-gray, which is also a recognized disabled-condition on other apps and web sites. The viewer could even have an option of Preference settings for an llCancelDialog to either be gray or to simply vanish. If the llCancelDialog were invoked on an llTextBox, have it cancel the same way.