Scripting Features

It would be incredibly useful to have native support for loading and unloading JSON data directly to and from linkset data. Currently, working with complex structured data in linkset storage requires manually looping over every key and parsing or serializing data ourselves, which can be time-consuming and error-prone. I'd like to propose the following four new LSL functions to streamline this process: llLinksetDataToJson() Exports the entire contents of the linkset data store as a JSON-formatted string. This includes all key-value pairs written with llLinksetDataWrite(). llLinksetDataFromJson(string json) Parses a given JSON string and writes all key-value pairs into the linkset data store. llLinksetDataToJsonProtected(string password) Works like llLinksetDataToJson(), but returns a password-protected version of the JSON. Useful when exporting data that may need to be stored or transferred securely. llLinksetDataFromJsonProtected(string json, string password) Takes a password-protected JSON blob and writes the included key-value pairs to linkset data after verifying the password. These functions would dramatically simplify working with complex or shared data sets across scripts or objects. They'd also make it much easier to support backups, duplication, synchronization, and version control of in-world configurations.

## Proposal Very familiar syntax per llSetKeyframedMotion but for moving a camera through space with various options. * Client-side moves smoothly through the keyframes specified * KFM mode equivalent options available for e.g. forward, reverse, loop, ping pong * KFM command equiv to pause, resume, stop * Meant to be a single elegant function that achieves several usecases and familiar syntax llSetKeyframedCamera overrides (higher priority) but does not replace llSetCameraParams . If llSetCameraParams is set then pressing ESC should disable the keyframed camera and resume back to llSetCameraParams over KFC_EASE_OUT or CAMERA_*_LAG . llSetKeyframedCamera( list keyframes, list options ); Keyframes is a strided list of keyframe same as per llSetKeyframedMotion . KFC_* constants duplicate of KFM_* s or reuse the KFM constants. Requires PERMISSION_CONTROL_CAMERA or experience permissions. Keyframe list is uploaded to client with the options. Ping / time of function call / region time dilation should all be taken into account: Viewer skips/seeks forward to the appropriate frame between keyframes based on when function was called. Also the time delta between frames is affected by region dilation. This is so that a good attempt is made so that scripts can sync up in terms of llGetTime() . Calling llSetKeyframedCamera again should take into account the last keyframed camera position when it comes to KFC_EASE_IN . Camera should obey roll rotations on keyframes. For mouselook this is similar to sitting on a tilted object. Additionally: * An option to specify absolute/local coordinates instead of relative deltas (as client-side has no physics engine tie-in to require the deltas, default to non-delta for ease of use) * KFC_EASE_IN, float time — ease-in camera from current mode (mouselook, third person, alt-cam) over float seconds across beginning keyframes (equivalent to ZoomTime debug setting but for easing into the keyframed camera, default to ZoomTime , e.g. 0.4s) * KFC_EASE_OUT, float time — ease-out over float seconds across end keyframes (similar per above) * KFC_MOUSELOOK, integer enabled — whether user can look around in mouselook, rotation keyframes will still affect the base rotation unless decoupled * KFC_MOUSELOOK_FORCE, integer force — whether to force into mouselook (equivalent to llForceMouselook but might be from a HUD) * KFC_MOUSELOOK_DECOUPLED, integer decoupled — whether to decouple mouselook camera to prevent it from being rotated by keyframe rotations / target (usecase: if user does not enter mouselook to look around and instead uses third person camera and lets the keyframes rotate their camera; usecase #2: vehicle mouselook camera decoupling without mouslook steering) * KFC_TRACK_SIT, integer enabled — whether camera motion is coupled to sitting object, so keyframed camera moves relative to sat object (default TRUE) * KFC_TRACK_TARGET, integer enabled — similar to above but target an object/avatar by UUID to move keyframed camera relatively to * KFC_TRACK_ROTATE, integer enabled — whether keyframes should be rotated relatively to targets orientation instead of only position (default TRUE) * KFC_EASE_CUBIC, integer enabled — whether to use cubic interpolation between keyframes (default FALSE) * (and/or implement something like B-Spline Interpolation with weight/bias/tension parameters, e.g. KFC_EASE_SPLINE, float bias ) ## Usecases Smooth scripted camera movements through region coordinates Smooth camera movement relatively to object, avatar or sat object Smooth movement between static camera coordinates (via new call to llSetKeyframedCamera with KFC_LOOP & KFC_EASE_IN to ease into new static, looping camera keyframe pos) Camera that follows an object / avatar ( KFC_TRACK_TARGET ) Camera that orbits an object / avatar (keyframe list of positions around the target with rotations set to look at the center point) Camera follow/orbit an object / avatar but only in terms of position (e.g. if the object / avatar rotates it won't cause the camera to rotate, via KFC_TRACK_ROTATE, FALSE ) Vehicle mouselook repositioning ( KFC_LOOP , KFC_TRACK_SIT , KFC_MOUSELOOK ) Pausing, stopping or resuming keyframed camera similar to KFM_COMMAND — (however take into account the time of function call to ease into the frame it was supposed to pause at or resume from) Vehicle mouselook cameras that move along a scenic orbit around the vehicle for an occupant KFC_TRACK_TARGET can target an individual child prim of a linkset, or an attachment of an avatar to follow specifically Keyframed camera that follows a keyframed motion object ??? Many more usecases via creative parameter mixing Some usecases like being able to reposition vehicle mouselook cameras for occupants relatively to the vehicle is achievably by looping a position and enabling mouselook on the keyframed camera.

