Scripting Features

Implementation: https://gist.github.com/FelixWolf/d6b78b39a06419693a93046046913e15 LSL has the issue where some lists need to be typed, cough llSetLinkPrimitiveParams cough . It's important to be able to store types when storing a string, say to either a remote server, or llLinkSetData , or even just transmitting it from one object to another. The design philosophy behind this idea is three points: Be compact Be easy to implement (for residents who need to make code to do this) Solve the issue The functions are: * string llList2TypedString(list data); * list llTypedString2List(string data); The syntax is as follows: * i precedes a integer, if no integer is found, it represents 0. (Hexidecimal is supported because of std::stoi ) * r ("r" as in Real!) precedes a float, if no float is found, it represents 0. Preceding zero are optional for values between 0 and 1. * v precedes a vector, if no vector is found, it represents zero. If any value is zero, it may be omitted. I.E. v,1 is valid for <0,1,0> , as well as v,,1 being for <0,0,1> . * q precedes a quaternion, it shares the same behavior as a vector (Quite literally the same code!) * k precedes a key. It reads exactly 36 BYTES, unless the first byte is "-" * s precedes a string. It is defined by specifying a integer length, followed by a colon, then the string. If no string or simply a semicolon, it represents a empty string. * Lists are unsupported, lists may not contain lists. * Any of the above may be combined in series to form a list. I've provided a lscript implementation at the top of this post.

Currently, there is no way to drop an object onto the ground after attaching it via script. I propose adding llDrop() to enable this functionality. Unlike llRezObject() or llDetachFromAvatar(), llDrop() would allow an attached object to be placed back into the world without being sent to the user’s inventory. This would provide a seamless interaction where a user can pick up an object with llAttachToAvatar() and later place it elsewhere using llDrop(), without unnecessary inventory management—creating a more intuitive "pick up and set down" experience. Requires PERMISSION_ATTACH to have been granted. Possible Rules: DROP_ALIGN_NORMAL – Aligns the object to the surface normal at the drop location. DROP_PHYSICAL – Enables physics on the dropped object, letting it fall naturally. DROP_PHANTOM - Drops the object with phantom properties. DROP_TEMPORARY – Drops the object as a temporary item that auto-deletes after some time.

Implementation: https://gist.github.com/FelixWolf/8ef1ced3cd1aa37c5dc803d7a79e43d8 (Contributor agreement should cover this, I think?) I requested this on the Jira back when it was around, but it was closed due to endianness issues on various machines. I've written a implementation that packs the float into base64, and visa versa, regardless of endianness. It currently encodes in big-endian, which llIntegerToBase64 and llBase64ToInteger do. It would be really useful if we need to preserve floating point values in a short string. Benefits of this over doing (string) for floats is that: Extremely precise floats don't end up like 1.258532194328154328 LSL cuts off floating point precision after the 5th precision (EG: 0.12345 instead of 0.1234567890)

Make the Second Life script editor more user-friendly by adding real-time script stats at the top of the floater window. This would give scripters instant feedback on how their edits affect memory usage and performance, making it easier to write efficient, optimized scripts. This doesn't need to be real-time if that isn't possible or to intensive however, This does seem like something that can be done after a script is compiled. Suggested Metrics: Script Memory Usage: Display the script’s current memory footprint (e.g., “Memory Usage: 16 KB / 64 KB”). Instruction Count Estimate: Provide an approximation of the number of operations executed per event. Mono Heap Usage: Show memory allocation for Mono-compiled scripts. Total Running Time: Estimate how much execution time the script might consume in active states. Other Potential Metrics: Stack depth, event queue size, or execution time per event. Benefits: Real-Time Optimization Feedback: Scripters can immediately see the impact of code changes on memory and execution efficiency. Improved Performance Awareness: Encourages best practices by making script limitations more visible. Streamlined Debugging: Helps identify potential inefficiencies before deployment. Better Resource Management: Reduces excessive script load across regions, improving overall grid stability.

