Scripting Features

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 like an LSL function to find out whether a teleport would land at the intended destination. Currently if the destination is in another region, the only way to know if the avatar will arrive at the target is to teleport them and find out. I would like to check the destination first, so i dont need to start a teleport that won't arrive at the target. For example, if i wanted to teleport an avatar to another sim at <128, 128, 3020> there's no way to know if they'd actually land at that point or 3000m away on a ground landing point, or if they can't teleport into that parcel at all. The proposed function would send the avatar id and group and target position, and the remote sim would return a vector back indicating where the avatar would land. This would either be at the target destination, at the parcel's landing point, or zero_vector if they dont have permission to enter the target parcel. This would mean a teleport script can check the target first, and not teleport the avatar if they will end up far from the intended destination.

Rather than having in built "freezes" in certain functions like object rez / ll email etc, which are trivially circumventable by "LINK_MESSAGE"ing another script in the same prim and having that other script swallow the delay (providing a 'burstable' limit on these calls) these could be better handled in slua by reworking how these delays are implemented - perhaps on a per prim or per script setting where these calls can be made at "no cost" up to some specific rate after which they stall or fail (for example the way HTTP requests can be performed - there is no function delay here but there is still an overall limit on HTTP requests) The work around of having often multiple 'worker' scripts that just listen for a link message then execute the call to llEmail / etc has always been a bodge, but also rather necessary one if you don't want your main server script to become unresponsive regularly, which is quite important for a simultaneous multi user server style script (e.g. providing a region wide service to all players, the main script here can not be stalled without noticable impact to the players and yet some of these functions with delays in are needed for operation). Made a longer post here https://community.secondlife.com/forums/topic/530018-of-functions-with-delays/ Since so much is changing in the lua implemented stuff we could use this opportunity to redefine or rework how these function delays work, /only/ for pure lua scripts compiled using the new lua mode, while legacy LSL to lua / LSL mono / LSL classic scripts can maintain their previous behaviour regarding delays. This would be great to avoid what is essentially a "gotcha" that new scripters sort of 'need to know' how to work around to have a performant system that needs to use these delayed calls, as well as avoiding the wasted overhead of multiple worker scripts with their overheads and the time wasted in link messaging (especially since all the worker scripts receive all link messages even though only one of them will take up the work) Would just be a great and rare opportunity to revisit a rather archaic piece of the scripting languages implementation that just doesn't really work as advertised anyway once you know of the bypass by offloading to worker scripts, not often breaking changes can be brought in to a new language checkpoint. If this isn't clear enough please let me know and I'll give some better examples or something but I assume this fairly trick is widely known.

llGetUnixTime, llGetTimestamp, llGetDate, llGetGMTClock, llGetWallclock https://wiki.secondlife.com/wiki/LlGetTimestamp We have this lovely function right here, that breaks down the current date and time, in human readable format, down to six decimal points of 'precision' in terms of seconds. 2026-02-07T19:31:56.992713Z Alongside it, we have llGetUnixTime which will give us the number of seconds since 00:00 hours, Jan 1, 1970. It's great, it's amazing. But both of these functions only work based on UTC (GMT) time. We have ~similar-ish~ functions that will report the time based on 'seconds since midnight', either in GMT or in Pacific Time (Second Life Time).. the latter is automatically adjusted for Daylight Savings Time (but there is some question as to whether it is DST as reckoned by Unix, by some international consortium, or US/State law). The math to calculate the 'date' now, (or at any timecode) is absurdly complex, and eats into both script memory and readability for something that should just be a command. We need a better set of tools. I'd love to simply plug in something like llGetBetterTimestamp("ET", TRUE) and get back the current time/date for Eastern Time, adjusted for the current (whatever standard is being used) EST/EDT offset. I'm not sure what the best practices are here. The problem is that we only have, for example, a couple ways to get 'the date'.. and these are all based on UTC. But there's a lot of hours during the day when UTC's date is just wrong dependent on where you are on the earth. At 7pm tonight (in Pennsylvania), the date returned by llGetTimestamp or llGetDate will be wrong for the next 5 hours. The problem is worse in California, where the date returned is wrong for 8 hours of the day... and don't even get started with Hawaii or Alaska. Yes, in some cases the math is less cumbersome to 'patch' the values returned, but in many cases it's quite complicated.. particularly if you wanted to get the "day of the week" or something like that. I feel like this is something that could be fixed with a suite or functions that were purpose built for the task. User Created functions in the 'library' have limited lifespans.. governments change their minds on the dates when Daylight Savings starts and stops too. These things could be updated upstream 'at the source' and then the fixes would propagate to all scripts using them, instead of needing every script writer to fix their code because Arizona decides they're all out on PDT. Alternatively, some simpler math for determining whether a given location is or isn't "+1" to their official "standard" timezone. llDaylightSavings("USA-PA") returning FALSE or TRUE or something, with a master list of 'names' for each relevant sovereign zone (state, province, etc? USA-AZA, USA-AZB, etc.. ) And then there's the problem of trying to solve "what was the date when the UnixTime was 1237811232?" ..it was Mon Mar 23 2009 12:27:12 GMT.. or Mon Mar 23 2009 08:27:12 GMT-0400 (Eastern Daylight Time) or.. 17 years ago.. according to https://www.unixtimestamp.com/ - I have no idea how accurate that is for EDT/EST on that date. Support for historical date/day/time calculations would be amazing too.

