Scripting Features

Ability to teleport a vehicle like a sim crossing, but to arbitrary grid coordinates. Something Like llTeleportVehicleGlobalCoords(vector global_coordinates, vector region_coordinates, rotation direction ); Should either obey the current allow object entry or a new parcel setting "Allow Remote Object Entry"? . Object should be returned to inventory if the parcel teleported to is set to no entry. Possibly only available if object has a seated avatar? Don't really need teleporting objects. This would probably need to be an experience function. But this could lead to heavy fragmentation and incompatible portals. Seeing as gridwide experiences aren't real, and a script in a vehicle would need to have the correct experience for the land its one etc.... Leave behind avatars that have not accepted the experience? A script could give users that haven't accepted the experience a map link to follow along after.. Mostly this would allow for road tunnels for vehicles to other places, spreading the SL road network and increasing connectivity.

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

There are many animations out there which were uploaded with a low / default priority. These are fine provided other overlayed animations running at the same time don't override their actions. It would be useful to be able to change that priority when starting the animation. eg: llStartAnimationPriority("animation", 6);

This is a refiling of BUG-233175 I would like to propose a mechanism for users to modify and customize some of their agent's attributes including (but not necessarily limited to) the various movement speeds, jump height, and scale of the agent's physics shape. My initial thought is for a set of three functions: llSetAgentParams llGetAgentParams llResetAgentParams The setting of these agent parameters could behave similar to llSetAnimationOverride: where once an attribute is set, the customization will persist until explicitly overridden, reset, or the user logs off. Also like the animation override, this would require a new runtime permission: PERMISSION_CHANGE_AGENT_PARAMS Action: configure the overriding of default agent parameters Category: Agent Granter: Anyone Auto-granted when: Attached llSetAgentParams(list params) Sets the agent parameters specified in params. Survives script reset/removal, attachment removal, changing regions and teleporting - but not relog. Setting a zero/null/etc value is the same as resetting it to default. Invalid inputs cause the function to shout an error on DEBUG_CHANNEL. The function will still accept and act upon valid inputs that preceded the invalid one(similar to llSetPrimitiveParams). Requires new permission: PERMISSION_CHANGE_AGENT_PARAMS. [AGENT_WALK_SPEED, float speed] : Agent's walking speed [AGENT_RUN_SPEED, float speed] : Agent's running speed [AGENT_CRAWL_SPEED, float speed] : Agent's crouch-walking speed [AGENT_TURN_SPEED, float speed] : Agent's turning speed [AGENT_FLY_SPEED, float speed] : Agent's horizontal flight speed [AGENT_FLY_UP_SPEED, float speed] : Agent's hover-up speed [AGENT_FLY_DOWN_SPEED, float speed] : Agent's hover-down speed [AGENT_JUMP_SPEED, float speed] : Speed at which agent achieves apex of jump height [AGENT_JUMP_HEIGHT, float height] : Agent's vertical jump height [AGENT_STAND_PHYSICS_SIZE, vector size] : Scale applied agent's standing physics shape [AGENT_SIT_PHYSICS_SIZE, vector size] : Scale applied to agent's sitting physics shape [AGENT_GROUND_SIT_PHYSICS_SIZE, vector size] : Scale applied to agent's ground-sitting (ALT+Shift+S) physics shape Min/Max values up for discussion. I imagine minimum size would mimic prims; no single dimension being smaller than 0.010 meters. list llGetAgentParams([list params]) Essentially same as llGetPrimitiveParams. Only accepts the AGENT_* flags as listed above. Requires PERMISSION_CHANGE_AGENT_PARAMS. llResetAgentParams([params]) Reverts specified parameters back to their system defaults. Only accepts the AGENT_* flags as listed above. Additional param: AGENT_ALL_PARAMS as a shortcut to reset all (or alternatively: supplying an empty list?). Requires PERMISSION_CHANGE_AGENT_PARAMS. Since llSetAgentParams and the persistence of its effects are modeled after the llSetAnimationOverride functions, it would have similar (if not higher) potentials for abuse, given the fact that these would go beyond cosmetic changes and could impact user navigation throughout SL. For that reason, I also suggest some additional viewer/server components to go alongside with this feature as defined below. If there is still concern, perhaps adding a throttle to how many times attributes can successfully be changed in a given time frame (in which case having the set function return a status integer would be warranted). Or perhaps removing the auto-granting of the permission on attach - though Experiences should still function as normal. Additional viewer support functionality: A UI toast/popup that appears whenever an agent parameter is changed, similar to the ones that show whenever the avatar complexity changes. At minimum, this popup should have a clickable link to a knowledge base article that explains this feature - and most importantly, how to reset it. This toast/popup can also be disabled by the user in Preferences > Notifications. A new menu item " Avatar > Reset agent " to immediately reset all agent params and revoke PERMISSION_CHANGE_AGENT_PARAMS to any unattached objects in the same region (similar to " Avatar > Stop animations "). Also, a " Develop > Render Metadata > Agent Physics Shapes " would be useful for users to visualize the altered (and default) agent physics shapes. Additional land support functionality: A new land option which could disallow changing agent params and/or ignore custom params and only use agent defaults while within the parcel/region (similar to no-fly zones). This would be beneficial to established games which rely on using the agent's default attributes and would consider alterations cheating (similar to the prohibiting of user made movement enhancers). Also consider letting experiences still perform such overrides over allowed land. Justification moved to comments due to 5k character limit...

