Scripting Features

I'd like an LSL function to find out whether a teleport would land at the intended destination. Currently if the destination is in another region, the only way to know if the avatar will arrive at the target is to teleport them and find out. I would like to check the destination first, so i dont need to start a teleport that won't arrive at the target. For example, if i wanted to teleport an avatar to another sim at <128, 128, 3020> there's no way to know if they'd actually land at that point or 3000m away on a ground landing point, or if they can't teleport into that parcel at all. The proposed function would send the avatar id and group and target position, and the remote sim would return a vector back indicating where the avatar would land. This would either be at the target destination, at the parcel's landing point, or zero_vector if they dont have permission to enter the target parcel. This would mean a teleport script can check the target first, and not teleport the avatar if they will end up far from the intended destination.

llGetUnixTime() , because of LSL integer type limitation, can return only 32 bits of epoch seconds. This means that around 19 January 2038, scripts that rely on counting the delta between two unix times will likely fail to function. Some workarounds are possible, but requires a lot of code to implement. Short of introducing a new type, integer64 , a (probably) much simpler workaround is to implement the following 2 functions: list llGetUnixTime2() returns a list whose first member is the higher-order 32 bits of a 64-bit unix epoch, while the second member is the lower-order 32-bits of the same unix epoch. The latter part is a bit tricky because it should be unsigned, so manual arithmetic might be a bit complex; hence, a second function: integer llDiffUnixTime2(list unixtime_a, list unixtime_b) given two list constructs as returned by llGetUnixTime2() , the function returns the number of seconds difference according to the rule of a - b . Alternatively, encode the 64-bit unix time into string using Base64. And introduce the functions string llGetUnixTimeB64() and integer llDiffUnixTimeB64(string a, string b) . This might use less memory because list is a complex structure that requires more memory than a string .

Linkset data is amazing for persistent storage and sending data between scripts. Having a set of data for avatars would be great too. It would enable synchronizing settings between multiple items of the same brand a lot easier. Storing shared settings, for example access block lists for interactive attachments. Or storing settings data when before swapping to a redelivered version of the same item, that can then read it. Sending password protected data between HUDs and other attachments, instead of using chat channels. I’m sure scripters would fine plenty of uses for something like this. Functionally it should have all the features of the LinkSetData, with some differences: • No equivalent for LlLinksetDataReset, as we wouldn’t want one brand’s items destroy other brand’s item’s data. • Larger storage than 128k, as there can’t be 30k avatars in a sim, compared to regular prims, more storage shouldn’t be a problem, I’d say 1mb or more sounds reasonable starting point. • Equivalent of https://feedback.secondlife.com/scripting-features/p/edit-linksetdata-from-inside-the-viewer would be a must, with a reset all button for the viewer. We wouldn’t want a broken item filling in someone’s whole storage, so ability for the Residents to clear all data or just select data would be required. • Maybe add a permission request before item can Write/Delete AvatarData, no read permission, or auto-grant read on attach. Again, since it is permanent storage on avatar, we wouldn’t want it to be corrupted by a broken script. • In terms of documentation there should be caveats pointed out that the data can be reset at any time by the Residents and that it should not be used for storing any license key or authorization type data. • Should have a listener functionality (similar to chat listen) for specific key changes instead of an equivalent of linkset_data event, as we wouldn’t want to trigger loads of scripts on many different attachments with each change.

