Scripting Features

VEHICLE_FLAG_CAMERA_DECOUPLED is incredibly useful for use in vehicles, and allows for scripters to create a stabilized platform on otherwise uneven or rough terrain. This was attempted to be brought up in https://feedback.secondlife.com/scripting-bugs/p/llsetvehicleflags-vehicle-flag-camera-decoupled-does-not-work In said thread, it was elaborated on by the lindens that VEHICLE_FLAG_CAMERA_DECOUPLED requires VEHICLE_FLAG_MOUSELOOK_STEER or VEHICLE_FLAG_MOUSELOOK_BANK This limits the usability of a desirable function and requires scripters to create work arounds if they are creating some form of track or wheel driven vehicle they want to stabilize. Additionally, without the ability to decouple non mouselook driven vehicles, they are very nauseating and difficult to control, creating an opportunity for physics grief to negatively impact user experiences. A lack of decoupling for non mouselook steered vehicles was previously worked around for LLCS vehicles, prior to the implementation of llSetLinkSitFlags(link,SIT_FLAG_NO_DAMAGE), by setting the volume detect "sit prim" to be a mouselook steered vehicle that didn't actually make use of any vehicle movement. In short : The current functionality of VEHICLE_FLAG_CAMERA_DECOUPLED is limited to mouselook steered vehicles, limiting usefulness, the desired functionality of this flag as shown by the existing feedback threads regarding this very topic is use with non mouselook steered vehicles as well. Additionally, camera decoupled vehicles are more user friendly and less prone to being griefed via applying rotations via physical prims as well. feedback threads in question: https://feedback.secondlife.com/scripting-features/p/link-camera-decoupling https://feedback.secondlife.com/scripting-bugs/p/llsetvehicleflags-vehicle-flag-camera-decoupled-does-not-work

Since we are "hopefully" getting a means to assign script pin via llRezObjectWithParams() "soon", I feel it is time to mention that we lack the means of setting a script pin on other links in a linkset, requiring a script-per-prim approach and we also lack the means to check if a desired/undesired/forgotten pin is present on a link. The following function facilitates the above needs with a level of discretion: integer llSetLinkRemoteScriptAccessPin(integer link_num, integer pin); returns 0 with no update to all target links returns 1 with an update (change) occurring to at least one target link(s) Accepts LINK_* constants. Not only will this function allow practices to evolve and scripts to be more efficient, but also allow needed modularity/flexibility/scrubbing capability. The "discretion" mentioned above is that any present pin number(s) are not directly exposed, although it is my opinion that since this is an internal function (same linkset), if the linkset is mod, it is the linkset owner's right to know if a pin is present and what the pin is, but I am still limiting the function's ability to that of discerning if a pin is present or not at the minimum.

I'm not sure why this is still not a thing, but for a long time, Second Life's data in scripts is like playing an RPG without a memory card, and no way to save. There's a lot of valuable information that is relegated to variables, where if something breaks and the script needs to be reset, or something needs to be moved and placing it down resets the script, all of that information is gone. Right now, the only other option is to set up an external data server to send and receive information from, and that's overkill. Implementing a way to store, edit, and erase data from a notecard within an object would grant us the following at the least: Dynamic data storage: Scripts could save and update information without requiring manual editing of notecards. Improved configuration management: Scripts could automatically update configuration parameters stored in notecards, making it easier to maintain and modify object behavior. User data persistence: Objects could store user-specific data, allowing for personalized experiences without manual intervention. Storing with script restarts: Right now, there is no way to restart a script and still store the information inside without the use of an external webhost. Extended variable use: Too many variables can make a script problematic. Notecards could allow for storing and recalling them as needed to a far easier degree. Simplified data sharing: Scripts could generate and distribute notecards with custom content to users or other objects, facilitating information exchange. Reduced script memory usage: By offloading data to notecards, scripts could potentially use less memory for storing large amounts of information. Enhanced debugging and logging: Scripts could write log data or debug information to notecards for easier troubleshooting and analysis. Dynamic content creation: Objects could generate and update notecards with current information, such as player statistics or in-world event details. We need the ability to write to notecards. I'm shocked we don't have this yet but it feels like not having this as an option does a great disservice to creators and customers in Second Life.

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

An enhancement to LSL function library to allow a worn attachment to request or offer teleport to wearers or target's location (+/- small range offset perhaps) exactly as if the TP request came from the wearer of the scripted object themselves. To avoid the potential risk of griefing this could be restricted to friends of the attachment wearer only (up to you) or generate short script delay / only have one outstanding at a time. But as I can search for any name in the Search for People from Content tab I do not see this as a particular problem. Popular use would be for leashes which could automatically teleport wearers to their leasher's position when they have just teleported away (possibly with some help from RLV to automate the acceptance but not mandatory) eg: key llRequestTeleportAgent(key target, vector offset) - Same as Request Teleport key llOfferTeleportAgent(key target, vector offset) - Same as Offer Teleport Key delivered could be actioned from dataserver event where the data would indicate the response: 0 = denied - Avatar does not exist (or is not in friends list if restricting to friends only) 1 = delivered and accepted 2 = delivered and rejected (Cancelled) 3 = delivered and rejected (Timed out) The offset may be restricted to +/- <10,10,10> basically to ensure people don't land on other people's heads like with normal TP requests.

Currently, the process to obtain group information is extremely limited. For avatars, pulling the UUID via llGetObjectDetails with a list entry given by llGetAttachedList is the only way. Objects themselves being only able to natively return the group UUID via llGetObjectDetails, but obtaining additional details about the group is not possible with any existing function. The only way to pull the name of the group an avatar/object is set to is via the group's webpage which requires running a HTML request, with other things such as the group's texture being pulled the same way. Due to these reasons, trying to set up systems which interface with groups has been largely unintuitive and unreliable beyond a simple true-or-false check. The goal of this request is to create simple functions that can pull group information directly ingame without having to call upon external resources, in addition to adding ways to pull the specific information of a group which there is currently no function for. Examples: string llGetGroupKey(key UUID) - Returns the group UUID active on object or avatar. string llGetGroupName(key Group_UUID) - Returns a string that is the group's name string llGetGroupTexture(key Group_UUID) - Returns the UUID that is the texture set to the group. string llGetGroupDesc(key Group_UUID) - Returns a string that is the description of the group. integer llGetGroupRating(key Group_UUID) - Returns 0 if group is General, or 1 if the rating is set to Moderate. list llGetGroupDetails(key UUID, list flags) - Returns a list containing the information request in 'flags'. Valid flags would be GROUP_KEY, GROUP_NAME, GROUP_TEXTURE, GROUP_DESC, GROUP_RATING.

Many areas could benefit if the scripts running in them could be notified of impending region restart. For example, Several of the RP games I play could suspend activity automatically to allow agents to exit the region in a more orderly fashion.

Since texture transforms aren't part of the PBR asset, we can't just use the "" hack in llSetLinkPrimitiveParamsFast(...) to preserve their values. Instead we need to record the transforms (offset/repeats/rotation) for each face and reapply them with the new alpha value. A function like llSetLinkPBRAlpha() would be very much appreciated. Coming to think if it, most use cases (except for fading) could actually be addressed by having something like llLinkVisible(LINK_THIS, ALL_SIDES, TRUE) - llLinkVisible(LINK_THIS, ALL_SIDES, FALSE) - taking the usual LINK_* constants and face numbers.

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

Would like a new function that can change parcel's landing point via script. Can be useful for avoiding people landing on top of each other, as well useful for RP places to put them in different interesting spots each time someone teleport in. Obviously, the object would need to be deeded to a group, matching parcel's group, for it to work.