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.

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

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.

Apply PBR material to the particle system. Should replace the texture if provided, only used as fallback when someone doesn't have the PBR viewer. Ex: [PSYS_SRC_PBR_MATERIAL, "MATERIAL-UUID-KEY-HERE"]

Texture animation is a widely used technique in various games and virtual worlds. It allows for dynamic and visually appealing effects that can greatly enhance the immersive experience for users. Enabling texture animation in the particle system, content creators would be able to create even more captivating and engaging environments. llParticleSystem is already using list for its setting. So I suggest [TEXTURE_ANIM, mode, sizex, sizey, start, length, rate] to be added for that option.

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"

llSetCameraParams already has CAMERA_PITCH to move the cam up and down around an avatar. However, it's missing left/right and roll to look from the side. I was missing this especially when using the new game_control feature to use the right stick to try and orbit around a sitter on a vehicle which isn't possible without those suggested params.

Since texture transforms aren't part of the PBR asset, we can't just use the "" hack in llSetLinkPrimitiveParamsFast(...) to preserve their values. Instead we need to record the transforms (offset/repeats/rotation) for each face and reapply them with the new alpha value. A function like llSetLinkPBRAlpha() would be very much appreciated. Coming to think if it, most use cases (except for fading) could actually be addressed by having something like llLinkVisible(LINK_THIS, ALL_SIDES, TRUE) - llLinkVisible(LINK_THIS, ALL_SIDES, FALSE) - taking the usual LINK_* constants and face numbers.