Scripting Features

Hard coding link numbers into scripts is usually bad practice. So it's often best to search for something more concrete like the name of a linked prim and assign it to an integer using a loop by using llGetLinkName and comparing it to the link name you want to find. This isn't very friendly to new scripters who want to work with linked prims. A function that checks all of the prims in a linkset and finds the first instance of a specified link name would make scripts like this much easier. If I wanted to find the first instance of 'door left' in a linkset this could look like; llFindLinkNumber("door left");

As a high-performant and modern alternative to the llHTTPRequest and llRequestURL , (web)sockets would be a great addition. It will allow objects and HUD elements to have direct bi-directional communication with back-end server software. The same can be achieved with the existing HTTP methods, but it requires a lot of effort to implement. The (web)sockets would have to be proxied through the Linden Labs servers just like the HTTP requests to avoid the leaking of IP addresses. If websockets are to be used, the benefit of HTTPS certificates exist for a secure connection. I am not requesting (web)sockets in the script to act as a server like llRequestURL , but for the script to always be the client to an external server (though feel free to implement that as well!). The functions could look like: key llSocketOpen( string url /*, Other options... */ ); llSocketSend( key id, string data ); // llSocketSend does not need a 'key' to return; packets identify themselves llSocketClose( key id ); The events could look like: socket_receive( key id, string body ) {} socket_close( key id, integer code ) {} // Code would follow the standard, but code '0' could be "closed by own script". There could be events for when the socket is opened or errors, too. In that case the llSocketOpen function can be non-blocking. Example code: key handler; default { state_entry() { handler = llSocketOpen( "wss://example.com:8081" ); llSocketSend( handler, "Hello world!" ); } socket_receive( key id, string body ) { if( id == handler ) { llSocketClose( id ); } } socket_close( key id, int code ) { if( id == handler ) { if( code == 0 ) { llSay( 0, "The socket was closed by us!" ); } elseif( code > 0 && code <= 99 ) { llSay( 0, "The socket was closed by the Linden proxy with code: "+ (string)code ); } else { llSay( 0, "the socket was closed by the remote server with code: "+ (string)code ); } } } }

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

I full well understand why llEmail - which can be used to send emails to inside AND outside of SL - has a 20 seconds forced delay. However, when used only inside of SL, using the lsl.secondlife.com namespace for object-to-object communication, the delay seems excessive to me. llEmail is basically the only(!) way for object-to-object communication that is reliable over long periods of time without the need to cache ephemeral URI's like we need with llHTTPRequest, where the URI changes with each restart. llEmail used in conjunction with an object UUID will run come hell or high water. Making llEmail in the lsl.secondlife.com namespace run with the typical 2 second delay (or less even), would allow scripters to keep more communication inworld and rely less on external servers. /me waits for the bot to turn it to "tracked"

Rationale We have sit targets to define where an avatar should sit on a linked object. But when standing up, it's always at that exact same position. This is awkward for things like vehicles where the user will unsit inside the vehicle instead of stepping out gracefully. This goes together with a possible unsit event as proposed here: https://feedback.secondlife.com/scripting-features/p/unsit-events Proposal Add a possibility to let us define the exact spot and rotation where the avatar will be positioned/moved to at the moment of unsitting.

Currently llGetAgentList() as an options parameter that is unused and the wiki warns of "possible stack/heap collision errors" because of the potential size of the returned list. This is like walking on a razors edge and sometimes forces us to use an extra script just to collect data of the parcel, with asynchronous message exchange with the main script, resulting in lots of complications just to try to avoid this. As already suggested in the wiki itself, there is room for improvement to limit the size of the returned list and hence the risk of stack/heap collisions. My first suggestion is of course to add an option to limit the size of the returned list: AGENTLIST_MAXNUM, with an integer value, 0 (no limit) being the default. Then an option to order the list is of course desirable: AGENTLIST_SORT, with an integer value: AGENTLIST_SORT_BYDISTANCE : sort agents by distance from the scripted object AGENTLIST_SORT_BYNAME : sort agents by (legacy) name AGENTLIST_SORT_BYAGE : sort them by age (to be completed) And an associated option to specify the sorting order: AGENTLIST_SORTINGORDER, with integer value: 0 (default) for ascending, 1 for descending order Other options to filter the list may also be useful: by minimum aga, by maximum age, by minimum distance, by maximum distance, by payment info .... (and possibly other filters).

