Scripting Features

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.

As a sim owner, I wish I could get better insights into prim (aka Land Impact) usage within my land. One key thing for me is I want to one day offer skybox rental in my region, but it is difficult to calculate land impact usage llGetPrimUsage(key avatar, list options); Options support the following:- PRIM_USAGE_PARCEL Get the amount of prims the agent is using within the parcel. PRIM_USAGE_REGION Get the amount of prims the agent is using within the entire region. PRIM_USAGE_AREA, vector bound_lower, vector bound_upper Get the amount of prims used in the specified area The last option would be the most useful for me as it would give me a way to measure land impact being used within skyboxes.

Second Life should implement Scripted UI as a modern replacement for prim-based HUDs. Prim HUDs have been a workaround for years, but they are outdated, inconsistent, and often visually clunky. A native Scripted UI system would remove the need for so many prim HUDs from circulation, reduce design fragmentation, and give creators a unified way to build interfaces that look and behave consistently across experiences. It would also improve the overall dialog box and UI presentation, making interactions cleaner, more readable, and more intuitive for residents. This is a much-needed request because Second Life has evolved, but its UI ecosystem still feels fragmented. Right now, HUDs vary wildly in quality, layout, and usability, which creates confusion and visual inconsistency. A proper Scripted UI would help standardize controls, improve accessibility, and make content feel more polished and professional. It would also give creators more flexibility without forcing them to rely on awkward prim-heavy builds that are harder to manage, more cumbersome to maintain, and less visually cohesive. It would also help retain new users. HUDs are one of the biggest things that new residents struggle to understand, and many end up needing someone to heavily guide them just to figure out basic interaction. A cleaner, built-in Scripted UI would make Second Life far more approachable, reduce that learning curve, and help new users feel less overwhelmed. That matters because first impressions are everything, and confusing HUD-based systems can make the platform feel harder to use than it needs to be. Second Life already has a strong creative community, and a modern UI framework would empower that community instead of limiting it. If Linden Lab wants to improve user experience, reduce clutter, and keep the platform competitive and usable, Scripted UI is not just a nice feature, it is a necessary step forward. Thanks to @hacker.Resident for this article. https://kathar.in/post/149846332570/lsl-ui

Simple one this. Add a new flag to the llGiveAgentInventory command: [TRANSFER_IMG,key] This would allow a folder to be given with a pre-determined folder image. That would be great for unpacker huds as typically used in clothes purchases. Shops that used this would be giving a useful service to customers and the servers wouldn't have to store a unique image for each person updating that folder with their own folder images.

There are many animations out there which were uploaded with a low / default priority. These are fine provided other overlayed animations running at the same time don't override their actions. It would be useful to be able to change that priority when starting the animation. eg: llStartAnimationPriority("animation", 6);

Currently there are a lot of things that damage your avatar via colliding with things and it triggers DAMAGE_TYPE_IMPACT We are forced to use llAdjustDamage to negate this to do things like dodge rolls without dying, but it can be unreliable and also just takes up uneccessary resources to have every avatar in a sim doing it constantly. Please allow for a land / estate setting, or a region debug setting to just disable DAMAGE_TYPE_IMPACT entirely so that avatars don't take impact damage at all, thus freeing us from needing to use work arounds.

key llGetRegionWorldMapTile(string region_name) A LSL function to return the UUID of the current world map tile for a named region, so that it might be placed on a face using PRIM_TEXTURE. This could also be added to llRequestSimulatorData Currently the only ways I know to accomplish this depend on MOAP and voodoo to get an image from slurl.com , or pulling the CDN UUID from gridsurvey.com via a HTTPRequest. Which all seems pretty hacky and unfun.

Please consider adding an endpoint to the map API for fetching data useful for navigating the grid. This data would be readily available map information. At the present, this is a very, very strange task to accomplish. We can pound LL's servers using this API: https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=region&grid_x=1000&grid_y=1000 And scanning every possible range of coordinates we think is useful. Or We can use a bot on a custom viewer, making MapBlockRequests until we've got the whole grid. Each of these really need an external service running, and hit your servers pretty hard--but it's all for information that you already have that would be valuable to us to use for scripted applications (eg for navigation HUDs, custom maps, games with distributed locations, exploration apps, touring pods) and also, just in general to know how our world is doing. Proposal: Two https endpoints to fetch paginated region info lists. First API endpont: region list by number. The order is determined by LL and is arbitrary, but is used for pagination. A script can ask for the first N regions, then another set of regions starting from N and so on. In this way, scripts can parse the region list without hitting the api server, sim, or script memory too hard Second API endpoint: region list by name. Similar to searching a word on the map and getting one or several regions that match the name. Responses are delivered as JSON, with each region'd details in an object of the following form: { { "name" : "Da Boom", "coordinate" : "<1000.0, 1000.0, 0.0>", "estate_name" : "mainland", "region_map_image" : "7963f194-82f9-23b3-3d89-c21f1bd0a8bc", "access_name":"Moderate" } } Example of using the first endpoint, the enumerated API: The endpoint can be called with a page number, and an optional maximum. For example, suppose we are permitted up to 25 list items in a single call: Example: Fetch default 25 items starting with the 437th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=437 Example: Fetch only 5 items starting with the 75th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=75&length=5 In this way, external services we write and LSL code in-world could reasonably work with the large list of region data in a way that doesn't flood the API (feel free to rate limit) and that permits us to work within script memory limits. Example of using the second endpoint, the named API: The endpoint is called with a search term, and returns one or more regions that have a name starting with the term. There should be a minimum character limit. Ecample: Fetch regions starting with the name "Da B" https://cap.secondlife/com/cap/NAME_ENDPOINT?search=Da%20B Summary: There are many standing requests for access to the map tile information, map region names, and map grid coordinates, all in separate feature requests. I propose this API mechanism to capture data you already have in a way that solves every request.

Allow us to retrieve keys and/or data from the Experience KVP storage by passing a regex or pattern. Example: an experience KVP contains the following keys (key, value): player_(some_uuid), "Player Name" player_(another_uuid), "Another Player" player_(yet_another), "Third Player" level_1, "SomeLevelDescription" level_2, "AnotherLevelDescription" level_3, "AndHereIsAnotherLevel" Now I do something like: searchRequest = llSearchKeyKeyValue("player_.*", 0); or: searchRequest = llSearchValueKeyValue("Player Name", 0); and retrieve the result in the dataserver event as usual. Why would this be important? Given the example, if I want to display or count all player names, I have to read through the whole storage and filter the "player_.*" entries "manually", which takes a lot of time if you have a big KVP storage and are only interested in a small subset of keys / data. This functionality would greatly simplify and accelerate scripts that deal with mixed data inside an experience KVP storage.

llSetCameraParams already has CAMERA_PITCH to move the cam up and down around an avatar. However, it's missing left/right and roll to look from the side. I was missing this especially when using the new game_control feature to use the right stick to try and orbit around a sitter on a vehicle which isn't possible without those suggested params.