Scripting Features

  • Search existing ideas before submitting
  • Use support.secondlife.com for customer support issues
  • Keep posts on-topic
Thank you for your ideas!
Add llGetAgentName(key id) or llGetCreatorName(key id) to retrieve avatar names from UUID, synchronously
📋 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.
5
Add function to get a list of objects in the region
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
9
·

tracked

Load More