Scripting Features

Add "received by" metadata for inventory items inside objects/attachments. Create llGetInventoryGiver() function to read giver key. Giver key is known by the server when the viewer sends ImprovedInstantMessage. Giver key is known by the server with every use of llGiveInventory(). Inventory prior to code implementation returns NULL_KEY. A viewer UI element for the Item Properties floater is not needed at this time.

Currently, llGetHTTPHeader() is limited to parsing only a dozen different header options, which makes it difficult to use for some applications. I'd like to be able to manually implement support for the 'Range' header, as well as others for authentication. Notably the corollary for HTTP clients, HTTP_CUSTOM_HEADER, _can_ set arbitrary headers.

I propose adding a new click action, CLICK_ACTION_TEXT_INPUT When an object with this attribute is clicked, A floating textbox will appear in the center of the user's screen. The textbox will be focused so the user can begin typing immediately. The contents of the textbox will be whatever hovertext (ie. llSetText) for that link is set to. Once the user presses enter to submit, we will get a CHANGED_TEXT event. The text will be stored in Hovertext in whatever color/alpha was previously set (default transparent). We will retrieve the text with the existing llGetText function This solves a few problems at once:- The existing llTextBox is too clunky to use for frequent text inputs, requiring the user to focus the box each time, which appears in an unintuitive location. Gets rid of the need for listeners and timers to close listeners for text input which often lead to user frustration Gets rid of the need to bring user input immediately into memory It makes it practical to do huds that take text input like Live Product/Community search huds HEX inputs Noticeboard Systems With SLua's release getting closer I think this feature would also pair particularly well with https://github.com/Martin-Pitt/NexiiText4/tree/main Martin Pitts NexiiText - Which can do proper text rendering on a prim with proper kerning etc. My personal desire is to make a mini editable wiki directly in SL using this feature request combined with NexiiText 😊

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.

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.

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

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.

Currently, we have no way to rotate the avatar. This function would rotate the owner of the script on the Z-axis and would work as an attachment. With this, we can rotate the avatar to the surface normal of a wall, table, or other avatars without the need to use RLV functions that manipulate the camera or having to sit and unsit the avatar. This would allow for things like wall climbing and a host of other useful applications. https://gyazo.com/7d441967232c304a4fa20ce722ec18ce rotation RotNormal(vector _normal){ vector vLeft = llVecNorm( _normal % llRot2Fwd(llGetRot())); vector vFwd = vLeft % _normal; rotation rRot = llAxes2Rot(vFwd, vLeft, _normal); return rRot; } wall_climb() { vector scale = llGetAgentSize(owner); vector vStart = llGetPos() + <scale.x/2,0,scale.z/2> * llGetRot(); vector vEnd = vStart + <0.25,0,-1.0> * llGetRot(); list CN = llCastRay(vStart, vEnd, [RC_DATA_FLAGS,RC_GET_NORMAL, RC_MAX_HITS, 1]); float FW_Dist = llVecDist(vStart,llList2Vector(CN, 1) + <scale.x/2,0,0> * RotNormal(llList2Vector(CN, 2))); /* Set the position and agent rotation to the surface normal of the detected object. */ }

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.