Scripting Features

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

llDialogTimed( key avatar, string message, list buttons, integer channel,float timeout ); and llTextBoxTimed( key avatar, string message, integer channel,float timeout ); Two new functions behaving like originals but that vanished after a time Very often we set a timer event after a dialog or textbox after witch we listenRemove putting same time will cause it to disappear when no more expected.

Some external services deny a request if a HTTP_ACCEPT header is present. However, llHTTPRequest enforces that header, using "text/plain;charset=utf-8" if no other header (out of a small list of available options) is present. As Monty Linden confirmed in https://community.secondlife.com/forums/topic/521090-grid-ssl-cert-updates-coming-soon/#findComment-2881062 , empty HTTP_ACCESS headers are not allowed. I would like to suggest that making a llHTTPRequest call with an explicitly empty HTTP_ACCEPT header will remove that header altogether in http-out calls. Examples: llHTTPRequest(url, [],"" ); No HTTP_ACCEPT set, default "text/plain;charset=utf-8" gets used. llHTTPRequest(url, [HTTP_ACCEPT, "application/json”],"" ); Specific HTTP_ACCEPT set, so only "application/json” gets accepted. llHTTPRequest(url, [HTTP_ACCEPT, ""],"" ); Empty string gets passed - HTTP_ACCEPT header gets removed completely. The chances for breaking existing content are slim, since a scripter would have had to explicitly pass an empty string (in violation of the documentation), and then rely on it being substituted with text/plain. Since work on the http-out part is underway anyway, this would be an ideal opportunity to add this feature.

Add a new method for material animation. This function would allow for independent channel animation on different faces of the same link or faces throughout a linkset. Rules for a material channel override containing an empty list are not animated. New/Improved Mode Flags: ANIM_ON: Starts the animation. LOOP: Repeats the animation indefinitely. REVERSE: Plays the animation backward. PING_PONG: Alternates between forward and backward animation. SMOOTH: Provides smoother transitions between frames. ROTATE: Rotates the texture map (e.g., for rotating textures). SCALE: Animates texture scaling. BLEND: Cross-fades between frames for smoother transitions. RANDOM_START: Randomizes the start frame in the animation sequence. SYNC_ALL_LINKS: Synchronizes animations across all linked objects. SYNC_CHANNELS: Synchronizes animation material channels. ie base, metallic, normal, emission. FRAME_BLEND: Allows frame blending (interpolation between frames). The material rules would contain the following: string material_UUID: Defines the texture asset to be used for the material. integer size_x: Defines the grid size (for sprite sheet-based animations or texture tiling). integer size_y: Defines the grid size (for sprite sheet-based animations or texture tiling). float start: Start position in the animation cycle. float length: Length of the animation cycle. float rate: Speed of the animation. float transition_time: Optional parameter for smooth transitions between frames. Example Useage: // Define mode flags integer mode_flags_face_0 = ANIM_ON | LOOP | SMOOTH | SCALE; integer mode_flags_face_1 = ANIM_ON | LOOP | REVERSE | PING_PONG; integer mode_flags_face_2 = ANIM_ON | LOOP | SMOOTH | ROTATE | FRAME_BLEND; // Animation rules for face 0 (Base Color, Metallic, Normal, Emission) list base_color_rules_face_0 = ["UUID-of-BaseColor-Texture", 4, 4, 0.0, 1.0, 0.5]; list metallic_rules_face_0 = ["UUID-of-Metallic-Texture", 2, 2, 0.0, 1.0, 0.8]; list normal_rules_face_0 = ["UUID-of-Normal-Texture", 3, 3, 0.0, 1.0, 1.0]; list emission_rules_face_0 = ["UUID-of-Emission-Texture", 4, 4, 0.0, 1.0, 1.2]; // Animation rules for face 1 (Base Color, Metallic, Normal, Emission) list base_color_rules_face_1 = ["UUID-of-BaseColor-Texture2", 3, 3, 0.0, 1.0, 1.0]; list metallic_rules_face_1 = ["UUID-of-Metallic-Texture2", 3, 3, 0.0, 0.5, 0.5]; list normal_rules_face_1 = ["UUID-of-Normal-Texture2", 3, 3, 0.0, 1.0, 1.0]; list emission_rules_face_1 = ["UUID-of-Emission-Texture2", 3, 3, 0.0, 0.8, 1.2]; // Animation rules for face 2 (Base Color, Metallic, Normal, Emission) list base_color_rules_face_2 = ["UUID-of-BaseColor-Texture3", 5, 5, 0.0, 1.0, 1.0]; list metallic_rules_face_2 = ["UUID-of-Metallic-Texture3", 5, 5, 0.0, 1.0, 1.5]; list normal_rules_face_2 = ["UUID-of-Normal-Texture3", 5, 5, 0.0, 1.0, 1.0]; list emission_rules_face_2 = ["UUID-of-Emission-Texture3", 5, 5, 0.0, 1.0, 1.2]; // Set animations for face 0 llSetLinkMaterialAnim(2, 0, mode_flags_face_0, base_color_rules_face_0, metallic_rules_face_0, normal_rules_face_0, emission_rules_face_0); // Set animations for face 1 llSetLinkMaterialAnim(2, 1, mode_flags_face_1, base_color_rules_face_1, metallic_rules_face_1, normal_rules_face_1, emission_rules_face_1); // Set animations for face 2 llSetLinkMaterialAnim(2, 2, mode_flags_face_2, base_color_rules_face_2, metallic_rules_face_2, normal_rules_face_2, emission_rules_face_2);

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

