Scripting Features

We currently don't have a way for scripts to know if bots are allowed or not in a region. Please add "deny_bots" to llGetEnv(). This should point to the same value set by the parameter of the same name in the region console. Thanks.

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.

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 😊

Several of the body vendors include scripts to change the shape of the foot to match the shoe being worn from flat footed to on tip-toes. But when the foot shape changes, the avatar is left hovering in the air, or sinking into the ground and the hover height needs to be manually changed to reflect the new food position. I suggest adding a new LSL command to alter the hover height of the avatar. Thus: llSetAgentHoverHeight(key Agent, float Distance) ( edit to add a key field to the command. Not surf if it would needed or not. but the the behavior that if the agent key is not also the owner key that the command is either ignored, or an error is shouted on the debug channel ) The distance can either be a fixed value, or a relative value based on the current hover value. Examples. When I stand barefoot, my hover height is "0.06" -- as shown on the "Avatar > Hover Height > Set Hover Height" slider. But when I'm wearing heels my hover height is "0.170" So the "llSetAgentHoverHeight" would either need to set the static values of 0.06, 0.170, and any other needed values for the shoes in question, or adding (+0.102) to the "current' value when putting on heels, and subtracting (-0.102) from the 'current' value when putting on flats. The actual values, either static or relative would need to be established either by the shoe maker, or the shoe wearer, depending on how the script maker decides best of course.

Add a new method for material animation. This function would allow for independent channel animation on different faces of the same link or faces throughout a linkset. Rules for a material channel override containing an empty list are not animated. New/Improved Mode Flags: ANIM_ON: Starts the animation. LOOP: Repeats the animation indefinitely. REVERSE: Plays the animation backward. PING_PONG: Alternates between forward and backward animation. SMOOTH: Provides smoother transitions between frames. ROTATE: Rotates the texture map (e.g., for rotating textures). SCALE: Animates texture scaling. BLEND: Cross-fades between frames for smoother transitions. RANDOM_START: Randomizes the start frame in the animation sequence. SYNC_ALL_LINKS: Synchronizes animations across all linked objects. SYNC_CHANNELS: Synchronizes animation material channels. ie base, metallic, normal, emission. FRAME_BLEND: Allows frame blending (interpolation between frames). The material rules would contain the following: string material_UUID: Defines the texture asset to be used for the material. integer size_x: Defines the grid size (for sprite sheet-based animations or texture tiling). integer size_y: Defines the grid size (for sprite sheet-based animations or texture tiling). float start: Start position in the animation cycle. float length: Length of the animation cycle. float rate: Speed of the animation. float transition_time: Optional parameter for smooth transitions between frames. Example Useage: // Define mode flags integer mode_flags_face_0 = ANIM_ON | LOOP | SMOOTH | SCALE; integer mode_flags_face_1 = ANIM_ON | LOOP | REVERSE | PING_PONG; integer mode_flags_face_2 = ANIM_ON | LOOP | SMOOTH | ROTATE | FRAME_BLEND; // Animation rules for face 0 (Base Color, Metallic, Normal, Emission) list base_color_rules_face_0 = ["UUID-of-BaseColor-Texture", 4, 4, 0.0, 1.0, 0.5]; list metallic_rules_face_0 = ["UUID-of-Metallic-Texture", 2, 2, 0.0, 1.0, 0.8]; list normal_rules_face_0 = ["UUID-of-Normal-Texture", 3, 3, 0.0, 1.0, 1.0]; list emission_rules_face_0 = ["UUID-of-Emission-Texture", 4, 4, 0.0, 1.0, 1.2]; // Animation rules for face 1 (Base Color, Metallic, Normal, Emission) list base_color_rules_face_1 = ["UUID-of-BaseColor-Texture2", 3, 3, 0.0, 1.0, 1.0]; list metallic_rules_face_1 = ["UUID-of-Metallic-Texture2", 3, 3, 0.0, 0.5, 0.5]; list normal_rules_face_1 = ["UUID-of-Normal-Texture2", 3, 3, 0.0, 1.0, 1.0]; list emission_rules_face_1 = ["UUID-of-Emission-Texture2", 3, 3, 0.0, 0.8, 1.2]; // Animation rules for face 2 (Base Color, Metallic, Normal, Emission) list base_color_rules_face_2 = ["UUID-of-BaseColor-Texture3", 5, 5, 0.0, 1.0, 1.0]; list metallic_rules_face_2 = ["UUID-of-Metallic-Texture3", 5, 5, 0.0, 1.0, 1.5]; list normal_rules_face_2 = ["UUID-of-Normal-Texture3", 5, 5, 0.0, 1.0, 1.0]; list emission_rules_face_2 = ["UUID-of-Emission-Texture3", 5, 5, 0.0, 1.0, 1.2]; // Set animations for face 0 llSetLinkMaterialAnim(2, 0, mode_flags_face_0, base_color_rules_face_0, metallic_rules_face_0, normal_rules_face_0, emission_rules_face_0); // Set animations for face 1 llSetLinkMaterialAnim(2, 1, mode_flags_face_1, base_color_rules_face_1, metallic_rules_face_1, normal_rules_face_1, emission_rules_face_1); // Set animations for face 2 llSetLinkMaterialAnim(2, 2, mode_flags_face_2, base_color_rules_face_2, metallic_rules_face_2, normal_rules_face_2, emission_rules_face_2);

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.

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

