Scripting Features

I'm currently developing an Experience that is to be packaged as a product that people can install in their land. One of the difficulties I can see is that in order to allow an experience a user must do a series of steps:- Open About Land Go to allowed Experiences Click add experience Type in the name of the experience The last step is especially prone to user and merchant error. Typo's causing the user not to find the Experience, adding the wrong Experience. Or the Merchant might have since renamed the Experience and the user no longer knows what to search for. To solve these pain points I propose adding the LSL function llRequestAllowExperience. It will ask the user with a dialog if they'd like to allow the experience the script is compiled to in their land, and offer the user to allow it for either 'Parcel' or 'Estate' depending on the permissions over the land the user has.

In scripting, currently we only have support for the following methods in SL: GET, POST, PUT, DELETE There is a new HTTP method QUERY: https://www.rfc-editor.org/info/rfc10008/ There are many benefits laid out in the proposal document that I feel would be beneficial for Second Life scripts. I am proposing adding this new method.

The VSCode plugin to work with scripts in SL from an IDE over a local connection to the viewer is nearly ready, so I'd like to add this request when it comes along: Any chance we'll be able to commit scripts into objects...within objects? Use case: Item gives a temp-attach HUD, which has scripts. Game rezzes pieces, which have scripts. Tons of use cases. Challenge: Finding out what's inside an object. The simulator doesn't know until it fetches the sub-object. I see a path forward here: When we use the local address to connect to an object, and that object has contents, the simulator fetches those sub-objects and their content. Sub-Objects are represenred as sub-folders in VSCode, with contents inside. When contents are synced back up to SL, it's all existing functionalities. The simulator unpacks sub-object(s) to get to the intended resource and replaces the script, then re-takes the objects. So a kind of automated "unpack to find out the content" and then existing capabilitiesthat power script pin and derez to re-pack. Most of this exists. Rezzing to get the object info from the asset server, replacing scripts in objects (via script pin in LSL, so the simulator knows how to do this), and recently, the derez ability to take things back into an object. The current gap: Rezzing is a bit of a problem. This automated "unpack the sub-objects" setup could cause unintended side-effects from rezzing things in ways they weren't intended to rez. Proposed fix: The simulator "rezzes" the content objects, but in a way that is out of the user's control. Li-less, permission-agnostic, invisible, non-physical, owned by simulator process, with scripts non-running. To the user, nothing happens. The simulator fetches the info it needs, sends this to the localhost , and discards the objects. On check-in, a similar process will invisibly get to the right sub-object and replace the script without allowing it to run (but without toggling its run state), and taking the object back. This all runs as an elevated simulator process that simply ignores no-copy, etc. The permissions to do all this editing are checked up-front; the simulator doesn't mess with anything. This has some performance implications, so let's imagine that recursion shouldn't go more than 2 levels or X sub-objects, whichever is met first, where X is whatever LL finds reasonable. Bonus!! If this can work in VSCode (via this shadow-simulator-agent rezzing thing), then I could see a future Viewer UI piece as well. Trivially, drag a script onto an object inside the contents area, get a menu asking whether you want to copy to Contents, or within object XYZ. If you choose object XYZ? Same routine; invisibly rez, add/replace the script, take back.

Basically it does the same as putting a script with llSetRemoteScriptAccessPin in the object's on_rez Right now if you have a project that relies on updating scripts of rezzed objects, you'll need to make a script that sets the pin and requests an update via the llSay system. This makes said script a major failure point because llSay has a tendency of being dropped during lag spikes, forcing you to set up a syn/ack system. And if you later discover that your syn/ack system wasn't as robust as you thought, or want to change it in any way, you may potentially have hundreds of items that you need to manually rework. Being able to set the remote script access pin directly on rez would eliminate the need for a syn/ack system entirely. Because you could: Rez object with pin Remote load the script(s) immediately in object_rez Profit! Another added benefit of this system is that you could rez the object without the scripts that you intend to overwrite with remote loading, saving time rezzing the object.

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?"

