Scripting Features

Currently you can only take llDamage in damage enabled parcels. Obviously this is ideal to keep players who do not want to take damage or die safe, but could you add an opt in option to choose to allow damage to affect your avatar at all times anywhere while enabled? This would mean that players could "turn on PVP" and engage in damage systems anywhere in SL, on any parcel, opening a huge amount of potential for combat focused communities to expand. Those that leave this "PVP Mode" disabled would not be affected by this change at all, and would remain safe unless they chose to toggle it on and jump into the action. Maybe avatars with PVP enabled would display it above their name and group tag, for example: (PVP) ECHELON Grave Maybe a PVP enabled avatar dot on the minimap would have a small additional red ring around the dot.

Linkset Data allows multiple scripts in the same linkset to read/create/update/delete data. We currently do not have any LSD functions with an append validation protocol. Experience KVP updating has a validation protocol w/ feedback which can address race conditions between scripts in the same linkset, different objects in the same region or different objects grid-wide. The following function satisfies the need stated above for LSD: integer llLinksetDataWriteWithValidation(string name, string value, string pass, string original_value) A new failure code constant LINKSETDATA_VALIDATION with value 6 will be needed for this function. Functionality: If name does NOT exist and value is NOT an empty string and original_value is an empty string, the entry is created and 0 is returned, else, 6 is returned. If name exists and value is NOT an empty string and original_value matches name's current value and pass matches name's current pass, the entry is updated and 0 or 5 is returned, else, 6 is returned. If name exists and value is an empty string and original_value matches name's current value and pass matches name's current pass, the entry is deleted and 0 is returned, else, 6 is returned. Other typical check failures such as empty name, name not found, pass mismatch, etc. will return the same values as they do now before validation handling is done. The server is actually already doing these checks in the background to determine what integer value to return with exiting LSD functions. There's just, currently, no validation protection. This feature offers validation protection for creates, updates and deletes which is a must in an environment where multiple scripts can potentially modify an entry at the same time creating race conditions. Since it has password input, this function becomes a defacto all-in-one append function for creates, updates and deletes, something even KVP currently doesn't offer.

The way it is now, reading the PBR properties of a face using llGetPrimitiveParams() with the PRIM_GLTF_X flags will only return parameters that are overrides of the underlying material asset. In other words, it is impossible to read all PBR texture parameters via scripts. This is a severe restriction, and one that appears to be more severe than what applies to Blinn-Phong textures. Being able to get and set all texture parameters is very useful in a number of contexts. This is unfortunately made very difficult if not impossible in the current model. We need way of accessing all parameters of PBR materials applied to a surface, not just the overrides. While it may be necessary to impose permission-based limitations, at a minimum it should be possible to do this on objects that the user has modify permissions on. PS: It's not always obvious what constitutes an "override." For example, all that is needed to create an override of the Tint parameter is to click the color swatch and then immediately close the color selection dialog without clicking a color -- any color, even the currently selected one. The tint clearly doesn't change, yet the parameter is now an override.

There are many animations out there which were uploaded with a low / default priority. These are fine provided other overlayed animations running at the same time don't override their actions. It would be useful to be able to change that priority when starting the animation. eg: llStartAnimationPriority("animation", 6);

... and have it as a rezzed prim parameter so that only the prim having rezzed the other prims can address directly (and in a totally secuured way) the ones holding this pin number. Use case : derez all the builds holding a certain PIN number without needing to know their UUID, for example with llDerezObjectPinned( integer pin, integer flag ); send / upgrade scripts the same way etc. i-e it's like having created groups of rezzed objects linked to their original rezzer prim. PS: llDerezObject() is a "stupid" function till now as UUID changes except if the rezzed object is NO COPY so you can't rely on the original rezzed build UUID. It means that you can't easily derez a full build area i-e with furniture in just one function call. Anyway, it is not capable of any native area management.

I full well understand why llEmail - which can be used to send emails to inside AND outside of SL - has a 20 seconds forced delay. However, when used only inside of SL, using the lsl.secondlife.com namespace for object-to-object communication, the delay seems excessive to me. llEmail is basically the only(!) way for object-to-object communication that is reliable over long periods of time without the need to cache ephemeral URI's like we need with llHTTPRequest, where the URI changes with each restart. llEmail used in conjunction with an object UUID will run come hell or high water. Making llEmail in the lsl.secondlife.com namespace run with the typical 2 second delay (or less even), would allow scripters to keep more communication inworld and rely less on external servers. /me waits for the bot to turn it to "tracked"

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.

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

Currently, we have no way to rotate the avatar. This function would rotate the owner of the script on the Z-axis and would work as an attachment. With this, we can rotate the avatar to the surface normal of a wall, table, or other avatars without the need to use RLV functions that manipulate the camera or having to sit and unsit the avatar. This would allow for things like wall climbing and a host of other useful applications. https://gyazo.com/7d441967232c304a4fa20ce722ec18ce rotation RotNormal(vector _normal){ vector vLeft = llVecNorm( _normal % llRot2Fwd(llGetRot())); vector vFwd = vLeft % _normal; rotation rRot = llAxes2Rot(vFwd, vLeft, _normal); return rRot; } wall_climb() { vector scale = llGetAgentSize(owner); vector vStart = llGetPos() + <scale.x/2,0,scale.z/2> * llGetRot(); vector vEnd = vStart + <0.25,0,-1.0> * llGetRot(); list CN = llCastRay(vStart, vEnd, [RC_DATA_FLAGS,RC_GET_NORMAL, RC_MAX_HITS, 1]); float FW_Dist = llVecDist(vStart,llList2Vector(CN, 1) + <scale.x/2,0,0> * RotNormal(llList2Vector(CN, 2))); /* Set the position and agent rotation to the surface normal of the detected object. */ }

This feature has been promised since the debut of the experience system, in 2015. During the beta period, several were created, but since then, only land-scope experiences have been available. Being able to run experience-based systems independent of land authorization would allow for a large number of improvements in HUDs, attachments, and travel systems.