Scripting Features

Add native WebSocket support (client and/or server) to LSL, similar to the existing HTTP request capabilities (llHTTPRequest, llRequestURL, etc.). WebSockets would allow persistent, bidirectional connections so scripts can send and receive real-time messages far more efficiently than the current HTTP polling or short-lived request model. This would greatly improve responsiveness for chat systems, multiplayer game logic, external service integration, dashboards, and any use case that needs low-latency updates. Any additional details... Support both outbound WebSocket clients (llWebSocketConnect or similar) and optional inbound/listening capability. Events for open, message, close, and error (e.g. websocket_message, websocket_close). Ability to send text and optionally binary frames. Reasonable connection limits, timeouts, and memory safeguards consistent with other LSL networking features. Optional authentication/header support and TLS (wss://). Compatibility with existing HTTP features so creators can migrate gradually. This would significantly reduce server load and script complexity compared to repeated HTTP requests while enabling true real-time experiences in Second Life.

Allow modification of a shape (provided it is modifiable) setting any of the parameters available on Edit shape. Prerequisites:- Script must be on a worn attachment (& therefore belong to the wearer) Worn shape is modifiable New permissions request - say Permission_Change_Shape = 4096 LSL functions: (list)llGetShape[list params1); Delivers list in correct format to be supplied to ... (integer)llModifyShape(list params2); Delivers True is successful params1 = [Body_Height, Body_Leg_Length ...] -> params2 = [Body_Height,50, Body_Leg_length,40 ...] Even if the modifications don't survive a relog this would be most useful. If they are not saved then editing shape then saving should really save the changes or unwear & rewear picks up original again

I'd like to see a CAMERA_YAW parameter added to the command. In an avatar follower application, you currently specify the point the camera's looking at as an X,Y,Z displacement relative to yourself (CAMERA_FOCUS_OFFSET parameter). You then specify the camera's position by its distance (CAMERA_DISTANCE) from the focal point and a pitch (CAMERA_PITCH) angle, basically a rotation around the Y axis, as if you were nodding up or down to look at the focal point. I would like to see yaw as well (rotation around the Z axis, as if you were turning your head left or right. This would allow you to position a camera not only above or below your head to look at the focal point, but also to one side or the other. I suggest the parameter be called CAMERA_YAW, that it also be a float value, in degrees, same as CAMERA_PITCH, and a range of, say, -45 degrees (rotated around to the left side of the head) to 45 (rotated around to the right side of the head). Adding this should not break existing content, since only those parameters that are specified are used, so existing scripts using llSetCameraParams that don't call it won't miss it.

I'd like a native scripted screen overlay, including an opaque blackout mode, authorised through an explicit permission or accepted Experience. Currently, a creator can attach a prim HUD to cover the scene, but it can be moved, resized, made transparent, or hidden through viewer HUD controls. Scripts can repair some changes afterwards, but that leaves gaps and doesn't address viewer-side hiding. Could we have a viewer-rendered overlay that doesn't depend on prim geometry, attachment slots, or screen aspect ratio? Ideally: Supports a solid colour, opacity, optional texture, and readable text. Can cover the entire 3D scene while optionally keeping necessary interface controls accessible. Works independently of the ordinary Show/Hide HUDs setting, but could toggle that setting via Experience. Reports whether the viewer supports and has activated it. Identifies the controlling Experience and provides a clear way to withdraw permission or leave. Automatically clears on Experience withdrawal, leaving its permitted area, or controller failure through an expiring lease. Provides predictable behaviour when multiple controllers request overlays. Uses include game blindness effects, transitions, camera-boundary warnings, and blackout when a camera enters a protected area. This would not make content confidential against modified viewers, but it would provide a consistent native effect for supporting viewers without relying on movable HUD prims. I'm happy to discuss the design and help develop/test the viewer-side implementation.

Pretty straightforward ask here. CHANGED_COLOR can detect when the Tint or Alpha of any face of an object has changed. CHANGED_TEXTURE can detect when the Texture of any face has changed. CHANGED_LIGHT could detect when variables for PRIM_POINT_LIGHT (on/off, tint, intensity, radius, or falloff) have been changed by hand or by script, and when the variables for the projection light (texture, FOV, focus, or ambience) have been changed.

Pretty simple request: llClamp(integer val, integer min, integer max)

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

Add INVENTORY_SOFTOBJECT to llGetInventoryType, or any other name to denote a soft-linked (aka, coalesced) object. Because there is currently no way to distinguish those from a singlle object. And this is vital for rezzers and such.

I'm developing a region system with zone-based camera restrictions, and I'd like an Experience-authorised way to enforce a maximum camera-to-avatar distance. In my testing, ordinary scripted camera control can be bypassed by Alt-camming. A preferred camera distance isn't the same as an enforced maximum. At present, achieving the latter appears to require RLV/RLVa and a supporting viewer. Could we have a native camera-distance restriction that continues to apply during Alt-click, orbit, pan, and zoom, without requiring RLV? Ideally: Requires explicit permission, with support for accepted Experiences. Allows a script to set and release a maximum distance in metres. Supports zone-based use, with scripts updating the limit as residents move. Reports whether the restriction was accepted and is supported. Automatically releases on Experience withdrawal, leaving its permitted area, or controller failure through an expiring lease. Handles restrictions from multiple controllers without one script clearing another's settings. This would be useful for games, exploration, confined spaces, and optional privacy-related zone rules. It should remain clear to residents which Experience is controlling their camera and how to leave it. I'm happy to discuss the design and help develop/test the viewer-side implementation.

With the introduction of PBR and new features in SL the The 64k memory limit is becoming increasingly hard to work with and not suitable for modern designs. When designing more feature intensive HUDS its hard not to keep running out of memory, suggestion to double or increase the limit would be very much welcome for 2024.