Sensors and listeners are limited in what objects they can detect, and both may require extensive setup and overhead in order to pick up all objects of interest in a region. I suggest a new function to retrieve a list of object UUIDs that the owner has permission to return, whether at the region or parcel level, or the owner's own objects otherwise. list llGetObjectList ( list filters, integer start, integer count ) Return a list of object keys matching provided filters. The list should be in the same order that the simulator stores object data, which presumably has the oldest objects first and newest objects last. Some possible filters: OBJECT_LIST_FILTER_BY_NAME, string pattern OBJECT_LIST_FILTER_BY_OWNER_KEY, key id OBJECT_LIST_FILTER_BY_PARCEL, vector pos OBJECT_LIST_FILTER_BY_TYPE, integer type pattern would ideally be the same format as used for llLinksetDataFindKeys . type would ideally align with object types used by llDetectedType . Objects owned by estate managers always have permission to return any objects in the region, so they should be allowed to see a list of all objects in the region with or without filters. Objects that are owned by the same resident/group as parcel(s) in the region have the same privilege. Objects that are given object return permission by a group role on group-owned land require the owner be present in the region to return objects, so the same behavior should be expected for this function. Applications: Updating all instances of an object in a region, without requiring a listener or even an active script in the objects Finding and returning objects with high resource consumption (land impact, script memory, etc) Finding one's own objects when you don't have permission to return objects for the parcel/region

My example use case is: I wish to host an experience-based combat game in my region. Players would need to accept my game's experience in order to receive a temp attached combat meter and weapon. The parcel also has the experience enabled in parcel settings. I don't want my players to have build rights on the region-sized parcel but I want their experience-enabled temp attach weapon that my experience provided them, to still be able to rez physical projectiles, overriding parcel build permissions since temp attachments become owned by the person they are attached to. The projectiles in that temp attached weapon would also be owned by the person it's attached to. By limiting build rights through the normal parcel settings, this ensures that unauthorized weaponry cannot be used for collision based combat and disallows players from rezzing other items/barriers/vehicles that would break gameplay. Letting experience enabled scripts to be able to continue to rez their projectiles despite parcel build permission would aid in immersion. I understand that we can accomplish much using llCastRay as a replacement for physical projectiles but it's not as immersive as having an arrow shot into the air in an arc to hit it's target on the other side of a hill. Parcel build permissions would probably need a third option besides allowing build permission for everyone or group members. The third option would be Experiences. I believe expanding Experience permissions could solve a lot of use cases besides just combat situations but it would offer a lot of solutions to making game experiences more immersive and feature rich.

