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

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.

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.

I'm posting this here since my original post as a bug was closed with an "expected behavior"-type reply. As referred to by the discussion mentioned in the LSL portal documentation for llGetLinkPrimitiveParams() ( https://community.secondlife.com/forums/topic/486118-only-set-ambiance-on-prim_projector/?_gl=11wd89ez_ga_T7G7P6DCEC*MTcwNjU2MzkwNS4xLjEuMTcwNjU2MzkwNy41OC4wLjA.#comment-2446570 ) the call with PRIM_PROJECTOR currently triggers shouting on the DEBUG_CHANNEL about an unsupported parameter. I understand that PRIM_PROJECTOR is considered, for now, as write only, but I see no valid reason why it could not be readable at all. The current situation is inconsistent in my opinion. While I understand the potential problem with texture rights, I believe the behavior of this parameter should be consistent with that of PRIM_TEXTURE: if the texture is in the prim's inventory, return its name, else if the owner has full permissions over the object return its UUID. Otherwise return NULL_KEY. This is important to be able to "copy" a user-set parameter from one object to another for example, I want to read the parameters and send them to another object. Please make PRIM_PROJECTOR behave just like PRIM_TEXTURE in this regard, as described in the discussion. Thanks!

Please consider adding an endpoint to the map API for fetching data useful for navigating the grid. This data would be readily available map information. At the present, this is a very, very strange task to accomplish. We can pound LL's servers using this API: https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=region&grid_x=1000&grid_y=1000 And scanning every possible range of coordinates we think is useful. Or We can use a bot on a custom viewer, making MapBlockRequests until we've got the whole grid. Each of these really need an external service running, and hit your servers pretty hard--but it's all for information that you already have that would be valuable to us to use for scripted applications (eg for navigation HUDs, custom maps, games with distributed locations, exploration apps, touring pods) and also, just in general to know how our world is doing. Proposal: Two https endpoints to fetch paginated region info lists. First API endpont: region list by number. The order is determined by LL and is arbitrary, but is used for pagination. A script can ask for the first N regions, then another set of regions starting from N and so on. In this way, scripts can parse the region list without hitting the api server, sim, or script memory too hard Second API endpoint: region list by name. Similar to searching a word on the map and getting one or several regions that match the name. Responses are delivered as JSON, with each region'd details in an object of the following form: { { "name" : "Da Boom", "coordinate" : "<1000.0, 1000.0, 0.0>", "estate_name" : "mainland", "region_map_image" : "7963f194-82f9-23b3-3d89-c21f1bd0a8bc", "access_name":"Moderate" } } Example of using the first endpoint, the enumerated API: The endpoint can be called with a page number, and an optional maximum. For example, suppose we are permitted up to 25 list items in a single call: Example: Fetch default 25 items starting with the 437th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=437 Example: Fetch only 5 items starting with the 75th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=75&length=5 In this way, external services we write and LSL code in-world could reasonably work with the large list of region data in a way that doesn't flood the API (feel free to rate limit) and that permits us to work within script memory limits. Example of using the second endpoint, the named API: The endpoint is called with a search term, and returns one or more regions that have a name starting with the term. There should be a minimum character limit. Ecample: Fetch regions starting with the name "Da B" https://cap.secondlife/com/cap/NAME_ENDPOINT?search=Da%20B Summary: There are many standing requests for access to the map tile information, map region names, and map grid coordinates, all in separate feature requests. I propose this API mechanism to capture data you already have in a way that solves every request.

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.

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.

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

Per https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/ This is putting the respawns part of what Rider had drafted up as a proposal into a feedback. The Teams portion of the draft is available at: https://feedback.secondlife.com/scripting-features/p/combat-21-teams Respawns builds upon Teams. Adding additional mechanisms to support reliable server-side respawns. That means that Teams can be built as a feature first and Respawns can be considered and built in after. Respawns have a current viable workaround with Experience but Teams are a more fundamental issue that all of SL can benefit from beyond SLMC but also Games and RP sims. --- Currently respawns can only be done through Experiences. Setting the DEATH_ACTION to disable server-side checks and teleportation. Instead upon avatar death, an experience manages via scripts the teleportation to a respawn. But as shown in the Teams proposal, there are many difficulties around identification, checks and logistics. For reference the current implementations either work via Combat Log, observing DEATH events to then teleport an individual to respawn. Or via temp attachment HUDs that rely on on_death to then trigger a teleport to respawn. --- So I would like to see Rider's implementation of Respawns. Which builds upon Teams to enhance it further. See the thread for more details: https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/

Particle system sorely need an overhaul and additional settings to make the best use of it. I've broken up a list of features to make tracking for each one easier for the devs. Texture Animation for ParticleSystem Easing Interpolation for ParticleSystem Alpha blend mask mode for ParticleSystem Color Noise for ParticleSystem Reverse Target for ParticleSystem Emissive Interpolation for ParticleSystem Select Sprite for ParticleSystem Offset Position for ParticleSystem PBR for ParticleSystem "MID_" Flags for ParticleSystem Follow a chosen attachment point