Scripting Features

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.

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.

This is a refiling of BUG-5307 New parameters which would further manipulate the texture displayed on the particle polygon. Note that the SCALE of the particle itself is still in effect. It is analogous to the scale of a prim. At the same time, the texture repeats/offset of this suggestion is analogous to the prim's face. They would interact in the same way which currently happens with textured prim faces. Static texture manipulation set: PSYS_SRC_TEXTURE_REPEATS : (vector) repeats. XY range +/-0.0 to +/-100 (Negative value flips, and Z is ignored) PSYS_SRC_TEXTURE_OFFSETS : (vector) offsets. XY range from -1.0 to 1.0 (Z is ignored) PSYS_SRC_TEXTURE_ROTATION : (float) rotation expressed in radians Static texture parms act like those which govern the texture repeats/offset/rotation on a prim's face. In essence, it would allow a particle's displayed texture to be a subset of a larger image file. Same limitations as with prim faces, see http://wiki.secondlife.com/wiki/PRIM_TEXTURE . Note that there are no start/end variations of these parameters because that would be better suited by supporting animated textures in particles. Animated textures have been suggested countless times before, but I'll briefly summarize them here (because I think under this implementation they would be very similar or related to what's proposed above). Animated texture manipulation set: `PSYS_SRC_ANIM_MODE: (integer) ANIM_ON | LOOP | REVERSE | PING_PONG | SMOOTH | ROTATE | SCALE PSYS_SRC_ANIM_SIZEX : (integer) horizontal frames. Ignored for ROTATE & SCALE `PSYS_SRC_ANIM_SIZEY: (integer) vertical frames. Ignored for ROTATe & SCALE PSYS_SRC_ANIM_START : (float) start position/frame number or radians for ROTATE PSYS_SRC_ANIM_LENGTH : (float) number of frames to display or radians for ROTATE PSYS_SRC_ANIM_RATE : (float) rate of frames per second This set largely resembles the existing texture animation function calls for prims, though without specifying any sort of face. See http://wiki.secondlife.com/wiki/LlSetTextureAnim . The animation mode parameter could accept the same flags used by llSetTextureAnim's mode parm. An important distinction to make: particles should not be synchronized, each burst's animation should play independently from the next. Alternatively, an additional PSYS_SRC_ANIM flag could be provided to toggle this behavior. This feature is important to me because it expands what can be possible with particle effects. Additionally, it removes the implicit restriction that particles cannot reuse textures that were not explicitly designed to be used as particles. At the same time, it also has the potential to significantly reduce asset server load by encouraging consolidation of particle textures into one asset. With this feature, users would be able to combine related images into a single asset and still allow different particle emitters to pick out unique looking texture data from that same asset. An experience within Second Life that uses multiple different particle textures could lump them into one asset and reduce the calls to the asset server to load them all. Even more interesting is the notion that these particle "sprite sheets" could themselves be subsets of an image file that includes other non-particle textures. For example, under this suggestion, a single texture could hold imagery for an experience's HUD, game pieces, and also particles. All within one asset!

This is a refiling of BUG-233266 A new PSYS_PART_FLAGS mask value that when set, would cause particles to be drawn on 2D planes that aren't locked to facing the viewer's camera. Instead, each particle would be given a random rotation to spin on at a constant rate throughout its lifetime. As the name implies, the intent is to mimic pieces of confetti tumbling randomly through the air. Ideally this would be compatible with most other existing particle parameters, perhaps with the exception of PSYS_PART_RIBBON_MASK. If the ribbon mask is set, it should probably override the confetti mask's effects. When combined with PSYS_PART_FOLLOW_VELOCITY_MASK, it may be interesting to limit the spin to occur around the particle's local Z axis, while still having the particle's "top" orient itself in the direction of movement. If this is too performance intensive, then it might be best to also ignore this mask when the confetti mask is set. Two additional PSYS_SRC_* parameters are optionally suggested to allow the user to specify a minimum and maximum speed at which the confetti particles will spin. I assume these would be ignored if PSYS_PART_CONFETTI_MASK is not set... unless others find it useful to be able to spin classic particles (since those always face the camera, they would in effect only be able to spin clockwise or counterclockwise). Setting spin speeds of 0 would be valid, causing the particles to not continuously spin, but sill have a random initial orientation at the time of their creation. PSYS_SRC_SPIN_SPEED_MIN : Specifies the minimum float value of a random range of values which is selected for each particle in a burst as its initial spin speed upon emission. PSYS_SRC_SPIN_SPEED_MAX : Specifies the maximum float value of a random range of values which is selected for each particle in a burst as its initial spin speed upon emission. I feel this could be useful to content creators as it expands upon the visual effects possible with particles. Just as interesting new effects were created with ribbon particles, I think it would be valuable to bring some of that semi 3D feel to be used with the other existing patterns without the constraint of joining the particles together as ribbon does.

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

Currently, prims owned by the script owner aren't able to be returned as per the wiki: "As a security measure, parcel owner, estate owner, and estate managers can not have their objects returned by this method, except when the object returns itself." ...which is understandable for user-rezzed content. Please update llReturnObjectsByID() with a check to allow return of self-rezzed objects. These are objects rezzed by the same object calling llReturnObjectsByID(). Whenever I have a massive amount of content that I wish to update in an automated fashion, I can't complete the process without tedious, repetitive, manual intervention come time to return each object to my inventory. This update would allow the process to be completely automated.

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

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