Scripting Features

We have many ways to Detect if an object is (left) clicked on, but no way to Detect if someone rights clicks on that same object, Why? This would be a very useful feature for the SL Racing Community and vehicle enjoyers as a whole, and I'm sure this could have many other uses for scripters in general. The reason for this request is because of the ability of a resident to effect the movement of a car (or any physical object) even if the object doesn't belong to them by right clicking on the object. I am not talking about a resident that has the person's edit rights, or estate manager of the sim they are on. But someone who has no rights to an object can still effect that object by right clicking on it, (often spamming right clicks) it will either make the object micro stutter slowing it down or out right stopping the object in place for a brief moment. Having a function that can detect a right click, much like you can with a left click, so that a script can tell you who is editing it would be very very helpful! And / Or some kind of tag that would stop physical objects from stopping when right clicked / edited would be really cool too.

From Inara Pey:- https://modemworld.me/2025/06/07/2025-week-23-sl-tpvd-meeting-summary/ "Signal Linden requested feedback on the idea of deprecating and removing Navmesh characters / llCreateCharacter (i.e. Pathfinding)." Here is my feedback:- I am getting the impression LL intends to remove all pathfinding functionality from simulators including the creation of navmesh and LSL functionality like llGetStaticPath I spent much of last year designing and putting together NPC's for my sim including scripting systems that use LSL pathfinding functionality, and spent a lot of time setting up my sim to generate good navmeshes. I will be very upset if this feature is just straight up removed. I can't keep investing my time in pioneering technology in SL if LL are not going to commit to maintaining the technology it implements and destroying my creations at random. I understand the need to transition, but basic pathfinding functionality should be maintained. I do not want to log in one day and find all of my work broken after all of the time and money invested.

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.

I'd the ability within LSL, possibly tied to a runtime permission, to be able to adjust the following parcel settings. This would be for moderation, estate management, and event management. Parcel name (string) Parcel description (string) Parcel sale (integer price, key buyer, integer sell_objects_with_land - NULL_KEY for anyone can buy, negative price (or const) to set not for sale. Should always be possible for an object running with estate manager permission, tying this to its own runtime permission for safety would probably be wise) Everyone can: Edit terrain, fly, build, object entry, scripts Group can: build, object entry, scripts Safe (damage) Pushing Show in search (+ category) Adult content Avatars on other parcels can see and chat with avatars on this parcel Landing point (quaternion (x,y,z,rotation) - have const values for blocked TP and anywhere) Snapshot (key texture_id - NULL_KEY for default/unset) Abandon land (Possibly its own runtime permission for safety, should always succeed if owned by an estate manager) Locking these adjustments behind estate manager permissions would be acceptable but not ideal only if absolutely necessary, also completely acceptable would be a reasonable script sleep penalty to prevent unfair use of server resources or abuse. Being able to specify the position or the parcel UUID to act upon for this would be nice to allow for the efficient management of estate regions and large event spaces, possibly with a const to reference the parcel the object resides in currently for convenience in non-centrally managed applications. Any changes that are not authorized would fail and result in an error. This would greatly reduce the reliance on bots / scripted agents which are currently used to accomplish these tasks. Allowing these tasks to be completed totally on-platform would simplify event/venue and estate management dramatically and reduce the load on servers by eliminating the need for bots to idle around waiting to handle these management tasks as needed.

Ability to trigger an ‘on_mouseover’ event when the mouse cursor is on a prim side. Used for example to show a floating text or a chat message to get help. The ‘delay’ parameter allows to set a delay in seconds before to execute the action in the event. The ‘link’ parameter return the link number of the prim when the cursor is. The ‘side’ parameter return the side number of the prim when the cursor is.

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

Use cases : make debugging easier for scripters structuring correctly their code with flags to enable / disable testing portions of code in spite of doing it manually with comments or copy / paste configure scripts to be dynamically optimized for a build configuration, though relying on one main script that scripters can upgrade with time and as they get better skilled etc. It is basically a free and open source feature from the C/C++ boost library https://www.boost.org/doc/libs/1_59_0/libs/preprocessor/doc/index.html (already existing into the Firestorm viewer). Anyway it is a feature needed by any serious scripter who wants to maintain code efficiently in the long term BTW making more efficient code also means using less cpu on LL servers.

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.

Requesting the following controls to be added for further usage of mouse input while in mouselook. CONTROL_ML_RBUTTON - Right mouse button control CONTROL_ML_MBUTTON - Mouse wheel/middle button control CONTROL_ML_MWUP - Mouse wheel up control CONTROL_ML_MWDWN - Mouse wheel down control I actually woke up this morning and realized that we didn't have an ML_RBUTTON and this hasn't been in since the launch of SL. I figured we could cover the rest of standard mice and modernize the old llTakeControls function to keep up with GameControl. Mice, as a standard, have a Left/Right button, as well as a Mouse Wheel and Middle button.

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