Scripting Features

  • Search existing ideas before submitting
  • Use support.secondlife.com for customer support issues
  • Keep posts on-topic
Thank you for your ideas!
Please make llSetVehicleFlags(VEHICLE_FLAG_CAMERA_DECOUPLED) not require mouselook steering
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
1
[Function Requests] llGetGroupDetails
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.
3
·

tracked

Enhancements to `llGiveAgentInventory` for Folder Management and Depth Expansion
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!
0
LSL to write/update/change notecards needs to exist
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.
9
Load More