Scripting Features

## 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.

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.

We noticed that the SIT_FLAG_INVISIBLE flag was not implemented as proposed by Signal on https://feedback.secondlife.com/scripting-features/p/add-llsetsitflags-sitflaginvisible-et-al . We were hoping to have this implemented to make the avatar invisible so it would not require detaching all objects and wearing an alpha layer so you would not be rendered in smaller vehicles. It affects interacting with vehicles in a FPS setting when multiple avatars are on the objects. (For example, Avatars in the Commander Seat, Gunner Seat, and Driver Seat) This would also allow us to scale down vehicles without considering avatars rendering and ruining the immersion.

Please consider adding an endpoint to the map API for fetching data useful for navigating the grid. This data would be readily available map information. At the present, this is a very, very strange task to accomplish. We can pound LL's servers using this API: https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=region&grid_x=1000&grid_y=1000 And scanning every possible range of coordinates we think is useful. Or We can use a bot on a custom viewer, making MapBlockRequests until we've got the whole grid. Each of these really need an external service running, and hit your servers pretty hard--but it's all for information that you already have that would be valuable to us to use for scripted applications (eg for navigation HUDs, custom maps, games with distributed locations, exploration apps, touring pods) and also, just in general to know how our world is doing. Proposal: Two https endpoints to fetch paginated region info lists. First API endpont: region list by number. The order is determined by LL and is arbitrary, but is used for pagination. A script can ask for the first N regions, then another set of regions starting from N and so on. In this way, scripts can parse the region list without hitting the api server, sim, or script memory too hard Second API endpoint: region list by name. Similar to searching a word on the map and getting one or several regions that match the name. Responses are delivered as JSON, with each region'd details in an object of the following form: { { "name" : "Da Boom", "coordinate" : "<1000.0, 1000.0, 0.0>", "estate_name" : "mainland", "region_map_image" : "7963f194-82f9-23b3-3d89-c21f1bd0a8bc", "access_name":"Moderate" } } Example of using the first endpoint, the enumerated API: The endpoint can be called with a page number, and an optional maximum. For example, suppose we are permitted up to 25 list items in a single call: Example: Fetch default 25 items starting with the 437th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=437 Example: Fetch only 5 items starting with the 75th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=75&length=5 In this way, external services we write and LSL code in-world could reasonably work with the large list of region data in a way that doesn't flood the API (feel free to rate limit) and that permits us to work within script memory limits. Example of using the second endpoint, the named API: The endpoint is called with a search term, and returns one or more regions that have a name starting with the term. There should be a minimum character limit. Ecample: Fetch regions starting with the name "Da B" https://cap.secondlife/com/cap/NAME_ENDPOINT?search=Da%20B Summary: There are many standing requests for access to the map tile information, map region names, and map grid coordinates, all in separate feature requests. I propose this API mechanism to capture data you already have in a way that solves every request.

Currently, there is no way to drop an object onto the ground after attaching it via script. I propose adding llDrop() to enable this functionality. Unlike llRezObject() or llDetachFromAvatar(), llDrop() would allow an attached object to be placed back into the world without being sent to the user’s inventory. This would provide a seamless interaction where a user can pick up an object with llAttachToAvatar() and later place it elsewhere using llDrop(), without unnecessary inventory management—creating a more intuitive "pick up and set down" experience. Requires PERMISSION_ATTACH to have been granted. Possible Rules: DROP_ALIGN_NORMAL – Aligns the object to the surface normal at the drop location. DROP_PHYSICAL – Enables physics on the dropped object, letting it fall naturally. DROP_PHANTOM - Drops the object with phantom properties. DROP_TEMPORARY – Drops the object as a temporary item that auto-deletes after some time.

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

Dark theme is the standard for modern script editors and IDE's. Statistically speaking you're likely to be viewing this canny in dark mode, have a dark themed discord, browse the web in dark mode etc. With the advent of Lua we should also show new creators that we are keeping with the times and meeting modern expectations by providing a dark mode by default in the script editor.

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

Implementation: https://gist.github.com/FelixWolf/8ef1ced3cd1aa37c5dc803d7a79e43d8 (Contributor agreement should cover this, I think?) I requested this on the Jira back when it was around, but it was closed due to endianness issues on various machines. I've written a implementation that packs the float into base64, and visa versa, regardless of endianness. It currently encodes in big-endian, which llIntegerToBase64 and llBase64ToInteger do. It would be really useful if we need to preserve floating point values in a short string. Benefits of this over doing (string) for floats is that: Extremely precise floats don't end up like 1.258532194328154328 LSL cuts off floating point precision after the 5th precision (EG: 0.12345 instead of 0.1234567890)

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.