Scripting Features

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

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

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

note: I didn't set the title to "LinkSet" and I have no clue why it's doing that, considering it's "Linkset" in the editor! weird! This suggestion was brought up a year ago and closed a few days later. I think, with respect to Spidey & Lucia, it deserves a second crack with a more well-defined spec, because we are actually missing an important function here. Problem There is currently only one function that returns any useful data regarding the memory usage of the linkset datastore - llLinksetDataAvailable , which only returns the bytes remaining for the entire datastore. It is currently impossible to measure the bytes used by any specific pair(s) without either reading them and running a base64 count (expensive, risky) or deleting them and measuring the change in available bytes (pointless). This is a problem because there is no limit on the size of linkset data pairs. Unless you only have a single pair in the datastore, it is currently impossible to tell if the pair you are about to read will be too large and crash your script. To that end, it is trivial to come up with an extremely tiny script that creates a pair so big that it is practically guaranteed to crash any script that tries to read it. Nor is it difficult to imagine scenarios where this could occur unintentionally. This will become even more likely with Luau support as Lua scripts (and, AIUI, Luau-compiled LSL) will switch back from UTF-16 to UTF-8, changing how strings count against script memory and facilitating bigger pairs. Proposal llLinksetDataBytes( string name ) string name - The key of the linkset name:value pair to count the bytes of. Returns an integer with the number of bytes used by the pair (including its name and 32-byte passphrase hash, if used), or 0 if it does not exist. llLinksetDataBytesFound( string pattern ) string pattern - A regular expression describing which keys to sum the bytes used of. Returns an integer with the number of bytes used by all keys matched by the regex. The point of these function names is to avoid confusing them with counting length as opposed to bytes . Also, linkset data storage is not "memory" per se, so I don't think the previous suggestion of llLinksetDataMemoryFound is semantically correct. Use Cases llLinksetDataBytes can get the bytes used by a linkset data pair without needing an expensive, risky, or destructive workaround. This is a separate function from llLinksetDataBytesFound because LSL lacks a regex escape function (although it can be done manually, just inefficiently) so it is more efficient if you want to check a single pair immediately before reading it. llLinksetDataBytesFound allows you to measure all pairs matching a certain regex at once. For example, say you have two concurrent data schemas in a single object - some pairs start with "array" and are used for a large array-like structure, some start with "config" and store notecard values, whatever. Trying to actually measure the bytes used by either of these schemas individually is potentially memory-intensive and slow, even though we already have llLinksetDataFindKeys and llLinksetDataDeleteFound . The only current practical solution is to run the aforementioned base64 count on every value you write, modify, or delete, and maintain a byte total manually. Additionally, llLinksetDataBytesFound makes it possible to calculate the entire space available to the datastore (128kB as of this writing, though it was once already raised from 64kB). This is currently impossible because there is no function that returns the complement of llLinksetDataAvailable , nor is there a function that returns the entire capacity, à la llGetMemoryLimit . This function fills that gap without needing to provide a function to return what may well be a constant (but not guaranteed!) 131072 forever. Caveats It is possible that someone could consider the bytes used by a protected pair to be sensitive information that this function shouldn't disclose; however, since llLinksetDataAvailable can be used to do this already, the novelty of this risk would be negligible. Since the bytes within the linkset datastore are UTF-8 but get read into Mono-compiled scripts as UTF-16, the bytes reported will not exactly match the bytes the value would use once read, although any value is better than nothing. (This won't be a problem under Luau, and wasn't a problem under LSL-2, just Mono.)

I'm pretty sure many of us hate this happening. All kinds of workaround solutions like a script checking on timer() base if another is still running seems quite old school and inefficient too. How to do it, no idea but suggestions welcome. Pure random and probably imaginary idea: a new event function - or even state - that does run regardless, and then can properly do the necessary work?

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.

Second Life's interactive objects rely on LSL—a basic scripting language largely unchanged since 2003. This limits creators’ ability to build advanced, dynamic experiences. By introducing Lua, a powerful and widely adopted language, we can modernize scripting and unlock new creative possibilities. Broadens Second Life’s creator base to more easily include developers from Lua-heavy platforms (e.g., Roblox, Garry's Mod). Reinvigorates existing creators who’ve struggled with LSL’s limitations. Enables advanced features like mobile-focused development kits and robust 3D content manipulation (e.g., GLTF). Objectives New Audiences : Attract creators from popular Lua-based UGC platforms. Easier Scripting : Leverage Lua’s built-in features, large support community, and ample learning resources. Re-Engage Creators : Provide a smooth transition from LSL with bridging functionality, encouraging return visits. Advanced Features : Introduce long-requested language improvements (e.g., map-types, index operators). Richer Experiences : Allow for more complex, dynamic scripts to increase retention and drive engagement. Reduced Technical Debt : Replace LSL's difficult-to-maintain system with a modern, flexible alternative. Education Opportunities : Offer a full-featured language that helps new programmers build real-world skills. Links Lua FAQ - Read this if you have questions about "Why Lua?"

Rationale We have sit targets to define where an avatar should sit on a linked object. But when standing up, it's always at that exact same position. This is awkward for things like vehicles where the user will unsit inside the vehicle instead of stepping out gracefully. This goes together with a possible unsit event as proposed here: https://feedback.secondlife.com/scripting-features/p/unsit-events Proposal Add a possibility to let us define the exact spot and rotation where the avatar will be positioned/moved to at the moment of unsitting.