Scripting Features

Currently, most mesh attachments in Second Life come with at least one script to receive commands from HUD's and change primitive parameters such as colors and textures. These scripts all add to region script time, slow down sim crossings and increase operating costs for LL. I believe that if we could remotely get/set primitive parameters from a HUD, the number of worn scripts on an avatar would decrease considerably over time. We would need two functions, similar to the existing llSet/GetPrimitiveParams I Propose llSetObjectPrimitiveParams(key object, integer link, string password, list parameters); llGetObjectPrimitiveParams(key object, integer link, string password, list parameters); The function would only work if both objects have the same owner and the correct password is used. The build window would allow us to set a password for remote editing on an object, which once set becomes a private internal variable that cannot be retrieved. Example - Making a remote object the color red Key myShirt = findAttachmentWithName("Captains Shirt"); llSetObjectPrimitiveParams(myShirt, LINK_SET, "some_password", [PRIM_COLOR, <1,0,0>]); By being able to edit objects directly from a HUD we vastly reduce the number of active scripts required to be attached to an agent at any given time, which will lead to better lag, faster sim crossings and lower operating costs.

Proposal Originally proposed on the Jira Allow non owners to receive HTML content. In responses from llHTTPResponse with llSetContentType(id, CONTENT_TYPE_HTML) Currently the restrictions are: (per the wiki) - the web browser is the Second Life client - the user (logged into the SL client viewing the page) is the owner of the object. - the user (logged into the SL client viewing the page) is connected to the region the object is located in I would propose relaxing at least the 2nd, "owner of the object" restriction. Reasoning The current restriction encourages the hosting of content external to sl, resulting in a form of "link rot" over time, leading to ever more broken scripts and objects as users forget/actively take down those external services. Removing it would allow prims to actually host their own pages when needed, in a simpler manner. There are already a few ways (but cumbersome) to circumvent it, so it is already ineffective. There has also been talk of serving content for HTTP requests directly from notecards at SUG meetings, this would compliment that massively. Concerns This should have no impact on either, security or privacy for SL users, as I mentioned above there is already a workaround for this, and the prim could just load an external site that can capture any data far better anyway. User privacy is primarily controlled client side with the decision on whether or not to load the page in the first place (be it via media being disabled, whitelists, or other settings). Additional The 1st and 3rd restrictions could also be lifted, but that is debatable, depending on how LL feels about prims being used to directly host content for use external to SL. I personally would like to make things like control panels etc for user to work with, and instead of having to upload complex meshes and moved things around with scripts a simple html ui would be perfect... but right now you have to bypass this restriction for that.

It'd be great to allow a message length greater than 512 characters. However, at a minimum, right now a message length greater than 512 characters both throws up a debug error AND causes the script to stop running. Is this really world breaking behavior that must be stopped? Maybe instead throw up the error, truncate the message, and allow the script to continue operating?

