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
LSL functions to adjust parcel settings
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.
0
Bug Report Note for Linden Lab (LSL Script Issue)
Subject: llDialog Function Not Displaying Menu Correctly - List Argument Being Misinterpreted Problem Description: My LSL script is intended to display a menu dialog using llDialog. While the llDialog function appears to be called successfully (confirmed by debug messages), the menu window does not pop up for the user. Analysis of the debug logs strongly suggests that the list menu argument passed to llDialog is being misinterpreted by the LSL compiler or the server-side system. Observed Behavior (from Debug Logs): Despite the list menu variable being defined in the script with the correct LSL list syntax (e.g., list menu = ["Item1", "Item2", "Item3"];), the debug output for the llDialog call shows the menu argument as a concatenated string without list delimiters ([]) or element separators (,). Example Debug Log Line: (Note: The menuText field below shows an example, but the core issue is the menu argument.) [04:27] [HAYSURIZA] Glasses Boston2 B&T(Lel Lady): B-SCRIPT DEBUG: Calling llDialog with: id='513ab74d-b9ab-9dd9-3516-4edd077e733a', menuText='Switch :On head :頭のせ\nStyle mode :Style Choose:スタイルを選ぶ\nSpecularRim :Reflected Rm on/off:リムの反射\nLens Select :Choose lens :レンズを選ぶ\nfullbright :Fullbright :フルブライト有無\nReSize :Size :サイズ調整', menu=fullnrightcloseresizestele modespecularlens listswitch, CHANNEL=1573325313 As seen in menu=fullnrightcloseresizestele modespecularlens listswitch, the list is not properly parsed into elements. Expected Behavior: The menu argument in the llDialog call should be recognized as a proper LSL list, enclosed in square brackets [] with elements separated by commas , (e.g., menu=[fullbright, CLOSE, ReSize, ...]). This should then result in the menu dialog appearing for the user. Steps Already Taken to Troubleshoot: string menuText Formatting: Corrected all full-width spaces to half-width spaces and ensured correct line breaks (\n) in menuText variables (menuText, menuText2, menuText3). list menu Formatting: Initially, ensured list menu = ["Item1", "Item2", ...]; followed correct LSL syntax (double quotes for strings, commas as separators, square brackets for the list). Attempted manual re-typing of the list menu line in the LSL editor to eliminate any invisible/corrupt characters from copy-pasting. This temporarily showed the list correctly in one debug log, but subsequent attempts reverted to the incorrect concatenated string. New Script Creation: Created a brand-new script and copied all code into it, including re-typing the list menu line, but the issue persisted. Script Reset: Repeatedly reset the script after every code change. Viewer Cache: Cleared viewer cache multiple times. Conclusion: Given that the LSL syntax for list menu appears correct in the editor, and debug logs show the llDialog call but with a malformed menu argument, this suggests an issue beyond simple script syntax errors. It points towards a potential problem with the LSL editor's file handling/encoding, or the server-side LSL compiler's parsing of the script, rather than a bug in the LSL script itself. Viewer Information: Please specify your Second Life viewer (e.g., "Official Second Life Viewer,") and its exact version number. my Operating System (e.g., "Windows 10," ).
2
Load More