Scripting Features

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

Scripters have long bemoaned the limitations of llStartAnimation and llStartObjectAnimation , and proposed a number of enhancements. It could be a lot better with only minimal changes to the simulator and the simulator-viewer protocol. Here are examples of great enhancements that could be made by just sending a little bit more data to the viewer along with the llStartAnimation message. To illustrate, I will name the new functions: llStartAnimationWithParams llStartObjectAnimationWithParams 1. Queuing When I ask others how the animation system is lacking, the most common complaint is Queuing one animation to play after another. Now, a script can send the viewer the message: llStartAnimationWithParams(anim, [ANIM_QUEUING]); When the viewer receives this message, it will do one of the following: If the avatar has no other active animation marked ANIM_QUEUING , it will play the animation normally Otherwise, the viewer will delay the animation start until all earlier ANIM_QUEUING animations on that avatar have stopped, either from ending, or by calling llStopAnimation . Caveat: This will currently not work well on Animesh, because animesh animations never automatically stop. I find this caveat acceptable. This is similar to the existing sound function llStartSoundQueuing . 2. Syncing This one is near to my heart. A script is animating two or more avatars. It designates one of those avatars as the leader: llRequestPermissions(leader, PERMISSION_TRIGGER_ANIMATIONS); llStartAnimationWithParams(leader_anim, [ANIM_SYNC_LEADING]); It designates the other avatars as followers: llRequestPermissions(follower, PERMISSION_TRIGGER_ANIMATIONS); llStartAnimationWithParams(follower_anim, [ANIM_SYNC_FOLLOWING, leader]); When the viewer is asked to start an animation marked ANIM_SYNC_FOLLOWING , it: Downloads the animation Waits until any leader animation marked ANIM_SYNC_LEADER encounters a loop point (including waiting until an ANIM_SYNC_LEADER animation is started at all) Starts the animation normally This is very similar to these existing sound functions: llLoopSoundMaster llLoopSoundSlave llPlaySoundSlave It would be up to the animator to create animations suitable for syncing. Synced animations should usually: Have identical loop durations Have no loop-in period The most flexible leading animation will be 0 priority and an animate zero bones; providing nothing but a looping beat. This is also true of llLoopSoundMaster ; The best master sounds are silent. 3. Property overrides Animation assets have a number of parameters you can set at upload time, but can't be changed afterward. It would sometimes be nice if you could change them, and, llStartAnimationWithParams provides a convenient place to override them. The most useful ones to override would be: ANIM_PRIORITY ANIM_DURATION ANIM_EASE_IN ANIM_EASE_OUT 4. Speedup Similar to ANIM_DURATION above, but, speed up the animation by a constant factor, regardless of the asset's native duration: llStartAnimationWithParams(anim, [ANIM_SPEED, 2.0]); // Double speed = half duration llStartAnimationWithParams(anim, [ANIM_SPEED, 0.5]); // Half speed = double duration 5. Blending Allow an animation to not fully replace any channels in animations in overrides, but, linearly blend the bones between this animation, and the next-lowest one in the animation stack: llStartAnimationWithParams("breathing", [ANIM_BLENDING, 0.1]); This one would require the most changes to the viewer, but would open up new ways to animate characters, and would often allow multiple animations to be consolidated together more flexibly Summary I hope you can consider this proposal. I considered it carefully so that it can be implemented with minimal changes to either simulator or viewer. I heavily limited the scope, so it has a clear end point, unlike Puppetry: It does not require changing the animation asset format It does not require any new viewer -> simulator communication, beyond the existing message "hey this animation ended". It does not require the simulator to download or understand animation assets. It does not require new simulator -> viewer communication. It only adds a few new fields to the existing "animation started" message llStopAnimation and llStopObjectAnimation require no changes

The llTextbox function is frequently used to enter parameters as values or text. It could be useful to prefill the text field with the previous parameter especially if it's a long text. Example, this previous sentence was entered: "The quick brown fox jumps over the lazy cat." and need to be fixed. Currently, for edit it, I need to put the sentence as message in llTextbox. Then, copy it from the box label and paste it in the field. With the llFilledTextbox, the field would be prefilled with the sentence. Also, a text size extended to 512 characters would be welcome. To finish, the field needs to take the focus when the box is showed.