I found a request for llLinksetDataWritePublic; I'm requesting something similar but distinctly different, hoping this will be compatible with what we have now. I'd like to request a variant of the linkset data functions with the word Remote, and a pin parameter. This set of functions would permit scripts in objects to get or set the linkset data in other objects via a secret access pin when the prim is set to Mod. There's precedent for this! We have remote script pin, for starting/stopping/replacing scripts in other objects. I propose we do the same for data. (I'll bold the new functions & events, the rest work like their current counterparts) Function Spec: function integer llSetRemoteLinksetDataPin(integer pin) Allows a prim to have scripts remotely get and set linkset data function integer llLockRemoteLinksetDataPin(integer pin, integer Locked) Allows a prim to be set to prevent linkset data access from being granted via pin, using a different pin. Eg, a creator could use a pin to set lock to TRUE, preventing a customer from enabling remote data access with a Mod prim. integer llLinksetDataRemoteWrite( key target, integer pin, string name, string value); string llLinksetDataRemoteRead( key target, integer pin, string name); integer llLinksetDataRemoteDelete( key target, integer pin, string name ); list llLinksetDataRemoteDeleteFound( key target, integer pin, string pattern, string pass ); llLinksetDataRemoteReset( key target, integer pin ); integer llLinksetDataRemoteAvailable( key target, integer pin ); integer llLinksetDataRemoteCountKeys( key target, integer pin ); integer llLinksetDataRemoteCountFound( key target, integer pin, string pattern ); list llLinksetDataRemoteListKeys( key target, integer pin, integer first, integer count ); list llLinksetDataRemoteFindKeys( key target, integer pin, string regex, integer first, integer count ); Read, Write, and Delete functions traditionally have a *Protected variation that works the same but adds a string password. This spec could extend protected functionality as well, or we could choose to implement just the functions above to alow data that is "already public." Events Spec: Minimal spec, using existing event: linkset_data( integer action, string name, string value ) Gains the following constants: LINKSET_DATA_REMOTE_RESET | The remote linkset's datastore has been cleared by a call to llLinksetDataRemoteReset. LINKSETDATA_REMOTE_DELETE | A key in the remote linkset's datastore has been deleted. Either through a call to llLinksetDataRemoteDelete or llLinksetDataRemoteWrite with an empty value LINKSETDATA_REMOTE_MULTIDELETE | A comma separated list of the keys in the remote linkset's datastore which have been deleted through a call to llLinksetDataRemoteDeleteFound. Maximal spec, using a new event: function integer linkset_data_listen( key target, integer pin ) | Fires a linkset_data_remote when the remote linkset data changes. Returns handle function linkset_data_close( integer handle ) | No longer fires an event when a remote linkset changes. Event linkset_data_remote( key linkset, integer action, string name, string value ) | Receives all linkset data events from the remote object as though it were that object itself. I see a minimal event spec as being useful and easier to implement; it essentially just tracks when successful remote linkset operations instigated by this script have completed. This provides the minimal needed feedback, and the script would need to check remote data when it intends to use it. The maximal spec might generate a lot of events between objects. But, it's nothing we're not already doing, more clumsily, with the messaging system, but this way would be much cleaner. With a dedicated listen/event event, we could properly have a multi-object game using common data, with events and functions fired by remote trigger. A real game platform! One consideration: It might be desirable to have mod objects, without allowing third-party control. I have included a function to lock/unlock pin access for this purpose.

Per https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/ This is putting the respawns part of what Rider had drafted up as a proposal into a feedback. The Teams portion of the draft is available at: https://feedback.secondlife.com/scripting-features/p/combat-21-teams Respawns builds upon Teams. Adding additional mechanisms to support reliable server-side respawns. That means that Teams can be built as a feature first and Respawns can be considered and built in after. Respawns have a current viable workaround with Experience but Teams are a more fundamental issue that all of SL can benefit from beyond SLMC but also Games and RP sims. --- Currently respawns can only be done through Experiences. Setting the DEATH_ACTION to disable server-side checks and teleportation. Instead upon avatar death, an experience manages via scripts the teleportation to a respawn. But as shown in the Teams proposal, there are many difficulties around identification, checks and logistics. For reference the current implementations either work via Combat Log, observing DEATH events to then teleport an individual to respawn. Or via temp attachment HUDs that rely on on_death to then trigger a teleport to respawn. --- So I would like to see Rider's implementation of Respawns. Which builds upon Teams to enhance it further. See the thread for more details: https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/

LSL dialogs require a timer() event to make sure listeners aren't endlessly open. Why not implement an extra special message when a dialog is closed? Whether it's by the Ignore button or the X. What about an empty message, is that an option? As buttons must have at least 1 character.

