Scripting Features

As a sim owner, I wish I could get better insights into prim (aka Land Impact) usage within my land. One key thing for me is I want to one day offer skybox rental in my region, but it is difficult to calculate land impact usage llGetPrimUsage(key avatar, list options); Options support the following:- PRIM_USAGE_PARCEL Get the amount of prims the agent is using within the parcel. PRIM_USAGE_REGION Get the amount of prims the agent is using within the entire region. PRIM_USAGE_AREA, vector bound_lower, vector bound_upper Get the amount of prims used in the specified area The last option would be the most useful for me as it would give me a way to measure land impact being used within skyboxes.

Currently there are a lot of things that damage your avatar via colliding with things and it triggers DAMAGE_TYPE_IMPACT We are forced to use llAdjustDamage to negate this to do things like dodge rolls without dying, but it can be unreliable and also just takes up uneccessary resources to have every avatar in a sim doing it constantly. Please allow for a land / estate setting, or a region debug setting to just disable DAMAGE_TYPE_IMPACT entirely so that avatars don't take impact damage at all, thus freeing us from needing to use work arounds.

I am working on a suite of object management scripts, and would find it useful to able to discriminate between locked objects and objects left unlocked. This would allow me to discriminate between stray objects and perma-builds in my roleplay sim when looking for stray objects that need cleaning up.

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

key llGetRegionWorldMapTile(string region_name) A LSL function to return the UUID of the current world map tile for a named region, so that it might be placed on a face using PRIM_TEXTURE. This could also be added to llRequestSimulatorData Currently the only ways I know to accomplish this depend on MOAP and voodoo to get an image from slurl.com , or pulling the CDN UUID from gridsurvey.com via a HTTPRequest. Which all seems pretty hacky and unfun.

Currently, llSetLinkGltfOverrides takes a link number parameter. In some programming paths, it's useful to then be able to swap to another link number within the same function call. llSetLinkPrimitiveParamsFast already supports this path by way of PRIM_LINK_TARGET , which allows the command to select another link to work on. This should also be supported by llSetLinkGltfOverrides

New LSL function that allows scripts to toggle an object’s Animesh property state at runtime. llAnimeshEnabled(integer enabled); ## Overview Currently, enabling Animesh on an object significantly increases its land impact, even when the object is idle. In contrast, a comparable non-Animesh object—especially one with well-optimized geometry and materials—can often remain at a land impact of 1. At the same time, Animesh animation itself is already fully script-driven. Functions like: llStartObjectAnimation(string anim) llStopObjectAnimation(string anim) llGetObjectAnimationNames() allow scripts to control animation playback dynamically. However, these functions only operate after an object is already in an Animesh-enabled state. This creates a structural limitation: creators can control what an object does, but not whether it needs to be Animesh at all at a given moment. ## How Animesh Currently Works Animesh objects function by associating a skeleton with a rigged mesh linkset. When a script plays an animation, the skeleton drives deformation of the mesh. Importantly: An object does nothing by default when set to Animesh Animations must be explicitly triggered via script The visual position of the mesh is driven by the skeleton and active animations, not strictly the object’s base transform This means Animesh is fundamentally an on-demand animation system , but it is currently forced to be always enabled at the object level , regardless of whether animations are playing. ## Problem There is currently no way to: Disable Animesh when no animations are running Return an object to a low land impact idle state Dynamically enable Animesh only when animation is required As a result, creators must choose between: Keeping Animesh permanently enabled (high land impact, unnecessary overhead) Building complex systems involving object swapping, rez/re-rez logic, or duplicate assets ## Use Case There is a strong need for objects that can dynamically transition between static and animated states. For example: A robot or pet that remains dormant until activated Creatures that only animate when a user is nearby Props that “wake up” briefly to perform an action Environmental elements that animate only during interaction In all of these cases, the object does not need continuous skeletal evaluation. ## Expected Behavior enabled = TRUE - Enables Animesh on the object - Allows use of llStartObjectAnimation and related functions enabled = FALSE - Disables Animesh - Stops all active animations - Returns the object to static mesh behavior - Restores lower land impact where applicable ## Benefits Land Impact Optimization Objects only incur Animesh cost when actively animating Performance Efficiency Reduces unnecessary skeletal evaluation on idle objects Cleaner Content Architecture Eliminates the need for duplicate objects or rez-based workarounds Better Alignment with Existing API Design Complements existing animation control functions by adding missing state control ## Additional Considerations State transitions should preserve: - Object transform - Linkset integrity - Script execution state Simulator safeguards may be needed: - Throttling or cooldown on toggling - Permissions checks to prevent abuse Documentation should clarify: - Effects on physics and collision - Bounding box changes - Interaction with pathfinding and attachments

Related issue: https://feedback.secondlife.com/feature-requests/p/add-support-for-prim-link-target-to-llsetlinkgltfoverrides Given the command structure of llSetLinkGltfOverrides, if the related issue is merged it may be useful to be able to swap which face (or, ALL_SIDES) is being worked on after the initial selection. Unlike llSetLinkPrimitiveParams , the face selection does not happen within the parameter list, instead happening at initialization of the command, so give the user an option to swap which face is being targeted after initialization.

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

Option 1: an event to read alerts (the easiest one, requires parsing) Option 2: an event to capture a restart, or a cancellation