What I want is a region-wide datastore, a very simple API like llLinksetData*. It is not required to be persistent -- scripters could reinitialise it on region restarts. It's ok if it's attached to an object (and therefore acts like a remote llLinksetData). It needs to support high read and high write usage and be synchronous. The usecase is for sharing data between objects at a higher level of abstraction. For example large region projects like games, weather systems, procedural life like pedestrians and cars / NPCs, etc. For example a game would often need to share a lot of data between scripted objects, such as vehicles, players, interactive objects, HUDs and temp attach objects. This often means the data also needs to shared across different objects of different ownership or active group settings securely. The security should be tied to a "project" (RSA keys, passwords and/or pins) or even experience compiled scripts. If the datastore is tied to an object or an avatar maybe all you need to know is the objects or avatar key and a script compiled to an experience to access and read from that region-wide datastore tied to that object or avatar. (E.g. like having a "mana" resource on an avatar and being able to actively manipulate that resource for passive mana regeneration or active/maintained spells from rezzed objects, HUDs or across multiple attachments, e.g. a wand that casts spells which drains the mana and a hud that shows current mana and has passive mana regen) Sometimes higher level of abstractions are needed for projects, such as a game manager that controls the overall state of a game and information such as who the players are and on what team they are / what teams there are, as well as objectives and resources. You should be able to make many of these region-wide datastores as you need in a project. Maybe several game managers/directors. Maybe one per avatar. Maybe one per major game object. Same limit of 128KB of LSD per datastore would be fine. Note that Experience Persistent Storage completely fails the above criteria: It's not high write / high read (I think it would be a bad idea to massively spam exp storage with fast timer reads to make sure to show an updated value on a HUD; What about small constantly changing updates like position, acceleration that may need to update at a very high frequency and be read immediately?) It is not fast / synchronous (how am I supposed to read/write a resource changing at milliseconds by multiple objects in a realtime game? Exp would keep accidentally overwriting values at critical moments as realtime games have action happen in bursts) It is an external server instead of in-memory (there is no reason for this complexity, latency and storage, I just wanted to share critical data (0.5-128KB) between objects in the same region or at least direct neighbouring regions/estate) Nice to have: Datastore being able to optionally/opt-in work cross-region or Estate-level / direct neighbours or 1-2 regions away, e.g. 3 regions in a line or a 2x2 square, just like how some data can be shared across region borders like llGetObjectDetails. This also avoids users having to create overly complicated/engineered systems of scripts to synchronise data between regions if they are all part of the same game/experience

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.

I've spent about the last week updating some scripts to handle both PBR and Blinn-Phong updates simultaneously. The scripts work fine, but the current way you have to update PBR values - through llSetPrimitiveParams and the full list of values - is not ideal. In order to avoid overwriting your existing values with blank or incorrect data, you have to have a way to know and store your existing values, modify those values, and send the whole list back in. Adding in some llFunctions for PBR values, so you don't have to modify the entire parameter array to change one value, would make scripting PBR modifications much more pleasant to work with. If llFunctions are not feasible, a way to update individual values in the parameter arrays without data loss (e.g. being able to pass a blank string as a texture and have it skip the value instead of applying it) would be appreciated. I've compiled a list below of how I would personally pop each value out into a Set function (they would have matching Get functions, a la llGetColor and llSetColor): --- For PRIM_GLTF_BASE_COLOR: llSetGLTFBaseTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFBaseColor(vector color, integer face); llSetGLTFBaseAlphaMode(integer gltf_alpha_mode, integer face); llSetGLTFBaseAlpha(float alpha, integer face); llSetGLTFBaseAlphaMask(float alpha_mask_cutoff, integer face); llSetGLTFBaseDoubleSided(integer double_sided, integer face); --- For PRIM_GLTF_NORMAL (this really only has one function): llSetGLTFNormal(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); --- For PRIM_GLTF_METALLIC_ROUGHNESS: llSetGLTFMetalRoughTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFMetallicFactor(float metallic_factor, integer face); llSetGLTFRoughnessFactor(float roughness_factor, integer face); --- For PRIM_GLTF_EMISSIVE: llSetGLTFEmissiveTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFEmissiveTint(float emissive_tint, integer face);

When a script needs a resident to select another resident uuid it would be super cool to have a function that opens for [id] the Resident Chooser already used in the viewer's invite to group. This would be so much better than the llTexBox(id,"please enter avatar's UUID,channel); we often use Upon "select" the CSV of choosed residents uuid would be sent to[id] on [channel] optionally "close" could send NULL_KEY to[id] on [channel] Ideally it could also have flags to restrict to only 'near me' and/or 'friends' tabs This new function working like llDialog() and llTextBox()

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

I just lost a lot of time trying to find and fix a non-existent bug, adding debug functions and such in my script, until I finally noticed the "running" checkbox was unchecked (because of a previous compilation failure and save, probably). It would probably have saved me a lot of time if inactive scripts could be identified at a glance in the prim's inventory. My suggestion is to color them in yellow, orange, red or whatever!

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!