Scripting Features

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

Users regularly grant their friends edit permissions in order to let their friends help them edit their stuff or setup a home or something. Then that user can't edit half the objects in the house fully because they require setup or configuring through a script menu or similar. Most of these scripts use if(llDetectedKey(0) == llGetOwner()) or similar for this kind of access check, if they don't want to implement a full access list system. llSameGroup can sometimes be used, but isn't really workable as it'd be too broad in many situations. Exposing a check for what the script actually wants to know, is this user allowed to change me, would let scripts provide a much more seamless and expected behavior from the point of view of a user. I propose a function that operates something like this. integer AGENT_CAN_MOVE = 0x1; integer AGENT_CAN_EDIT = 0x2; integer perms = llAgentPermissionsOverObject(agent_key); if (perms & AGENT_CAN_MOVE) llSay(0,"Agent can move object"); if (perms & AGENT_CAN_EDIT) llSay(0,"Agent can edit object"); Taking into account the objects status, being possibly, everyone can move, no mod, locked, attached, etc. Further flags like, AGENT_CAN_RETURN could be implemented over time, but an initial version should probably implement at least 2, to prevent people using it as a boolean response.

Basically it does the same as putting a script with llSetRemoteScriptAccessPin in the object's on_rez Right now if you have a project that relies on updating scripts of rezzed objects, you'll need to make a script that sets the pin and requests an update via the llSay system. This makes said script a major failure point because llSay has a tendency of being dropped during lag spikes, forcing you to set up a syn/ack system. And if you later discover that your syn/ack system wasn't as robust as you thought, or want to change it in any way, you may potentially have hundreds of items that you need to manually rework. Being able to set the remote script access pin directly on rez would eliminate the need for a syn/ack system entirely. Because you could: Rez object with pin Remote load the script(s) immediately in object_rez Profit! Another added benefit of this system is that you could rez the object without the scripts that you intend to overwrite with remote loading, saving time rezzing the object.

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

Currently, the only way to attach an object is to rez it in world and then have the object call llAttachToAvatar or llAttachToAvatarTemp. Could we have new functions can directly attach an object from the inventory of the object the script is located in? For example: llAttachInventoryToAvatar(string inventory, integer attach_point) llAttachInventoryToAvatarTemp(string inventory, integer attach_point) The PERMISSION_ATTACH permission will still be required with the destination avatar determined based on the permission - same as how llAttachToAvatar and llAttachToAvatarTemp works today. Having these new functions improves the main use cases - a store could directly attach a demo product to an avatar without having to first rez it somewhere in the store. A roleplay sim could attach temporary items to players. Vehicle HUDs could be attached when driving. The current 'rez in world first' requirement causes the object to flash in world or require other strange workarounds. If there are potential security concerns (e.g. guests without rez access trying to cause trouble) then this new functionality could require parcel rez access, even though it wouldn't be directly used.

When using Combat 1.0 weapons, the on_damage() event caps at the 32 limit, but further damage is still processed. This makes it impossible to prevent death using llAdjustDamage and on mainland, that means they get sent home. My fastest attempt at preventing this only works 50% of the time. We've asked to remove the Teleport Home on Death option for our sim, but were denied. We'd like to control combat deaths ourselves through Experiences, but cannot with mainland rules. Acceptable solutions: * Increase the event queue to 64 for on_damage() // Maybe sufficient * Stop processing damage after it hits the event limit // Absolutely sufficient Either of these would allow us to use the new Combat 2.0 system in role-play situations without needing any mainland estate setting changes.

key llGetRegionWorldMapTile(string region_name) A LSL function to return the UUID of the current world map tile for a named region, so that it might be placed on a face using PRIM_TEXTURE. This could also be added to llRequestSimulatorData Currently the only ways I know to accomplish this depend on MOAP and voodoo to get an image from slurl.com , or pulling the CDN UUID from gridsurvey.com via a HTTPRequest. Which all seems pretty hacky and unfun.

Related issue: https://feedback.secondlife.com/feature-requests/p/add-support-for-prim-link-target-to-llsetlinkgltfoverrides Given the command structure of llSetLinkGltfOverrides, if the related issue is merged it may be useful to be able to swap which face (or, ALL_SIDES) is being worked on after the initial selection. Unlike llSetLinkPrimitiveParams , the face selection does not happen within the parameter list, instead happening at initialization of the command, so give the user an option to swap which face is being targeted after initialization.

Currently, llSetLinkGltfOverrides takes a link number parameter. In some programming paths, it's useful to then be able to swap to another link number within the same function call. llSetLinkPrimitiveParamsFast already supports this path by way of PRIM_LINK_TARGET , which allows the command to select another link to work on. This should also be supported by llSetLinkGltfOverrides

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