Scripting Features

I'm pretty sure many of us hate this happening. All kinds of workaround solutions like a script checking on timer() base if another is still running seems quite old school and inefficient too. How to do it, no idea but suggestions welcome. Pure random and probably imaginary idea: a new event function - or even state - that does run regardless, and then can properly do the necessary work?

I would love if we could do better menus other than just dialogbox, actually customizable menus for more proficient stuff, make huds that aren't primbased or mediabased. Dialogbox is way too constrained for this.

Currently there's no way to detect if rezzing an object has failed, (e.g. due to being too far away, or an invalid inventory item name) but the viewer does get this information when users screw up. Can we get object_rez_failed(key id) added to LSL (and SLua), by analogy with no_sensor() and experience_permissions_denied() ?

Second Life's interactive objects rely on LSL—a basic scripting language largely unchanged since 2003. This limits creators’ ability to build advanced, dynamic experiences. By introducing Lua, a powerful and widely adopted language, we can modernize scripting and unlock new creative possibilities. Broadens Second Life’s creator base to more easily include developers from Lua-heavy platforms (e.g., Roblox, Garry's Mod). Reinvigorates existing creators who’ve struggled with LSL’s limitations. Enables advanced features like mobile-focused development kits and robust 3D content manipulation (e.g., GLTF). Objectives New Audiences : Attract creators from popular Lua-based UGC platforms. Easier Scripting : Leverage Lua’s built-in features, large support community, and ample learning resources. Re-Engage Creators : Provide a smooth transition from LSL with bridging functionality, encouraging return visits. Advanced Features : Introduce long-requested language improvements (e.g., map-types, index operators). Richer Experiences : Allow for more complex, dynamic scripts to increase retention and drive engagement. Reduced Technical Debt : Replace LSL's difficult-to-maintain system with a modern, flexible alternative. Education Opportunities : Offer a full-featured language that helps new programmers build real-world skills. Links Lua FAQ - Read this if you have questions about "Why Lua?"

In various events, such as listeners, we can only pass a string. We know that we can pass floats or integers as a string, but trouble occurs if the listener can receive both alphanumeric and numeric values. The check for that now would be a separate function that would be circumspect. I request adding a function: integer IsNumeric(string input) The input is a string and the return value is TRUE if the string is a valid numerical value (e.g. 1, -2198, 15.49883) and FALSE otherwise.

Currently, most mesh attachments in Second Life come with at least one script to receive commands from HUD's and change primitive parameters such as colors and textures. These scripts all add to region script time, slow down sim crossings and increase operating costs for LL. I believe that if we could remotely get/set primitive parameters from a HUD, the number of worn scripts on an avatar would decrease considerably over time. We would need two functions, similar to the existing llSet/GetPrimitiveParams I Propose llSetObjectPrimitiveParams(key object, integer link, string password, list parameters); llGetObjectPrimitiveParams(key object, integer link, string password, list parameters); The function would only work if both objects have the same owner and the correct password is used. The build window would allow us to set a password for remote editing on an object, which once set becomes a private internal variable that cannot be retrieved. Example - Making a remote object the color red Key myShirt = findAttachmentWithName("Captains Shirt"); llSetObjectPrimitiveParams(myShirt, LINK_SET, "some_password", [PRIM_COLOR, <1,0,0>]); By being able to edit objects directly from a HUD we vastly reduce the number of active scripts required to be attached to an agent at any given time, which will lead to better lag, faster sim crossings and lower operating costs.

string llRandomBase64(integer number_of_bits) Generates number_of_bits random bits using a cryptographically secure random number generator (CS-PRNG or true randomness) and encodes them into a Base64 string. If number_of_bits is not a multiple of 6, up to 5 zero-bits are added for padding. The padding bits must not be random. Padding to full bytes is not a good idea, it will just cause people to immediately throw a llGetSubString() on top of this. SECURITY If a PRNG is used, its state must not be shared between scripts. The PRNG may require/support (re-)seeding using a separate function llSeedRandomBase64(string seed_material) However, it is not feasible to demand the script to provide all the entropy. This is also why this function is so important for SL scripting. RATIONALE Without secure randomness, the use of cryptography in SL is extremely limited. You can use it for non-security-relevant purposes. You can sort-of comply with protocols, though you are undermining their intended security. You can rely on external services, which makes the SL experience more dependent on services that can go away any time. SAMPLE IMPLEMENTATION NOTE: Not recommended for practical use because of its weak entropy source. Attachment seems to get rejected, I hope it accepts a paste: https://pastebin.com/k4Wrquhm

Several of the body vendors include scripts to change the shape of the foot to match the shoe being worn from flat footed to on tip-toes. But when the foot shape changes, the avatar is left hovering in the air, or sinking into the ground and the hover height needs to be manually changed to reflect the new food position. I suggest adding a new LSL command to alter the hover height of the avatar. Thus: llSetAgentHoverHeight(key Agent, float Distance) ( edit to add a key field to the command. Not surf if it would needed or not. but the the behavior that if the agent key is not also the owner key that the command is either ignored, or an error is shouted on the debug channel ) The distance can either be a fixed value, or a relative value based on the current hover value. Examples. When I stand barefoot, my hover height is "0.06" -- as shown on the "Avatar > Hover Height > Set Hover Height" slider. But when I'm wearing heels my hover height is "0.170" So the "llSetAgentHoverHeight" would either need to set the static values of 0.06, 0.170, and any other needed values for the shoes in question, or adding (+0.102) to the "current' value when putting on heels, and subtracting (-0.102) from the 'current' value when putting on flats. The actual values, either static or relative would need to be established either by the shoe maker, or the shoe wearer, depending on how the script maker decides best of course.

Proposal Originally proposed on the Jira Allow non owners to receive HTML content. In responses from llHTTPResponse with llSetContentType(id, CONTENT_TYPE_HTML) Currently the restrictions are: (per the wiki) - the web browser is the Second Life client - the user (logged into the SL client viewing the page) is the owner of the object. - the user (logged into the SL client viewing the page) is connected to the region the object is located in I would propose relaxing at least the 2nd, "owner of the object" restriction. Reasoning The current restriction encourages the hosting of content external to sl, resulting in a form of "link rot" over time, leading to ever more broken scripts and objects as users forget/actively take down those external services. Removing it would allow prims to actually host their own pages when needed, in a simpler manner. There are already a few ways (but cumbersome) to circumvent it, so it is already ineffective. There has also been talk of serving content for HTTP requests directly from notecards at SUG meetings, this would compliment that massively. Concerns This should have no impact on either, security or privacy for SL users, as I mentioned above there is already a workaround for this, and the prim could just load an external site that can capture any data far better anyway. User privacy is primarily controlled client side with the decision on whether or not to load the page in the first place (be it via media being disabled, whitelists, or other settings). Additional The 1st and 3rd restrictions could also be lifted, but that is debatable, depending on how LL feels about prims being used to directly host content for use external to SL. I personally would like to make things like control panels etc for user to work with, and instead of having to upload complex meshes and moved things around with scripts a simple html ui would be perfect... but right now you have to bypass this restriction for that.

Rationale We have sit targets to define where an avatar should sit on a linked object. But when standing up, it's always at that exact same position. This is awkward for things like vehicles where the user will unsit inside the vehicle instead of stepping out gracefully. This goes together with a possible unsit event as proposed here: https://feedback.secondlife.com/scripting-features/p/unsit-events Proposal Add a possibility to let us define the exact spot and rotation where the avatar will be positioned/moved to at the moment of unsitting.