As a creator, I was trying to make a new user experience with a HUD that docks UI elements to the left or right side of the screen. I was using llGetCameraAspect to figure out the width of the screen. However, I discovered that it is impossible as a creator to dock my UI to either side of the screen accurately. The problem is that the viewer can have Toolbar Buttons that are docked to the sides of the screen. When these are docked, the 'aspect' of the viewport is changed, but llGetCameraAspect does not reflect it. This means that UI elements get covered up by docked Viewer UI. Being unable to accurately dock HUD UI elements to the side of the screen limits the types of experiences I can build and the quality at which I can build them. I want to meet the higher quality expectations of our new generation of players joining us in 2026 who have grown out of platforms like Roblox where such UI issues do not exist. I would like a function that can tell me what area of the viewport is unobscured by docked toolbar buttons. This way I can calculate where to place my HUD elements more accurately adapting to an individual users viewport.

The problematic bots are those that are not marked as bots so that they may enter locations where bots are banned. The solution is for LL to actively monitor for avatars that are teleporting all over SL while sending data from a LSL script to an offworld or inworld server. I'm talking about data that can't be collected by the viewer/bot-software directly. The pattern should be quite distinct - teleport, data collected, data transmitted, repeat. Or even several teleports and then transmit the data if it's cached for a while in the script. Ditto for detecting the LSL commands being run after each teleport. The regions are in the best position to detect and collate this bot-like behaviour from avatars that are not flagged as bots. With the unmistakable bot behaviour being the frequent teleporting, collection and transmission of specific information. Once the offworld/inworld server is identified all avatars sending information to this server should be suspended from being able to login immediately to prevent new bots being created to replace suspended bots. This will ensure new bot accounts are instantly blocked the moment they start reporting data to their database. The goal is for all bots to be flagged as bots in their profile so that people can block them by using the region setting to deny bots entry to the region. Of course we will need similar functionality to block bots from mainland parcels too. What we should not be doing is adding limitations to existing LSL commands, or the ability for new accounts to explore SL as some people have suggested. Bot behaviour is quite distinct and detectable by the regions and this is where we should be enforcing the bot policy on the bots directly.

Ability to make individual prims within a linkset follow any attachment point, not just the attachment point the root prim is occupying. This would enable certain attachments with clickable prims to be combined; alleviating attachment limit woes. *EDIT: Clarification for anyone else who misunderstands. A skinned mesh (incorrectly termed "rigged" in SL) cannot be scripted with a touch event, which is the entire point of my request. Additionally, as is also true in Kristy's example use case, the user needs to be able to reposition the prim wherever they please. Setting bone weight via the script would make this impossible.

In order to change the value of one parameter using llSetPrimitiveParams , the script must specify values for all of the parameters for the given flag. With the addition of PBR, which can be changed in child links only with this function, this has never been more cumbersome. I propose a new constant be added to preserve the existing value for the position it is placed in. A "NO_CHANGE" or "KEEP" constant could replace known or unknown values in order to preserve them while changing other values following a flag. Take this for example: llSetLinkPrimitiveParamsFast(2, [PRIM_TEXTURE, 0, "12345678-1234-1234-1234-123456789012", <1,1,0>, <0,0,0>, 0]); If we don't know the texture on face 0 of link 2, then we would need to add a second script in that link to change any of the above individual parameters, or we could have something like this: llSetLinkPrimitiveParamsFast(2, [PRIM_TEXTURE, 0, NO_CHANGE, <1,1,0>, <0,0,0>, 0]); Because some parameters require other parameters to be defined when changed, llSetPrimitiveParams should assume defaults (or revert to previously used values, if available) when not provided or currently in use, such as mask_cutoff when PRIM_ALPHA_MODE_MASK is used. This feature would provide a significant quality of life improvement to scripters working with objects that they don't have all of the source items for.

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);