llGiveInventory and llGiveAgentInventory both allow for giving inventory. However llGiveInventory allows you to give items unrestricted across any region. llGiveAgentInventory is however restricted but is a more useful function with inventory folders. There is a huge demand to unrestrict llGiveAgentInventory as the whole point of the function was to get around "Unboxers" in the first place as the major usecase. Here are two proposals: This proposal - Allow llGiveAgentInventory to work across regions but only if the destination agent is part of the group the object is assigned to Allow llGiveAgentInventory to work across regions but the contents are put into "Received items", same as Marketplace. -- https://feedback.secondlife.com/scripting-features/p/llgiveagentinventory-across-regions-but-has-to-be-put-it-into-received-items Both proposals go toward the same goal for my personal uses but are not exclusive -- they can be both valid and should be considered on their own merits and usecases. ---- Proposal - Part of same group Lets allow llGiveAgentInventory to work across regions, however only if the destination agent is part of the group that the object is assigned to. Usecases: Roleplay / Combat group that wants to give updated objects to their members Shop that has an customer, outreach or support group of customers that have opted in or subscribed to updates to their products Related issues: https://feedback.secondlife.com/scripting-features/p/improve-usefulness-of-llgiveagentinventory SamanthaTekcat Resident's comment in https://feedback.secondlife.com/scripting-features/p/enhancements-to-llgiveagentinventory-for-folder-management-and-depth-expansion

Dark theme is the standard for modern script editors and IDE's. Statistically speaking you're likely to be viewing this canny in dark mode, have a dark themed discord, browse the web in dark mode etc. With the advent of Lua we should also show new creators that we are keeping with the times and meeting modern expectations by providing a dark mode by default in the script editor.

Some external services deny a request if a HTTP_ACCEPT header is present. However, llHTTPRequest enforces that header, using "text/plain;charset=utf-8" if no other header (out of a small list of available options) is present. As Monty Linden confirmed in https://community.secondlife.com/forums/topic/521090-grid-ssl-cert-updates-coming-soon/#findComment-2881062 , empty HTTP_ACCESS headers are not allowed. I would like to suggest that making a llHTTPRequest call with an explicitly empty HTTP_ACCEPT header will remove that header altogether in http-out calls. Examples: llHTTPRequest(url, [],"" ); No HTTP_ACCEPT set, default "text/plain;charset=utf-8" gets used. llHTTPRequest(url, [HTTP_ACCEPT, "application/json”],"" ); Specific HTTP_ACCEPT set, so only "application/json” gets accepted. llHTTPRequest(url, [HTTP_ACCEPT, ""],"" ); Empty string gets passed - HTTP_ACCEPT header gets removed completely. The chances for breaking existing content are slim, since a scripter would have had to explicitly pass an empty string (in violation of the documentation), and then rely on it being substituted with text/plain. Since work on the http-out part is underway anyway, this would be an ideal opportunity to add this feature.

llGiveInventory and llGiveAgentInventory both allow for giving inventory. However llGiveInventory allows you to give items unrestricted across any region. llGiveAgentInventory is however restricted but is a more useful function with inventory folders. There is a huge demand to unrestrict llGiveAgentInventory as the whole point of the function was to get around "Unboxers" in the first place as the major usecase. Here are two proposals: Allow llGiveAgentInventory to work across regions but only if the destination agent is part of the group the object is assigned to -- https://feedback.secondlife.com/scripting-features/p/llgiveagentinventory-across-regions-but-only-if-same-group This proposal - Allow llGiveAgentInventory to work across regions but the contents are put into "Received items", same as Marketplace. Both proposals go toward the same goal for my personal uses but are not exclusive -- they can be both valid and should be considered on their own merits and usecases. ---- Proposal - Received Items Lets allow llGiveAgentInventory to work across regions, however only if a flag is set to put the inventory into Received items. Usecases: Vendor / Shop that wants to deliver a new product Customer wants a redelivery of a product (particularly latest one) Vendor / Shop that wants to deliver a critical update to a product This could be done by adding a TRANSFER_FLAG_RECEIVED_ITEMS flag, which allows for giving a structured folder into the Received items part of the viewer inventory interface.

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?"

It would be great if we could check which prim was damaged through llDetectedLinkNumber , since it's possible to target an individual prim either via direct damage via llDamage or collision damage via `llSetDamage. The usecases are for component level damage or adjustments. For example the pillars of a building I am working on are damageable to bring down the building. But currently I need to separate them out into their own individual objects. Another usecase is a tank with different armor thicknesses of the front, sides and back. Or creating weaknesses in vehicles that can be targetted such as an external fuel tank. Since a vehicle is a linkset it would not be possible to separate out such components into their own objects or it would be pretty laggy / not a good idea use the workaround as the building. Usecase could also be an objective or game goal, such as an enemy or boss with an exposed weakness, or a power source linked to a force field, with an exposed part that could be shot to shut down the power source and thus the force field, or weapons/legs/tracks that could be damaged and disabled. Proposal: llDetectedLinkNumber in on_damage and final_damage return the link number of the prim that was damaged.