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.

List management tools are based on strings or managing conversions based on a field number, otherwise you need to make a loop to extract the needed data. it would be useful to add: llList2Integer(list _name, ALL_INTEGER) to convert a list into integers, removing non integer items and llLis2Integer(listname, ALL_INTEGER & NO_ZERO) to convert a list into a list of integers but with no zero when the field was not an integer. Technically it is easy to implement as flags for example with ALL_INTEGER = -1 NO_ZERO = -2 The same could apply to strings to just keep strings from a list, floats to just keep floats, vectors to just keep vectors .. which would be a quick and concise way to extract data especially from imported CSV. PS: Why use flags ? because llList2String() could also implement trimming features that way (flags for trim / trim head / trim tail) or lower / upper case etc. making it be like a super powerful and easy tool on lists. llList2String(listname, TRIM & UPPER_CASE) etc.

Please implement the equivalent of Python's re.escape() in LSL. This escapes regex metacharacters in a string. Repeatedly attempting this via a UDF consumes too much script timing. Thanks.

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

I'm posting this here since my original post as a bug was closed with an "expected behavior"-type reply. As referred to by the discussion mentioned in the LSL portal documentation for llGetLinkPrimitiveParams() ( https://community.secondlife.com/forums/topic/486118-only-set-ambiance-on-prim_projector/?_gl=11wd89ez_ga_T7G7P6DCEC*MTcwNjU2MzkwNS4xLjEuMTcwNjU2MzkwNy41OC4wLjA.#comment-2446570 ) the call with PRIM_PROJECTOR currently triggers shouting on the DEBUG_CHANNEL about an unsupported parameter. I understand that PRIM_PROJECTOR is considered, for now, as write only, but I see no valid reason why it could not be readable at all. The current situation is inconsistent in my opinion. While I understand the potential problem with texture rights, I believe the behavior of this parameter should be consistent with that of PRIM_TEXTURE: if the texture is in the prim's inventory, return its name, else if the owner has full permissions over the object return its UUID. Otherwise return NULL_KEY. This is important to be able to "copy" a user-set parameter from one object to another for example, I want to read the parameters and send them to another object. Please make PRIM_PROJECTOR behave just like PRIM_TEXTURE in this regard, as described in the discussion. Thanks!

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.

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.

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.

Sensors and listeners are limited in what objects they can detect, and both may require extensive setup and overhead in order to pick up all objects of interest in a region. I suggest a new function to retrieve a list of object UUIDs that the owner has permission to return, whether at the region or parcel level, or the owner's own objects otherwise. list llGetObjectList ( list filters, integer start, integer count ) Return a list of object keys matching provided filters. The list should be in the same order that the simulator stores object data, which presumably has the oldest objects first and newest objects last. Some possible filters: OBJECT_LIST_FILTER_BY_NAME, string pattern OBJECT_LIST_FILTER_BY_OWNER_KEY, key id OBJECT_LIST_FILTER_BY_PARCEL, vector pos OBJECT_LIST_FILTER_BY_TYPE, integer type pattern would ideally be the same format as used for llLinksetDataFindKeys . type would ideally align with object types used by llDetectedType . Objects owned by estate managers always have permission to return any objects in the region, so they should be allowed to see a list of all objects in the region with or without filters. Objects that are owned by the same resident/group as parcel(s) in the region have the same privilege. Objects that are given object return permission by a group role on group-owned land require the owner be present in the region to return objects, so the same behavior should be expected for this function. Applications: Updating all instances of an object in a region, without requiring a listener or even an active script in the objects Finding and returning objects with high resource consumption (land impact, script memory, etc) Finding one's own objects when you don't have permission to return objects for the parcel/region

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