The current implementation of the timer event works great for simple tasks. However, it becomes complicated when working with concurrent timers because you need to set the shortest divider for all of them and work with globals and other mechanisms around the timer to determine which timer triggered the timer() event. I suggest a parallel structure for timer events that is more consistent with other ways of requesting resources from the simulator. key llRequestTimerEvent(float sec); It works exactly like the current llSetTimerEvent , except it returns a key that holds the UUID of the specific set timer. timer_request(key queryID) This would be the associated timer event, extending the existing timer event with a key when triggered. This key corresponds with the key returned by llRequestTimerEvent . A request to the simulator returns a query ID, which is then compared to an event trigger to determine which code to execute. This structure is familiar to any scripter beyond beginner level. This suggestion would make working with timers much more efficient. It would reduce resource usage by eliminating the need for 1-second timer loops for complex timing requirements. Ultimately, the current timer event/function could be incorporated into the new structure. Behind the scenes, a legacy llSetTimerEvent would return a NULL_KEY and trigger both the timer and timer_request events, the latter with a NULL_KEY.

llSetParcelForSale() should use a dedicated permission and not piggyback off of PERMISSION_SILENT_ESTATE_MANAGEMENT. The permissions dialog needs to make it very clear that permission to resale land is being requested. Currently, the only thing a user will see in the perms request is "Suppress alerts when managing estate access lists". This has nothing to do with selling their land. Yes, this will have to wait on a viewer update, but that is what is takes to have clarity and offer peace of mind.

Linkset data is amazing for persistent storage and sending data between scripts. Having a set of data for avatars would be great too. It would enable synchronizing settings between multiple items of the same brand a lot easier. Storing shared settings, for example access block lists for interactive attachments. Or storing settings data when before swapping to a redelivered version of the same item, that can then read it. Sending password protected data between HUDs and other attachments, instead of using chat channels. I’m sure scripters would fine plenty of uses for something like this. Functionally it should have all the features of the LinkSetData, with some differences: • No equivalent for LlLinksetDataReset, as we wouldn’t want one brand’s items destroy other brand’s item’s data. • Larger storage than 128k, as there can’t be 30k avatars in a sim, compared to regular prims, more storage shouldn’t be a problem, I’d say 1mb or more sounds reasonable starting point. • Equivalent of https://feedback.secondlife.com/scripting-features/p/edit-linksetdata-from-inside-the-viewer would be a must, with a reset all button for the viewer. We wouldn’t want a broken item filling in someone’s whole storage, so ability for the Residents to clear all data or just select data would be required. • Maybe add a permission request before item can Write/Delete AvatarData, no read permission, or auto-grant read on attach. Again, since it is permanent storage on avatar, we wouldn’t want it to be corrupted by a broken script. • In terms of documentation there should be caveats pointed out that the data can be reset at any time by the Residents and that it should not be used for storing any license key or authorization type data. • Should have a listener functionality (similar to chat listen) for specific key changes instead of an equivalent of linkset_data event, as we wouldn’t want to trigger loads of scripts on many different attachments with each change.

Second Life's interactive objects rely on LSL—a basic scripting language largely unchanged since 2003. This limits creators’ ability to build advanced, dynamic experiences. By introducing Lua, a powerful and widely adopted language, we can modernize scripting and unlock new creative possibilities. Broadens Second Life’s creator base to more easily include developers from Lua-heavy platforms (e.g., Roblox, Garry's Mod). Reinvigorates existing creators who’ve struggled with LSL’s limitations. Enables advanced features like mobile-focused development kits and robust 3D content manipulation (e.g., GLTF). Objectives New Audiences : Attract creators from popular Lua-based UGC platforms. Easier Scripting : Leverage Lua’s built-in features, large support community, and ample learning resources. Re-Engage Creators : Provide a smooth transition from LSL with bridging functionality, encouraging return visits. Advanced Features : Introduce long-requested language improvements (e.g., map-types, index operators). Richer Experiences : Allow for more complex, dynamic scripts to increase retention and drive engagement. Reduced Technical Debt : Replace LSL's difficult-to-maintain system with a modern, flexible alternative. Education Opportunities : Offer a full-featured language that helps new programmers build real-world skills. Links Lua FAQ - Read this if you have questions about "Why Lua?"