Scripting Features

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!

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

Determine a part of the texture to be used for particle. The texture could have a grid of different sprite effect/object with options on how the particle will select those. First, must provide the grid information (X,Y) to use that texture's sprite sheet, so it knows which section to use. Second, is setting which kind of mode you want to use. Useful for setting particle once with one texture and still have effects appear randomized or in following order without seeing the same thing. 0 = random 1 = In order from right to left, top to bottom. 2 = In order from left to right, top to bottom. 3 = In order from right to left, bottom to top. 4 = In order from left to right, bottom to top. Ex: [PSYS_PART_SPRITE_SHEET_GRID, 5, 5, PSYS_PART_SPRITE_SHEET_MODE, 0] Example of a sprite sheet texture for the code above. The code will select one of the sprite in that texture at random each time it emits a particle item.

Together with https://feedback.secondlife.com/scripting-features/p/offset-position-for-particlesystem we could add particle systems to rigged mesh that follow a certain attachment point instead of the root. Like: PSYS_PART_ATTACHMENT_POINT, point_id Since rigged mesh follows the bones as they are animated, a particle system can not be made to stay in sync with the attachment. This proposal would make that possible.

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.

Summary: Enhance llGiveAgentInventory to provide better folder management and allow deeper inventory hierarchy, enabling more complex inventory structures for scripted outfit and appearance management systems. Proposed Enhancements: New Flag for Folder Reuse - Introduce an additional flag ( TRANSFER_REUSE_FOLDER ) that, when set, will place items in an existing destination folder if it already exists, rather than creating a duplicate. - This will prevent unnecessary clutter in a user’s inventory when updating or managing scripted items. Increase Maximum Folder Depth - Expand the allowable inventory path depth from 4 levels to 8 levels when using TRANSFER_DEST . - This allows for more granular organization, which is particularly useful for modular outfit management systems where users need to organize appearance layers and accessories effectively. Use Case: A scripted outfit management system needs to store various items in a structured way, such as: #RLV | Product/Region | Outfits | Sci-Fi | Armor | Chest | V1 #RLV | Product/Region | Outfits | Sci-Fi | Armor | Chest | V2 #RLV | Product/Region | Outfits | Fantasy | Robes | Mage | Red #RLV | Product/Region | Outfits | Fantasy | Robes | Mage | Blue The current depth limitation (4 levels) makes this approach unworkable. By increasing the depth to 8, systems that manage avatar appearances dynamically can maintain organization without workarounds like splitting folders into separate deliveries and having the user manually move them. Additionally, without TRANSFER_REUSE_FOLDER , every time a scripted system attempts to add to an outfit folder, it creates duplicates, making inventory organization difficult for users. This flag would ensure updates and additions go into the existing folder seamlessly. Expected Benefits: Improved Inventory Organization – Prevents unnecessary duplicate folders when updating outfits or items. Greater Flexibility for Outfit Management – Allows deeper categorization, benefiting modular and layered appearance systems. Better User Experience – Reduces clutter and streamlines scripted inventory transfers. These enhancements will significantly improve usability for content creators and users relying on automated inventory systems. Thank you for considering this feature request!

As seen here: https://wiki.secondlife.com/wiki/LlSetInventoryName llSetInventoryName( string old, string new ); Changes inventory object 'old' to 'new'. Feature has been requested repeatedly since 2009, it would be useful for data storage, version control, and customization.

Limits on strings are in bytes[1] everywhere it matters. llStringLength returns a count of characters (code points, presumably). Luau already gives us string.len() utf8.len() to distinguish between the two. ll.OwnerSay("bytes: " .. string.len("abcdᴥ")) // 7 ll.OwnerSay("points: " .. utf8.len("abcdᴥ")) // 5 The suggested approach to getting the byte length of a string in LSL is to convert it to base 64, parse that to a list to strip padding, cast the list back to a string, get the length of that string (since the code point count will now (nearly) match the byte count), and do some math to clean it up. For complexity, performance, and GC, It would be nice if we didn't have to do that. Mono having a utf-16 soul might complicate things? - although vm 2025 certainly uncomplicates them again if so. [1] https://wiki.secondlife.com/wiki/Limits#Communication https://wiki.secondlife.com/wiki/LlGetNotecardLine https://wiki.secondlife.com/wiki/LlHTTPRequest https://wiki.secondlife.com/wiki/LlEmail ... etc ---- Also related- https://feedback.secondlife.com/scripting-features/p/functions-to-get-byte-count-of-a-notcard-line-as-well-as-total-bytes-used-availa

I often switch back and forth between Firestorm and LL Viewer when helping customers with issues. I have found ways to be comfortable with either viewer BUT the limitation on LL viewer to not be able to derender a neighbor's way too low sky platform, a surround box that blocks my view of the water, or a random chair hanging in mid-air is very limiting. It seems a small thing but can make a huge difference when wanting to be comfortable on one's own mainland plot.

Something I've had issues with is making stuff that communicates with other stuff easily configurable. It'd be nice if we could utilize build tools in conjunction with LSL to do this. The simulator is already aware of what is selected, so it shouldn't be too difficult to expose it via LSL. Think of the following: I make two teleporters, instead of going through making the resident copy UUIDs or set up channels, they can just select the two teleporters then do /1234 link and they are linked automatically. Ideally, it would return a list of objects (up to a limit, I'm aware large amounts of objects can be selected at once, enough to cause a stack heap collision), with the first entry being the last object someone selected, and the last being the first selected. As for the function signature, maybe something like llGetSelectedList(key agent, list options) . Might want to put it behind some sort of permission though if it is someone other than owner. Might be useful to have a singular llIsSelectedBy(key agent); as well, to avoid having to do loops / list index checking in timers / events.