New LSL function that allows scripts to toggle an object’s Animesh property state at runtime. llAnimeshEnabled(integer enabled); ## Overview Currently, enabling Animesh on an object significantly increases its land impact, even when the object is idle. In contrast, a comparable non-Animesh object—especially one with well-optimized geometry and materials—can often remain at a land impact of 1. At the same time, Animesh animation itself is already fully script-driven. Functions like: llStartObjectAnimation(string anim) llStopObjectAnimation(string anim) llGetObjectAnimationNames() allow scripts to control animation playback dynamically. However, these functions only operate after an object is already in an Animesh-enabled state. This creates a structural limitation: creators can control what an object does, but not whether it needs to be Animesh at all at a given moment. ## How Animesh Currently Works Animesh objects function by associating a skeleton with a rigged mesh linkset. When a script plays an animation, the skeleton drives deformation of the mesh. Importantly: An object does nothing by default when set to Animesh Animations must be explicitly triggered via script The visual position of the mesh is driven by the skeleton and active animations, not strictly the object’s base transform This means Animesh is fundamentally an on-demand animation system , but it is currently forced to be always enabled at the object level , regardless of whether animations are playing. ## Problem There is currently no way to: Disable Animesh when no animations are running Return an object to a low land impact idle state Dynamically enable Animesh only when animation is required As a result, creators must choose between: Keeping Animesh permanently enabled (high land impact, unnecessary overhead) Building complex systems involving object swapping, rez/re-rez logic, or duplicate assets ## Use Case There is a strong need for objects that can dynamically transition between static and animated states. For example: A robot or pet that remains dormant until activated Creatures that only animate when a user is nearby Props that “wake up” briefly to perform an action Environmental elements that animate only during interaction In all of these cases, the object does not need continuous skeletal evaluation. ## Expected Behavior enabled = TRUE - Enables Animesh on the object - Allows use of llStartObjectAnimation and related functions enabled = FALSE - Disables Animesh - Stops all active animations - Returns the object to static mesh behavior - Restores lower land impact where applicable ## Benefits Land Impact Optimization Objects only incur Animesh cost when actively animating Performance Efficiency Reduces unnecessary skeletal evaluation on idle objects Cleaner Content Architecture Eliminates the need for duplicate objects or rez-based workarounds Better Alignment with Existing API Design Complements existing animation control functions by adding missing state control ## Additional Considerations State transitions should preserve: - Object transform - Linkset integrity - Script execution state Simulator safeguards may be needed: - Throttling or cooldown on toggling - Permissions checks to prevent abuse Documentation should clarify: - Effects on physics and collision - Bounding box changes - Interaction with pathfinding and attachments

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.