Scripting Features

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.

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

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

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

I need does-not-contain word/phrase support so I am not resorting to making massive sized patterns. Please add support for both lookbehind and lookahead with the regex based LSL functions. (?=...),(?!...),(?<=...) and (?<!...) Thanks.

(or llGetInventoryAddedBy, or - ... But I'll stick to the semantics of "last owner" for presentation's sake) Scripts can act on object inventory and objects can be configured to accept inventory from any source ( llAllowInventoryDrop ), as well as from agents with permission to modify the owner's objects. Being able to interrogate object inventory entries for their last owner would be good addition to scripting - it would make CHANGED_INVENTORY and CHANGED_ALLOWED_DROP events more able to richly react to the users causing them, as well as allowing for (slightly) better behavior security. Objects have a property OBJECT_LAST_OWNER_ID but this can only be interrogated (in script land) with llGetObjectDetails, while the object exists in the world. It would be nice if this property was: available on all kinds of asset, set on them when they are added to an object's inventory (and only then), accessible via a key llGetInventoryLastOwner(string item) function; the same theme as llGetInventoryCreator . ---- Hauling this up from a later thought, bonus round! integer llGetInventoryAddCount() string llGetInventoryAddName(integer index) integer llGetInventoryAddType(integer index) integer llGetInventoryRemoveCount() string llGetInventoryRemoveName(integer index) integer llGetInventoryRemoveType(integer index) That are populated only within CHANGED_INVENTORY and CHANGED_ALLOWED_DROP events. I have no idea of the cost of holding this stuff in the event queue versus user-implemented prior/new state comparisons - but I think I can reasonably assume it would be cheaper for everyone.

Currently, we have no way to rotate the avatar. This function would rotate the owner of the script on the Z-axis and would work as an attachment. With this, we can rotate the avatar to the surface normal of a wall, table, or other avatars without the need to use RLV functions that manipulate the camera or having to sit and unsit the avatar. This would allow for things like wall climbing and a host of other useful applications. https://gyazo.com/7d441967232c304a4fa20ce722ec18ce rotation RotNormal(vector _normal){ vector vLeft = llVecNorm( _normal % llRot2Fwd(llGetRot())); vector vFwd = vLeft % _normal; rotation rRot = llAxes2Rot(vFwd, vLeft, _normal); return rRot; } wall_climb() { vector scale = llGetAgentSize(owner); vector vStart = llGetPos() + <scale.x/2,0,scale.z/2> * llGetRot(); vector vEnd = vStart + <0.25,0,-1.0> * llGetRot(); list CN = llCastRay(vStart, vEnd, [RC_DATA_FLAGS,RC_GET_NORMAL, RC_MAX_HITS, 1]); float FW_Dist = llVecDist(vStart,llList2Vector(CN, 1) + <scale.x/2,0,0> * RotNormal(llList2Vector(CN, 2))); /* Set the position and agent rotation to the surface normal of the detected object. */ }

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.

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

These days, we have to resort to bots when we want to send another user a group invitation. This is pretty annoying and uses additional resources while scripted objects are pretty cheap in comparison. I propose: llInviteToGroup(key target_avatar, string group_role); group_role can be either the name of the role or its key. Limitations: The object must be set to the group it should invite others to, so no group name/key needed in the command. The object inviting the avatar must be owned by someone who is a member of the group and has the necessary group role ability to invite others to the selected role. The object must be in the same region as target_avatar. The object can not be an attachment. The object can only send invites inside a touch_* event. The object will sleep 10 seconds after each invitation (optional? not sure if it's needed)