Scripting Features

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

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

In a discussion following SUG, we were trying to come up with a way to handle the issue of GLTF Overrides setting properties "all or nothing" in cases where override properties were not set, and the problem of needing to know what those properties were, combined with the issue of the simulator lacking the actual values from the material. Here is a solution that seems workable: If the material asset is included within the object's inventory, allow us to fetch its values using llRequestInventoryData. In this way, creators who intend to alter these properties can choose to include the material asset and sample the properties as needed, allowing for lots of new functionality to restore appearances and to fetch properties where no override was specified. This would also solve the problems discussed with overrides.

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.

At the last Sim Meeting, there was a brief discussion about allowing scripts to toggle the locking feature of prims or objects. This functionality could be integrated into llGetPrimitiveParams/llSetPrimitiveParams or established as an independent function. For security purposes, a script should not be able to modify the state of a locked object unless it has already been introduced to the object. Additionally, the script should trigger a permission event and require explicit approval from the object's owner before executing any changes.

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

Given the present state of attacks (and man-in-the-middle attacks), using self-signed certificate as mentioned in https://wiki.secondlife.com/wiki/LlRequestSecureURL is no longer a decent option.

Pretty self explanatory. Creating a tab in the object edit window to maybe enable and disable scripts individually without having to open them. Using a way to tag and serialize some of the variables so they can be tweaked at run time. See what unity does with it's inspector. Keeping the set values between script resets too. -It would allow scripters to easily tweak variables without openning the script and changing by hand and restarting it or making a whole system with a listener just to changer a few variables that will remain unchanged once properly set. -It would allow a way for users to be given access to some script variables from the edit tab without having to bloat the scripts with a whole menu system to handle them. Keeping a lot of scripts as light as possible server side this way.

Please add an OBJECT_ESTIMATED_TRIANGLES constant to llGetObjectDetails(). This will return the streaming cost calculated triangle count for an object or agent. This value is already known to the server for all agents, rezzed objects or attached objects. At the advent of llDerezObject() and DEREZ_TO_INVENTORY, I'd like to create a character creator for my animesh application that allows users to swap out heads, hair, clothing, accessories, etc. and save their creations for later use. This application needs to know current character triangles, before and after linking/delinking content since animesh currently has a 100K estimated triangle cap. Also, this data point, when used in conjunction of other overall data, can act as a quick identifier for a linkset instead of compiling data for every link.

I propose the following API: key llStartAnimationOptions(string animation, list options); key llStartObjectAnimationOptions(string animation, list options); Params: animation: The name of the animation to start options: An option list, in the same style as llSetPrimitiveParams and other such functions. Return value: A key which can be passed to llStopAnimation to cancel the animation. When animations are started in this way, they are not uniquely identified by their name in the way that traditional animations are. There can even be multiple copies of the same animation running. So this key is needed toi identify an instance of the animation. Options: [ANIMATION_RATE, float rate]: A multiplier applied to the rate of the animation, so 2.0 plays at double speed, and 0.5 plays at half speed. [ANIMATION_OFFSET, vector offset]: Offset the root position of the animation by the given vector. Defaults to 0. [ANIMATION_SCALE, vector, scale]: Scales the root position of the animation by the given vector. Defaults to 0. [ANIMATION_PRIORITY, integer priority]: The priority of the animation. If not specified, defaults to the priority set at upload time. [ANIMATION_LOOP, integer loop]: If TRUE, the animation is looped. If FALSE, not. If not specified, defaults to the setting at upload. ... ditto for overriding other upload options. JUSTIFICATION: It is currently very difficult or impossible to use off the shelf animations purchased from other creators in scripted objects. The relative timing between animations has to be just right. The scale of the animation has to match the size of the object, meaning creators often have to resize their objects to match the animation rather than their own vision, and it's impossible to make an animated object resizable without screwing up the animations. When layering animations, you have to just hope the creators uploaded them with the right relative priorities, but you always get that one creator who decided that if you're catching a ball you legs should be exactly in this position at the max priority, so the avatar stands up awkwardly when the catch anim is played, and so on. These options are intended to return some control over how an animation is used to the user of that animation, so that it can be adjusted to match a build. Of the upload options that can be overridden, the most important are the priority (to layer animations reliably) and the in percent or frame. The latter can be used for all sorts of interesting tasks, like resynchronizing animations in the middlke of playback by restarting them with a different input frame; or selecting just portions of longer animations to use in specific contexts.