It seems kinda crazy we're in 2025 and there's no programmatic way to detect this

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 a new function LSL function named llRenderText or similar, which allows users to dynamically render text, with limited but flexible formatting, onto the face of their choosing. Concept: // Signature llRenderText(integer face, string text, list params); // Basic example llRenderText(ALL_FACES, "Lorem ipsum...", [ FONT_ALIGN, "right", FONT_WEIGHT, "bold", FONT_FAMILY, "sans serif" ]); Rationale Text is ubiquitous, yet Second Life has no way for users to display text other than uploading a texture, setting floating text using llSetText , or using relatively resource intensive solution such as XyText/Furware/et al. This absence precludes interesting features, such as being able to create a responsive interactive terminal in Second Life, HUDs with dynamic text, etc. A scripted and efficient text solution that displays on the face of a prim/mesh would give Second Life the biggest bang for the buck: Limited in scope (easier to implement than grand UI-creation ideas) Easy to kitbash into existing and new creations For inspiration, you can look to how the Text Display widget is implemented in the Playstation game Dreams. It has limited options: a finite number of fonts and formatting options, but the fact that it can be combined with other content makes it rather powerful. Other details Font color, opacity, glow, etc are controlled by prim properties (Example: setting face color to red sets font color to red) Questions Should the background always be transparent? Creators could put another prim behind the text display face to give it a background, or it could be a property of the render params. Possible Parameters FONT_WEIGHT FONT_STYLE FONT_FAMILY FONT_VERTICAL_ALIGN FONT_HORIZONTAL_ALIGN FONT_TEXT_WRAP FONT_LINE_HEIGHT FONT_SIZE Possible Features Markdown / rich text

llTeleportAgentHome() should never have been implemented in its current form. While it is understood that the various "security features" of the Linden Scripting Language arguably serve a valid purpose in numerous situations - primarily to mitigate griefing or privacy concerns at the local/parcel level, the reality is that these functions are more often than not used irresponsibly by residents, causing absolutely undue and undeserved disruption to the target resident's Second Life experience. llTeleportAgentHome() is particularly egregious when used without any advance warning or without enough time to move clear of the parcel. Indeed, the lack of warning and lack of time to clear is the primary offense here. It can be sensibly argued that the vast majority of encounters with these aggressive scripted objects are accidental. Especially when in aircraft, it is impossible to know in advance if your 60 minute flight that you're 30 minutes into is about to be cancelled the moment you cross into the next parcel. I would also argue that it is the residents who deploy these tools in this manner who are the actual griefers. At the very least, however, please add a mandatory 10 second delay to the teleport home function. Residents can opt-in to a specific implementation should they desire immediate effect, which might be likely in certain games or roleplay experiences. But generally speaking, the instant payload is far too punitive and unnecessarily disruptive to residents who do not mean to intrude, but rather are simply trying to navigate somewhere. It would also be a confusing and probably upsetting event for a new resident to have to experience as they explore the Mainland, and might give them pause to reconsider whether Second Life is worth their time investment if this is the behavior they can expect from the established resident community. This nonsense has gone on long enough, and too many people are just fed up. Ask anyone in the driving and aviation groups. You are not providing tools for residents to control their experience, you are providing tools for residents to use in an overly aggressive and frankly obnoxious manner toward other residents.

We have many ways to Detect if an object is (left) clicked on, but no way to Detect if someone rights clicks on that same object, Why? This would be a very useful feature for the SL Racing Community and vehicle enjoyers as a whole, and I'm sure this could have many other uses for scripters in general. The reason for this request is because of the ability of a resident to effect the movement of a car (or any physical object) even if the object doesn't belong to them by right clicking on the object. I am not talking about a resident that has the person's edit rights, or estate manager of the sim they are on. But someone who has no rights to an object can still effect that object by right clicking on it, (often spamming right clicks) it will either make the object micro stutter slowing it down or out right stopping the object in place for a brief moment. Having a function that can detect a right click, much like you can with a left click, so that a script can tell you who is editing it would be very very helpful! And / Or some kind of tag that would stop physical objects from stopping when right clicked / edited would be really cool too.