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

This function returns public metadata about an asset, and it is an essential component of scripting in Second Life! How essential? This functionionalty is not something we've lived without for 20+ years; instead, it is so critical that we have continuously needed to use store extra data and use larger LSL scripts--and more sim memory--to get around this missing function. These are each so essential that we all must constantly jump through data storing and loading hoops constantly to accomplish things like: Sound: Trivially, every game might eg, play a game-start sound, then loop the game's tune, then play the game over sound). Game controls etc might be tied to the timing of the music. But you can't do this in Second Life scripting without knowing the length of the sound files. We do silly things like notecards with the length info and we increase the size of a simple music-playing script significantly by adding dataserver handling. (And we lose a lot of flexibility to swap sounds, since we have to hard-code file sizes) Images: Re-texturing a surface and getting the aspect ratio and scale correct--again, we need to write down the size (width and height) of the asset. Particularly with PBR's different uv setup, we need to know if we have non-square images! Animations: Just like sounds, completely essential to know their length in order to string together sequences dynamically. Essential but unknowable, so we again hard-code or write data-loader scripts. Useage: So, I would like to see llGetAssetDetails return a list of elements related to the asset-type requested. For example, llGetAssetDetails(TEXTURE_PLYWOOD , ASSET_TEXTURE) would return a list of [512,512] Sound files would have the sound length Animation files would have play length (and maybe priority?) Benefit and consideration: The advantage to this system: if there's ever sufficient justification to add more details for an asset, tack them onto the list, it's pretty backwards-compatible. If there's justification to add another asset that has useful metadata, add an integer type. This data is needed but even better it's already not sensitive. Ironically, anyone and everyone can have it anywhere except Second Life. Eg, it is trivial to use the CDN api to fetch this info. (I just fetched the width and height of the Plywood texture in the example above using curl). The http request functionality in lsl cannot do this: the simulator blocks incoming datatypes that aren't text--eg, all the media files--with a 499 error and empty body. So, the alternative would be to run a proxy service that does this for people but...if the data is publicly available (it is) then why can't these pieces of metadata be used in-world? It would massively simplify dance/music/animesh/gaming etc. Future: Other assets might be interesting to fetch basic data about, like Notecard size (useful to know how many bytes before you try loading it). I think by establishing this function and having a signature that accepts UUID and which "type" of asset, we establish a flexible future-minded capability where any new asset metadata that can be proven to be both useful and safe to be known by all could be added without breaking past content. Technical challenges: Textures pre-2009 have the w and h written a little differently. The function, under the hood, would invoke 2 different methods. Sounds have the sampling rate and number of samples present, so the length is calculated rather than written in the metadata. I am unable to fit code for sound and textures (which I already have tested in Python) into this request, so...I'll reply to myself so you can see!

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.

Allow us to retrieve keys and/or data from the Experience KVP storage by passing a regex or pattern. Example: an experience KVP contains the following keys (key, value): player_(some_uuid), "Player Name" player_(another_uuid), "Another Player" player_(yet_another), "Third Player" level_1, "SomeLevelDescription" level_2, "AnotherLevelDescription" level_3, "AndHereIsAnotherLevel" Now I do something like: searchRequest = llSearchKeyKeyValue("player_.*", 0); or: searchRequest = llSearchValueKeyValue("Player Name", 0); and retrieve the result in the dataserver event as usual. Why would this be important? Given the example, if I want to display or count all player names, I have to read through the whole storage and filter the "player_.*" entries "manually", which takes a lot of time if you have a big KVP storage and are only interested in a small subset of keys / data. This functionality would greatly simplify and accelerate scripts that deal with mixed data inside an experience KVP storage.

hi, has anyone ever asked for a function called llGetGroupKey(key id);? A function like this would make it easier for many stores to rez group gift giver in any group instead of the landholding group. llSameGroup & llDetectedGroup are not an option if it is group owned land and the store uses a different group. LG Dae

Currently the function rotates the avatar and camera, I think it would be useful if we had a flag to enable or disable the camera being rotated with the function. llSetAgentRot(rotation rot, ROTATE_CAMERA); I Believe this would add useful functionality

Any user can get this information through their viewer, and rightly so as you're connecting with an external server and should be able to know where. I'm not sure what we're protecting by restricting access to this information to land owners only in LSL, but it'd be a useful thing to be able to get without requiring manual button clicks in the viewer.

I've seen a rise in griefing tools being used as the hangout I run gains popularity and I've had to create a number of automated security tools to combat them so that the peace & comfort of my patrons is minimally interrupted by griefer attacks. The only problem is that due to imposed limitations on various functions, at best these security tools can only intervene retroactively & my patrons are still subjected to these attacks. If it were possible for me to get information on visitors worn hud attachments without needing them to opt into an experience (and requiring the hud attachment to also be scripted for the experience), then I could prevent these attacks nearly every time by booting visitors wearing items made by blacklisted users and such. But as it is now, griefers can still get away with carrying out an attack due to the loophole of attaching a griefing tool to their hud instead of their avatar, thus avoiding detection until they're put to use. Allowing the full use of the llGetAttachedListFiltered() function for estate managers without the experience requirements seems like a fair way to prevent abuse of the function while also allowing for more robust land security tools to be made.

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