In order to change the value of one parameter using llSetPrimitiveParams , the script must specify values for all of the parameters for the given flag. With the addition of PBR, which can be changed in child links only with this function, this has never been more cumbersome. I propose a new constant be added to preserve the existing value for the position it is placed in. A "NO_CHANGE" or "KEEP" constant could replace known or unknown values in order to preserve them while changing other values following a flag. Take this for example: llSetLinkPrimitiveParamsFast(2, [PRIM_TEXTURE, 0, "12345678-1234-1234-1234-123456789012", <1,1,0>, <0,0,0>, 0]); If we don't know the texture on face 0 of link 2, then we would need to add a second script in that link to change any of the above individual parameters, or we could have something like this: llSetLinkPrimitiveParamsFast(2, [PRIM_TEXTURE, 0, NO_CHANGE, <1,1,0>, <0,0,0>, 0]); Because some parameters require other parameters to be defined when changed, llSetPrimitiveParams should assume defaults (or revert to previously used values, if available) when not provided or currently in use, such as mask_cutoff when PRIM_ALPHA_MODE_MASK is used. This feature would provide a significant quality of life improvement to scripters working with objects that they don't have all of the source items for.

Per https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/ This is putting the teams part of what Rider had drafted up as a proposal into a feedback. --- Right now it is very difficult to clearly identify combatants except for using groups which is a hassle. It requires someone to join a group, set it as active, etc. Or systems that implement Teams via scripts like the Combat2 DevKit can be cumbersome and hard to maintain. Requiring the hacky group checks, a lot of listeners and messages for anything that cares about team assignment, such as a restricted door, a forcefield, a claymore that checks friendlies or enemies in a sensor. And if group checks are used then you need to distribute and update all the scripts involved if something changes. A military has an extra group? Update the entire armory. Want to play with 3 or 4 teams against eachother? Update all the scripted objects deployed in the battlefield, sometimes across multiple sims. Even the Pew Pew combat 2.0 party we had with the lindens showed the issues greatly affecting the event, as the feature was rushed out and it wasn't possible from a lot of strangers in many different groups as to who which team they were fighting for. Experience based respawn systems also need to manage identification, to know where to put someone. We had an issue where a group wanted to have an internal fight, people had to change their active group, ... which then led to problems because army-specific equipment can have required group identification that ties it to the active group as authorisation, we resolved that (since we had a militia group that it allowed usage with) thankfully but it showed the cracks in the system from lacking a fundamental system. --- So I would like to see Rider's implementation of Teams. Which allows some predefined teams to be configured (8 but hopefully up to 12-16 personally). See the thread for more details: https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/

Inspired by a comment during an SL21B Town Hall interview: key llGetProfilePicture(key uuid); Displaying a user's profile picture has a multitude of valid uses, from simple visitor counters, to "Am I Online?" displays in stores, game scoreboards, fun little ID badges, and so on. We've been doing this for ages.. easily a decade or more at this point.. and yet displaying a user's current profile picture is far from trivial. The current approach goes something like this. Get the user's UUID. Point a web call to https://world.secondlife.com/resident/ + (string)UUID Then we sit, and wait, and hope today isn't the day that LL finally shuts off world.secondlife.com , and we pray it's online at the moment. Assuming we get back a valid page response, we scrub through the small fragment of HTML that the script managed to capture, then we look for <img alt=\"profile image\" src=\"https://secondlife.com/app/image/ Then we pull out everything before that, and the first 36 characters left SHOULD be the UUID for the user's current profile picture. There has to be a more elegant way to do this. llGetProfilePicture could work much the same as llGetUsername or llGetDisplayName, feed the user's UUID in, and get a response that's immediately usable... resulting in less http overhead, and less reliance on a profile and group service ( world.secondlife.com ) that is not really being supported. Other uses: * Objects: sending it an object's UUID (or other inventory asset) could return it's set 'inventory image', if one exists * Groups: sending it the UUID of a group could return the group's Image * Land: sending it the UUID of a parcel of land could return the land's "Place Profile" image.

We have no way to know how long sounds are in our inventory in the sound properties or in LSL. We need the ability to see how long sound files are. Having this function would be great for making sure we can queue the next sound properly. this would be ideal for song loopers when we have a lot of sound files we're handling that have differing lengths. llSetSoundQueueing is limited and does not offer anything more than 1 level deep and will discard the last sound your trying to queue, so that isn't useful.

It's an age-old problem.. you're building a device to play some sounds in order. Because of SL's file-upload limitations, these files might be small sequential bits of a longer recording. Maybe it's music, maybe it's atmospheric sound effects, maybe a recorded speech. Doesn't matter. With recent changes, NEW sound files can be 'up to' 30 seconds long, while older sounds were limited to 10 seconds maximum. But there's no reason that a sound file couldn't be 4 seconds, 1 second, 27 seconds, etc. I propose a function be added, that would retrieve the playback length of a given sound (id), returning it as a float of fractional seconds. This would allow scripts to know exactly how long of a delay to insert between playing sound A, and sound B, C, D, and so on.

Right now llGetAgentList can only return up to 100 users, but regions can have 110 online users at the same time because there's an extra 10 slots for Premium users. If I'm not mistaken, event regions can also have up to 175 users. It'd be nice if llGetAgentList was updated to reliably return the whole list of users, at least up to 110. The fact that the current limit is 100 seems like an oversight.