Scripting Features

📋 Description: Second Life currently lacks a reliable and synchronous way to retrieve an avatar's name from their UUID. The existing options are either incomplete, unreliable, or cumbersome: llKey2Name() – only works if the avatar is online and present in the same region. Totally useless for offline or distant avatars. llRequestAgentData(id, DATA_NAME) – works globally, but is asynchronous, which makes scripting logic unnecessarily complex, especially when dealing with batch object scans (e.g. llGetAttachedList() results). llGetObjectDetails([OBJECT_CREATOR]) – returns only the UUID, never the actual name of the creator. ✅ Requested Feature: Add a synchronous function to retrieve an avatar’s full name (legacy + display name or just legacy), such as: string llGetAgentName(key id); // or llGetCreatorName(key id) It would: Work for any valid agent UUID, regardless of online status or region presence. Return the legacy name (e.g. ResidentName) or display name if available. Respect existing name visibility rules (i.e. only for real agents, not groups or objects). 💡 Why this is needed: Name Display in Scripts: Many scripts scan objects (e.g. attachments, creators) and want to display human-readable information. Without name resolution, UUIDs are useless for end users. Asynchronous Callbacks Are Cumbersome: Managing dataserver events for each attachment creator becomes unscalable in larger scripts or loops. LSL lacks proper data structures to cleanly handle async logic. Consistency: Many SL viewers and Marketplace already resolve names from UUIDs. It's logical and expected that LSL scripting should be able to do the same, natively and synchronously. Reduces Redundant Work: Currently, scripters are forced to cache names manually, handle dataserver events, manage query IDs, and juggle temporary storage — all of which is unnecessary overhead for a basic task. 📌 Conclusion: This is not a luxury feature — it's a basic tool that should exist in LSL to simplify development and enhance usability. A single function to retrieve agent names synchronously would greatly improve script clarity, performance, and user experience. Requested Improvement on the Second Life Website When logging out of the Second Life website and then attempting to log back in, the system automatically reconnects to the previously used avatar without offering a choice. This is problematic for users who have multiple avatars and wish to log in with a different avatar. It is important to add a clear option on the login page allowing users to select the avatar they want to log in with, without forcing automatic reconnection to the last avatar. This improvement would enhance the site's usability and multi-avatar management for users.

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.

From Inara Pey:- https://modemworld.me/2025/06/07/2025-week-23-sl-tpvd-meeting-summary/ "Signal Linden requested feedback on the idea of deprecating and removing Navmesh characters / llCreateCharacter (i.e. Pathfinding)." Here is my feedback:- I am getting the impression LL intends to remove all pathfinding functionality from simulators including the creation of navmesh and LSL functionality like llGetStaticPath I spent much of last year designing and putting together NPC's for my sim including scripting systems that use LSL pathfinding functionality, and spent a lot of time setting up my sim to generate good navmeshes. I will be very upset if this feature is just straight up removed. I can't keep investing my time in pioneering technology in SL if LL are not going to commit to maintaining the technology it implements and destroying my creations at random. I understand the need to transition, but basic pathfinding functionality should be maintained. I do not want to log in one day and find all of my work broken after all of the time and money invested.

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. */ }

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

Linkset Data allows multiple scripts in the same linkset to read/create/update/delete data. We currently do not have any LSD functions with an append validation protocol. Experience KVP updating has a validation protocol w/ feedback which can address race conditions between scripts in the same linkset, different objects in the same region or different objects grid-wide. The following function satisfies the need stated above for LSD: integer llLinksetDataWriteWithValidation(string name, string value, string pass, string original_value) A new failure code constant LINKSETDATA_VALIDATION with value 6 will be needed for this function. Functionality: If name does NOT exist and value is NOT an empty string and original_value is an empty string, the entry is created and 0 is returned, else, 6 is returned. If name exists and value is NOT an empty string and original_value matches name's current value and pass matches name's current pass, the entry is updated and 0 or 5 is returned, else, 6 is returned. If name exists and value is an empty string and original_value matches name's current value and pass matches name's current pass, the entry is deleted and 0 is returned, else, 6 is returned. Other typical check failures such as empty name, name not found, pass mismatch, etc. will return the same values as they do now before validation handling is done. The server is actually already doing these checks in the background to determine what integer value to return with exiting LSD functions. There's just, currently, no validation protection. This feature offers validation protection for creates, updates and deletes which is a must in an environment where multiple scripts can potentially modify an entry at the same time creating race conditions. Since it has password input, this function becomes a defacto all-in-one append function for creates, updates and deletes, something even KVP currently doesn't offer.

The function llInstantMessage can be used to send spam to users as noted here https://feedback.secondlife.com/feature-requests/p/unblockable-instant-message-spam and here https://feedback.secondlife.com/scripting-features/p/feature-request-llinstantmessagenoemail-same-function-as-llinstantmessage-but-do While there are legitimate uses for this function, it is being abused by some to send spam. For example, I get IM via email as a convenience but that also means I get these spam messages too. In particular, region owners are using this message to send IMs only to people who are not logged in making it difficult to put an end to. My suggestion is before this function can be used to send a message to anyone other than the owner of the sending object, the calling object MUST get permission from the recipient first.

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

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.

I'd the ability within LSL, possibly tied to a runtime permission, to be able to adjust the following parcel settings. This would be for moderation, estate management, and event management. Parcel name (string) Parcel description (string) Parcel sale (integer price, key buyer, integer sell_objects_with_land - NULL_KEY for anyone can buy, negative price (or const) to set not for sale. Should always be possible for an object running with estate manager permission, tying this to its own runtime permission for safety would probably be wise) Everyone can: Edit terrain, fly, build, object entry, scripts Group can: build, object entry, scripts Safe (damage) Pushing Show in search (+ category) Adult content Avatars on other parcels can see and chat with avatars on this parcel Landing point (quaternion (x,y,z,rotation) - have const values for blocked TP and anywhere) Snapshot (key texture_id - NULL_KEY for default/unset) Abandon land (Possibly its own runtime permission for safety, should always succeed if owned by an estate manager) Locking these adjustments behind estate manager permissions would be acceptable but not ideal only if absolutely necessary, also completely acceptable would be a reasonable script sleep penalty to prevent unfair use of server resources or abuse. Being able to specify the position or the parcel UUID to act upon for this would be nice to allow for the efficient management of estate regions and large event spaces, possibly with a const to reference the parcel the object resides in currently for convenience in non-centrally managed applications. Any changes that are not authorized would fail and result in an error. This would greatly reduce the reliance on bots / scripted agents which are currently used to accomplish these tasks. Allowing these tasks to be completed totally on-platform would simplify event/venue and estate management dramatically and reduce the load on servers by eliminating the need for bots to idle around waiting to handle these management tasks as needed.