Particle system sorely need an overhaul and additional settings to make the best use of it. I've broken up a list of features to make tracking for each one easier for the devs. Texture Animation for ParticleSystem Easing Interpolation for ParticleSystem Alpha blend mask mode for ParticleSystem Color Noise for ParticleSystem Reverse Target for ParticleSystem Emissive Interpolation for ParticleSystem Select Sprite for ParticleSystem Offset Position for ParticleSystem PBR for ParticleSystem "MID_" Flags for ParticleSystem Follow a chosen attachment point

Summary: Enhance llGiveAgentInventory to provide better folder management and allow deeper inventory hierarchy, enabling more complex inventory structures for scripted outfit and appearance management systems. Proposed Enhancements: New Flag for Folder Reuse - Introduce an additional flag ( TRANSFER_REUSE_FOLDER ) that, when set, will place items in an existing destination folder if it already exists, rather than creating a duplicate. - This will prevent unnecessary clutter in a user’s inventory when updating or managing scripted items. Increase Maximum Folder Depth - Expand the allowable inventory path depth from 4 levels to 8 levels when using TRANSFER_DEST . - This allows for more granular organization, which is particularly useful for modular outfit management systems where users need to organize appearance layers and accessories effectively. Use Case: A scripted outfit management system needs to store various items in a structured way, such as: #RLV | Product/Region | Outfits | Sci-Fi | Armor | Chest | V1 #RLV | Product/Region | Outfits | Sci-Fi | Armor | Chest | V2 #RLV | Product/Region | Outfits | Fantasy | Robes | Mage | Red #RLV | Product/Region | Outfits | Fantasy | Robes | Mage | Blue The current depth limitation (4 levels) makes this approach unworkable. By increasing the depth to 8, systems that manage avatar appearances dynamically can maintain organization without workarounds like splitting folders into separate deliveries and having the user manually move them. Additionally, without TRANSFER_REUSE_FOLDER , every time a scripted system attempts to add to an outfit folder, it creates duplicates, making inventory organization difficult for users. This flag would ensure updates and additions go into the existing folder seamlessly. Expected Benefits: Improved Inventory Organization – Prevents unnecessary duplicate folders when updating outfits or items. Greater Flexibility for Outfit Management – Allows deeper categorization, benefiting modular and layered appearance systems. Better User Experience – Reduces clutter and streamlines scripted inventory transfers. These enhancements will significantly improve usability for content creators and users relying on automated inventory systems. Thank you for considering this feature request!

Something I've had issues with is making stuff that communicates with other stuff easily configurable. It'd be nice if we could utilize build tools in conjunction with LSL to do this. The simulator is already aware of what is selected, so it shouldn't be too difficult to expose it via LSL. Think of the following: I make two teleporters, instead of going through making the resident copy UUIDs or set up channels, they can just select the two teleporters then do /1234 link and they are linked automatically. Ideally, it would return a list of objects (up to a limit, I'm aware large amounts of objects can be selected at once, enough to cause a stack heap collision), with the first entry being the last object someone selected, and the last being the first selected. As for the function signature, maybe something like llGetSelectedList(key agent, list options) . Might want to put it behind some sort of permission though if it is someone other than owner. Might be useful to have a singular llIsSelectedBy(key agent); as well, to avoid having to do loops / list index checking in timers / events.

Now that AI is here, many people of different experience are using AI to generate scripts. Given the low footprint of LSL (and SLua) there are not a lot of sources for AI to get patterns and good practices from, so AI frequently hallucinates. Now that MCP is booming, is it possible that we can get an MCP server for LSL and/or SLUa so that we can use agentic coding (I hate the term vibe coding) in IDEs to generate better scripts? That way, less experienced scripters can produce higher quality scripts and experienced scripters can create content more efficiently. When is comes to SLua, having an MCP that tames the AI agent into using good practices will also help the learning curve for people that are adopting SLua, now and in the future.

A lot of scripted objects need to be set for a specific group, for example for commercial events, where gift-givers need to be set to the event group. llSameGroup allows to check the group and give a warning to the object owner, but then you need to rely on a timer and regular checks to react for when the group is changed. Having a group change trigger an event would solve that quite nicely.

to allow flying or driving over or across edge of parcels without interruption, add a short delay to llEjectAgent() so that the shortest delay is a few seconds. What problems might this cause?