Background and Motivation: LSL provides llCreateLink, llBreakLink, and llBreakAllLinks for scripted linking and unlinking of objects. Before any of these may be called, the script must hold PERMISSION_CHANGE_LINKS, obtained by calling llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS). This causes a dialog to pop up at runtime, asking the owner of the object whether to allow it to link and unlink things. Only the owner can grant this permission, and it must be requested and granted each time the script resets. This model is correct for its original purpose: a script inside one object is trying to reach out and attach itself to any other object in the world. The permission answers the question: "Do you, the owner, allow this specific script, right now, to perform linking operations?" The Analogous Script Pin System: Second Life already includes a beautifully designed precedent for pre-authorizing cross-object operations: the llSetRemoteScriptAccessPin / llRemoteLoadScriptPin system. A creator places a script inside a target prim that calls llSetRemoteScriptAccessPin(pin). A calling script then passes that same pin to llRemoteLoadScriptPin to inject scripts into the target — no runtime dialog, no owner prompt. The permission was established ahead of time , by someone who had modify rights to the prim, when they placed the pin-setting script inside it. The pin is the credential, and possessing it is the grant. The key insight: A link pin system would allow objects to be 'set up to accept linking' in the same way that script pins allow objects to 'set up to accept remote script loading'. The hard permission work is done at configuration time by someone with mod rights, not at runtime by an owner who may not be present. The Problem This Solves • It requires the owner to be present and attentive when the script runs, even if they already "authorized" the behavior by crafting the product. • It makes fully-automated, physics-driven, or time-triggered linking impractical in products where the owner is not online. • It introduces UX friction that discourages creative use of a powerful simulation feature. • It is conceptually mismatched to the scenario where both objects were built by the same creator specifically to work together. The linking permission was designed for open-ended scenarios : a script that might try to link anything to itself. The proposed link pin is for closed scenarios : specific objects that have been explicitly configured to participate in a linking relationship. Backwards Compatibility Placing a link pin requires mod rights. Objects with mod rights can already be linked/unlinked without scripting. Link pins do not elevate capability — they only reduce the runtime friction for capability the creator already possesses. The new functions are additive. Existing calls to llCreateLink, llBreakLink, and llBreakAllLinks are completely unchanged. Scripts that currently request PERMISSION_CHANGE_LINKS via the dialog continue to work exactly as before. No existing behavior changes. Objects without a link pin set cannot be linked or unlinked by the new pin-based functions. An object that was never given a pin is invisible to the new mechanism. Spec • The pin is a 32-bit integer. Creators should treat it as a private shared secret between the orchestrating script and the pin-holding object. • A pin of 0 means "no pin set" (cleared state). Setting a pin of 0 removes any existing pin. • Both objects must still be owned by the same person. The pin bypasses the dialog, not the ownership requirement. • A prim's pin persists across link and unlink operations (same persistence model as llSetRemoteScriptAccessPin). • A creator can change or clear a pin at any time from within the object by calling llSetLinkPin again. llSetLinkPin(integer link_number, integer pin) Attempts to link the calling object to target, using pin as the authorization credential in place of a runtime permission dialog. The target's root prim must have a matching link pin set (via llSetLinkPin). Both objects must have the same owner and both must be modifiable. If the pin does not match, or the target has no pin set, the call fails silently (no error is shouted). llCreateLinkPin(key target, integer parent, integer pin) Attempts to link the calling object to target, using pin as the authorization credential in place of a runtime permission dialog. The target's root prim must have a matching link pin set (via llSetLinkPin). Both objects must have the same owner and both must be modifiable. If the pin does not match, or the target has no pin set, the call fails silently (no error is shouted). llBreakLinkPin(integer link_number, integer pin) Breaks the link of a prim identified by link_number from the current linkset, using pin as the authorization credential. The targeted child prim must have a matching pin set. This is called from the root/parent prim's script, not from the child being removed.

Add the ability to receive input from game controllers such as joysticks, Xbox controllers, etc. This will allow the creation ofhHelicopters and planes that use analog input from console controllers, attachments that control drones, arcade games, cranes, machinima puppetry, etc. This new feature will be implemented by adding a LSL event game_control(...) which script authors can use to capture and respond to input from users. For further details, see https://wiki.secondlife.com/wiki/Game_control

Pretty simple request: llClamp(integer val, integer min, integer max)

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.

Akin to llRequestPermissions, but allows for revoking of permissions. Can be coupled with either the existing run_time_permissions event or with a new event.

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.

A function to be able to pull the preview image of an item in an object Inventory I feel this can be useful for all types of options. If the preview images are part of the objects now, being able to display them will allow for a whole set of options, such as vendors with the preview image already set from the object itself or a rez box that shows what it rez with minimal setup on it. The texture is already in-world, and it is already attached to the object, so this seems like something useful to have