Scripting Features

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

As a creator, I was trying to make a new user experience with a HUD that docks UI elements to the left or right side of the screen. I was using llGetCameraAspect to figure out the width of the screen. However, I discovered that it is impossible as a creator to dock my UI to either side of the screen accurately. The problem is that the viewer can have Toolbar Buttons that are docked to the sides of the screen. When these are docked, the 'aspect' of the viewport is changed, but llGetCameraAspect does not reflect it. This means that UI elements get covered up by docked Viewer UI. Being unable to accurately dock HUD UI elements to the side of the screen limits the types of experiences I can build and the quality at which I can build them. I want to meet the higher quality expectations of our new generation of players joining us in 2026 who have grown out of platforms like Roblox where such UI issues do not exist. I would like a function that can tell me what area of the viewport is unobscured by docked toolbar buttons. This way I can calculate where to place my HUD elements more accurately adapting to an individual users viewport.

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);

Suggested a method to reply to a http_request with the contents of a notecard with some simple templating options. llHTTPRespondWithNotecard(request_id, notecard_id_or_name, list_of_tokens_and_substitutions); request_id being the key of the request notecard_id_or_name being a natecard key or name of one in the objects inventory list_of_tokens_and_substitutions being a strided key value pair list of tokens to substitute in the notecards content e.g A script doing http_request( key request_id, string method, string body ) { llHTTPRespondWithNotecard( request_id, "content", [ "%%A%%", "Hello", "%%B%%", "World" ] ); } With a notecard in it's object inventory called "content" containing %%A%% %%B%%!!! %%A%% %%B%%!!! %%A%% %%B%%!!! Would serve the http content of Hello World!!! Hello World!!! Hello World!!! To the request. This sort of feature was discussed a few times a Simulator User Groups

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.

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.

There is currently a lot of debate on how to improve driving, sailing, and flying experiences through mainland where those individuals may have to either deliberately or inadvertently find their way onto a privacy focused parcel during their recreational vehicular activities. The argument is currently focused around the preservation of privacy vs. the desire to not be sent home via teleport for a momentary and potentially unavoidable encroachment onto a private parcel. A solution that could serve both sides of this argument was proposed by omoMMomo Resident as a comment and expanded upon by me. Due to how this may actually solve both sides of the problem without causing either side to "lose" anything, I felt the proposal deserved it's own canny post to discuss and upvote as needed . Here is the original pitch within the comments: Original Proposal (with edits/updates) The ability to place a static volume (box, cylinder, sphere) tied to a list that separates the residents living there (listed) from the residents passing through (unlisted), as though two dimensions occupy the same space; similar to how private parcels do it except access will not be denied. It might be worth exploring if this is possible without having to modify the clients (viewers). Listed residents will not be disturbed because they cannot see/hear unlisted (and vise-versa) (including media). Unlisted residents can navigate through the property without hassle. hide objects (like cars, planes, boats) of residents that are unlisted from the listed ones.* disallow unlisted residents from interacting (touch, sit) with any prims within the volume.* prevent unlisted residents (on the same parcel) from IMing listed residents while inside the privacy area.* Like this, everyone can be happy. Those that want privacy get their privacy. Those that want to explore get to explore. Such a system could replace and obsolete existing systems for privacy (parcel rules, ban lines, llEjectAgent() , etc.), modernizing and simplifying the whole concept going forward . * - Edits to the original proposal. Expanded Proposal As was mentioned, I liked the idea of this proposal and added to it with my own thoughts on how an implementation might work: To expand on the original proposal, in the spirit of what the 'volume' or "prim" bordering suggests, perhaps we can utilize something similar to the EEP system that allows for different environments at different levels. Instead it would allow for different privacy permissions at different altitudes. Starting from 4096m, as that is the highest one can rez anything, every 'entry' that is added encompasses the space from the next highest entry down to the present entry, at which the new policy/privacy preference takes precedence (the reverse of the environment system). It could incentivize folks to use their land and space in new ways. Say someone wants to have a portion of their parcel be public, but wants a private space for just their friends. They set everything below 3000m public and then everything from 4096m - 3001m is private, subject to the limitations you suggested. I think that would be a win, and based upon the other logic within the original proposal, it would make the space from 4096-3001m still passable, but they couldn't interact with the individuals or objects inside of that space and vice versa. I did a small mock up of what that could look like. I also like this idea for the other fact that you could essentially do a 'block and derender' of someone through the land without listing them. They still get to pass through, but unless you've got radar or your mini-map up, you'd be none the wiser. Assumptions I want to make note that this change if made would have some assumptions around it: This would apply solely to mainland regions. Parcel Bans would still be effective for those that need them (for public parts of their space, for instance). Modifications may need to be made to parcel access lists to work more like estate access lists where they can accept both groups and people. This implementation would also go in line with changes to how llTeleportAgentHome() works within mainland, to help solve the original problem stated above. Thank you for taking the time to read this proposal.

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.

Add a new function LSL function named llRenderText or similar, which allows users to dynamically render text, with limited but flexible formatting, onto the face of their choosing. Concept: // Signature llRenderText(integer face, string text, list params); // Basic example llRenderText(ALL_FACES, "Lorem ipsum...", [ FONT_ALIGN, "right", FONT_WEIGHT, "bold", FONT_FAMILY, "sans serif" ]); Rationale Text is ubiquitous, yet Second Life has no way for users to display text other than uploading a texture, setting floating text using llSetText , or using relatively resource intensive solution such as XyText/Furware/et al. This absence precludes interesting features, such as being able to create a responsive interactive terminal in Second Life, HUDs with dynamic text, etc. A scripted and efficient text solution that displays on the face of a prim/mesh would give Second Life the biggest bang for the buck: Limited in scope (easier to implement than grand UI-creation ideas) Easy to kitbash into existing and new creations For inspiration, you can look to how the Text Display widget is implemented in the Playstation game Dreams. It has limited options: a finite number of fonts and formatting options, but the fact that it can be combined with other content makes it rather powerful. Other details Font color, opacity, glow, etc are controlled by prim properties (Example: setting face color to red sets font color to red) Questions Should the background always be transparent? Creators could put another prim behind the text display face to give it a background, or it could be a property of the render params. Possible Parameters FONT_WEIGHT FONT_STYLE FONT_FAMILY FONT_VERTICAL_ALIGN FONT_HORIZONTAL_ALIGN FONT_TEXT_WRAP FONT_LINE_HEIGHT FONT_SIZE Possible Features Markdown / rich text

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