Right now there's no way to make a dolly camera in SL, aside from manual panning. Similarly, chase cameras are limited to following vehicles that the avatar is sitting in. With these features, scripters could implement: Remote control vehicles Security camera views that rotate from side to side Machinima camera scripting engines Scripted tours of sims with dynamic motion Cameras that follow other avatars Independent top-down cameras for strategy games (think isometric!) and platformers (think side-scrollers!) Technical details CAMERA_POSITION_KEY would set the UUID of an object to use for the eye position and rotation. Any changes to this object's position, including via keyframed motion or omega rotation, should affect the camera's eye position according to what the client sees. Only effective while CAMERA_POSITION_LOCKED is TRUE. CAMERA_FOCUS_KEY would be the same, but for the camera focus position only. Only effective while CAMERA_FOCUS_LOCKED is TRUE. A simple implementation of this feature can reasonably ignore most other camera settings (LAG, OFFSET, THRESHOLD, PITCH, etc.) when both CAMERA_POSITION_KEY and CAMERA_FOCUS_KEY are set, without compromising on utility to scripters. Such an implementation should also adopt the rotation of the CAMERA_POSITION_KEY when CAMERA_FOCUS_LOCKED is TRUE but CAMERA_FOCUS_KEY is nil (see use cases below). A more ambitious implementation might enable CAMERA_*_OFFSET (which already exists for FOCUS) as overrides, and re-use the CAMERA_DISTANCE attribute to determine the depth-of-field target when CAMERA_POSITION_KEY is employed without CAMERA_FOCUS_KEY. Dynamic control of camera position in response to user feedback is currently unusable Although implementing position changes is possible, but involves updating the camera position to track an object with a high-resolution timer. This is both needlessly cruel to the simulator and very janky. Back-to-back llSetCameraParams() calls that update the camera position cannot be smoothed with CAMERA_POSITION_LAG in response to control() input, as the camera attempts to spline back to the non-scripted avatar camera after every input unless the CAMERA_POSITION_LAG is 0. Controlling camera rotation is currently incomplete Because SL currently assumes the avatar always wants a sensible camera orientation, there's no way right now to make an upside-down or sideways camera except in mouselook. To deal with this, it should be possible for scripters to indicate they wish to also use the rotation of the CAMERA_POSITION_KEY, at least when no camera focus is in use. (I'd really like to be able to make a car that can drive up curved walls and onto the ceiling...)

At present, it is not guarantee that your code will execute fully when running instructions in the attach event during detachment. This can be particularly annoying — for instance, when trying to revert avatar deformations upon detachment. Additionally, there are cases where this code may unexpectedly run during the attachment process, as it remains in the object's execution queue. For example put this script in an object and wear it then unwear it several times: default { attach(key id) { if (id==NULL_KEY) // DETACH { llOwnerSay("DETACH 1"); llSleep(0.5); llOwnerSay("DETACH 2"); llSleep(0.5); llOwnerSay("DETACH 3"); } else { llOwnerSay("ATTACH"); } } } On first ATTACH you will have these logs : > ATTACH On first DETACH you will have these logs : > DETACH 1 On second ATTACH you will have these logs : > DETACH 2 > DETACH 3 > ATTACH The end of the "detach" code is completed on the attachment ! It would be highly beneficial if the object could delay detachment until the attach event has fully completed.

Context: https://wiki.secondlife.com/wiki/LlSetLinkGLTFOverrides At the time of writing, this function is still in development. My understanding is that this new function is intended to reduce the complexity of llSetPrimitiveParams while being extensible enough for future overrides. If that's the case, I'm sincerely asking for the implementation to be re-evaluated from multiple angles. GLTF overrides are primitive parameters and shouldn't be excluded from llSetPrimitiveParams. I'm hoping this point is self-explanatory. Splitting some params off to a different function is not very ergonomic from a scripter's perspective, especially when llSetPrimitiveParams can already set GLTF overrides. The proposed function has problems that are solved by llSetPrimitiveParams. Most importantly, llSPP provides PRIM_LINK_TARGET so scripts can assign parameters to separate parts of the linkset in one go. This is very important for visual cohesion. If you change params via multiple calls, the changes can be individually observed as the linkset checker-boards into the new configuration. It's poor practice and looks ugly. Left: what scripters avoid. Right: what llSPP achieves. If (eg.) OVERRIDE_LINK_TARGET was added to llSetLinkGLTFOverrides, it naturally follows that scripters would need a way to change which face is being affected. Being able to change only the same face number across multiple links is not very useful, so scripters would need OVERRIDE_FACE_TARGET as well. Hopefully by this point I've illustrated why the new function should just be merged into llSetPrimitiveParams, the function is already designed to be extensible and GLTF overrides are in its domain. The new parameters are needed and would reduce the complexity of the current "omnibus" parameters like PRIM_GLTF_BASE_COLOR. It's just that separating the overrides to a new function complicates things with problems that have already been solved. Please, take a moment to review the conversations that has followed the llSetLinkGLTFOverrides proposal on Discord, in the Scripting channel.

Add the ability to receive input from game controllers such as joysticks, Xbox controllers, etc. This will allow the creation ofhHelicopters and planes that use analog input from console controllers, attachments that control drones, arcade games, cranes, machinima puppetry, etc. This new feature will be implemented by adding a LSL event game_control(...) which script authors can use to capture and respond to input from users. For further details, see https://wiki.secondlife.com/wiki/Game_control

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

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.