Scripting Features

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"

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-232631 Used to get or set multiple specific links with a single PrimParameters call with finer control that would be allowed with the existing LINK_* numbers and with better efficiency than targeting each link with PRIM_LINK_TARGET. Since we cannot have lists within lists, I propose this constant takes a string parameter which itself is a CSV (comma separated value) list of link numbers. PIRM_LINK_SUBSET, string comma_separated_string_of_link_targets If a nonexistant link target is specified, it is silently ignored (similar to how PRIM_LINK_TARGET ignores numbers outside the current linkset). If an invalid character (anything other than a number or comma) is used in the string, a runtime error is thrown. Sample use case: a user wants to change the prim size of links 1, 5, and 8 within the linkset. The current approach requires repeating the same parameters for each link target and results in duplicate list data. This has the potential to become very wasteful if the set of parameters is large or complex... llSetLinkPrimitiveParamsFast(1, [ PRIM_SIZE, <1,1,1>, PRIM_LINK_TARGET, 5, PRIM_SIZE, <1,1,1>, PRIM_LINK_TARGET, 8, PRIM_SIZE, <1,1,1>] ); Under this feature suggestion, the parameters need not be duplicated for each individual link target. This results in a smaller and more efficient list... llSetPrimitiveParams( [ PRIM_LINK_SUBSET, "1,5,8", PRIM_SIZE, <1,1,1> ] ); I feel this is important because it enhances how creators can apply the same set of parameters to a subset of links without having to duplicate said parameters for each link target. This would result in much more efficient lists for this use case. Thank you for any consideration.

The provisioned features and power of the game_control() event are impressive, and miles ahead of the support available to scripters for processing input events for standard keyboard+mouse usage. Currently there's no way to respond to other mouse buttons (scroll wheel, middle click, right click, shoulder buttons) and there are no vectors for user input aside from the standard movement keys. Thus if someone wants to make a game for users without a controller, they're limited to the interactivity of Quake 1, which is notable as being an aggressively minimalist design (shoot only, all doors open automatically) that was largely abandoned by other games. For SL to really work as a game environment, we need a way to bind a "use" key, or keys for reloading weapons, or for using special powers like a quick melee attack. I'd like to propose the following: - Adding 6 new mouse button bits to control(): scroll up, scroll down, mouse 2 (right), mouse 3 (middle), mouse 4 (shoulder 1), mouse 5 (shoulder 2) - Adding 4 new general-purpose control inputs to control(): action 1, action 2, action 3, action 4 - Adding the general-purpose action inputs to Preferences › Controls - Allow all control() bits to be mapped to controller buttons so vehicles without game_control() can be used with controllers and receive all the benefits of these new features — though this could/should be a feature request on its own The bitmasks for level and edge have plenty of room for these 10 new bits, so I don't think this is too crazy a request.

The Full/Folded perm mask exists, but we don't have access via llGetObjectPermMask() nor llGetInventoryPermMask(). https://wiki.secondlife.com/wiki/Debug_Permissions https://wiki.secondlife.com/wiki/LlGetObjectPermMask https://wiki.secondlife.com/wiki/LlGetInventoryPermMask We've needed access to quickly know if there is content anywhere in the inventory of the same or other prims of the linkset whose perms do not match the perms of the linkset itself. This has become more important with the advent of llTransferOwnership(). The yet-to-be implemented remote perms function will also need access. https://feedback.secondlife.com/scripting-features/p/object-permission-information-with-llgetobjectdetails