To provide additional "keyframe" points information for particle's color, glow, alpha, scale, and emission*. *see Emissive Interpolation for ParticleSystem . PSYS_PART_MID_* can have many of the same variable type in the list and ends when it detected an integer type in that list's item. Ex: [PSYS_PART_START_COLOR, <1,0,0>, PSYS_PART_MID_COLOR, <1,1,0>, <0,1,0>, <0,1,1>, PSYS_PART_END_COLOR, <0,0,1>] [PSYS_PART_START_GLOW, 1.0, PSYS_PART_MID_GLOW, 0.5, 1.0, 0.2, 1.0, 0.75, 1.0, 0.4, 1.0, PSYS_PART_END_GLOW, 0.0, PSYS_PART_START_EMISSION, 1.0, PSYS_PART_MID_EMISSION, 0.5, 1.0, 0.2, 1.0, 0.75, 1.0, 0.4, 1.0, PSYS_PART_END_EMISSION, 0.0] [PSYS_PART_START_SCALE, <0.1,0.1,0.0>, PSYS_PART_MID_SCALE, <0.3,0.3,0.0>, PSYS_PART_END_SCALE, <0.0,0.0,0.0>] [PSYS_PART_START_ALPHA, 0.1, PSYS_PART_MID_ALPHA, 0.7, 0.3, 0.0, PSYS_PART_END_SCALE, 0.1]

Making a HUD and would like to get some organizing of gestures and animations instead of it all being in root. Even having a script have access to the inventory would solve a lot. Or maybe let the script read the contents and access of a prim in root.

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...

This is a refiling of BUG-233105 A companion to PRIM_LINK_SUBSET which would allow the user to get or set prim parameters over a consecutive range of link targets at once. The range specified is inclusive. PIRM_LINK_RANGE, integer start, integer end Example: The following code would change the prim size of links 3, 4, 5, 6, 7, 8, 9, and 10 within the linkset. llSetPrimitiveParams( [ PRIM_LINK_RANGE, 3, 10, PRIM_SIZE, <1,1,1> ] ); If a nonexistent link number is specified, it is silently ignored (similar to how PRIM_LINK_TARGET ignores numbers outside the current linkset). If this is the case for the end parameter, perhaps the range would default to only targeting the link specified in the start parameter. If the start parameter specifies a nonexistent link, perhaps the entire range (and the following prim parameters it would have applied) is silently ignored as well. Speed and list efficiency is the main goal here. If we look at the example above, the current way to achieve this would be duplicating the parameters list and pairing it with a PRIM_LINK_TARGET for each additional target link. llSetLinkPrimitiveParamsFast( 3, [ PRIM_SIZE, <1,1,1>, PRIM_LINK_TARGET, 4, PRIM_SIZE, <1,1,1>, PRIM_LINK_TARGET, 5, PRIM_SIZE, <1,1,1>, PRIM_LINK_TARGET, 6, PRIM_SIZE, <1,1,1>, PRIM_LINK_TARGET, 7, PRIM_SIZE, <1,1,1>, PRIM_LINK_TARGET, 8, PRIM_SIZE, <1,1,1>, PRIM_LINK_TARGET, 9, PRIM_SIZE, <1,1,1>, PRIM_LINK_TARGET, 10, PRIM_SIZE, <1,1,1> ] ); This creates a larger list for what is essentially the same data - and the problem is worsened if the initial parameters list we wish to apply to each link is large by itself. Alternatively the user could run llSetLinkPrimitiveParamsFast in a loop, updating the target link each time. That keeps the parameter list small, but requires multiple invocations of the function. This suggestion aims streamline the process in this scenario, avoiding having to duplicate a potentially long parameters list for each target link and allowing only a single llSLPPF call to be needed. This suggestion complements PRIM_LINK_SUBSET which suggests an arbitrary CSV list of link targets, whereas this suggestion would target a consecutive range. I believe both would be valuable additions. Thank you for your consideration.