Scripting Features

A lot of scripted objects need to be set for a specific group, for example for commercial events, where gift-givers need to be set to the event group. llSameGroup allows to check the group and give a warning to the object owner, but then you need to rely on a timer and regular checks to react for when the group is changed. Having a group change trigger an event would solve that quite nicely.

I found a request for llLinksetDataWritePublic; I'm requesting something similar but distinctly different, hoping this will be compatible with what we have now. I'd like to request a variant of the linkset data functions with the word Remote, and a pin parameter. This set of functions would permit scripts in objects to get or set the linkset data in other objects via a secret access pin when the prim is set to Mod. There's precedent for this! We have remote script pin, for starting/stopping/replacing scripts in other objects. I propose we do the same for data. (I'll bold the new functions & events, the rest work like their current counterparts) Function Spec: function integer llSetRemoteLinksetDataPin(integer pin) Allows a prim to have scripts remotely get and set linkset data function integer llLockRemoteLinksetDataPin(integer pin, integer Locked) Allows a prim to be set to prevent linkset data access from being granted via pin, using a different pin. Eg, a creator could use a pin to set lock to TRUE, preventing a customer from enabling remote data access with a Mod prim. integer llLinksetDataRemoteWrite( key target, integer pin, string name, string value); string llLinksetDataRemoteRead( key target, integer pin, string name); integer llLinksetDataRemoteDelete( key target, integer pin, string name ); list llLinksetDataRemoteDeleteFound( key target, integer pin, string pattern, string pass ); llLinksetDataRemoteReset( key target, integer pin ); integer llLinksetDataRemoteAvailable( key target, integer pin ); integer llLinksetDataRemoteCountKeys( key target, integer pin ); integer llLinksetDataCountFound( key target, integer pin, string pattern ); list llLinksetDataListKeys( key target, integer pin, integer first, integer count ); list llLinksetDataFindKeys( key target, integer pin, string regex, integer first, integer count ); Read, Write, and Delete functions traditionally have a *Protected variation that works the same but adds a string password. This spec could extend protected functionality as well, or we could choose to implement just the functions above to alow data that is "already public." Events Spec: Minimal spec, using existing event: linkset_data( integer action, string name, string value ) Gains the following constants: LINKSET_DATA_REMOTE_RESET | The remote linkset's datastore has been cleared by a call to llLinksetDataRemoteReset. LINKSETDATA_REMOTE_DELETE | A key in the remote linkset's datastore has been deleted. Either through a call to llLinksetDataRemoteDelete or llLinksetDataRemoteWrite with an empty value LINKSETDATA_MULTIDELETE | A comma separated list of the keys in the remote linkset's datastore which have been deleted through a call to llLinksetDataRemoteDeleteFound. Maximal spec, using a new event: function integer linkset_data_listen( key target, integer pin ) | Fires a linkset_data_remote when the remote linkset data changes. Returns handle function linkset_data_close( integer handle ) | No longer fires an event when a remote linkset changes. Event linkset_data_remote( key linkset, integer action, string name, string value ) | Receives all linkset data events from the remote object as though it were that objecct itself. I see a minimal event spec as being useful and easier to implement; it essentially just tracks when successful remote linkset operations instigated by this script have completed. This provides the minimal needed feedback, and the script would need to check remote data when it intends to use it. The maximal spec might generate a lot of events between objects. But, it's nothing we're not already doing, more clumsily, with the messaging system, but this way would be much cleaner. With a dedicated listen/event event, we could properly have a multi-object game using common data, with events and functions fired by remote trigger. A real game platform! One consideration: It might be desireable to have mod objects, without allowing third-party control. I have included a function to lock/unlock pin access for this purpose.

Limits on strings are in bytes[1] everywhere it matters. llStringLength returns a count of characters (code points, presumably). Luau already gives us string.len() utf8.len() to distinguish between the two. ll.OwnerSay("bytes: " .. string.len("abcdᴥ")) // 7 ll.OwnerSay("points: " .. utf8.len("abcdᴥ")) // 5 The suggested approach to getting the byte length of a string in LSL is to convert it to base 64, parse that to a list to strip padding, cast the list back to a string, get the length of that string (since the code point count will now (nearly) match the byte count), and do some math to clean it up. For complexity, performance, and GC, It would be nice if we didn't have to do that. Mono having a utf-16 soul might complicate things? - although vm 2025 certainly uncomplicates them again if so. [1] https://wiki.secondlife.com/wiki/Limits#Communication https://wiki.secondlife.com/wiki/LlGetNotecardLine https://wiki.secondlife.com/wiki/LlHTTPRequest https://wiki.secondlife.com/wiki/LlEmail ... etc ---- Also related- https://feedback.secondlife.com/scripting-features/p/functions-to-get-byte-count-of-a-notcard-line-as-well-as-total-bytes-used-availa

In llGetPrimitiveParams, we have the ability to get PRIM_SIZE, which is a vector giving us the bounding-box size of the prim. It is possible for the physics shape to be something other than the visible size of the object, making it rather tricky to deal with. What's more, based on the scale of the object, the physics size is sometimes altered automatically. It would be very handy to be able to detect the size of the object's physics shape in order to work flexibly with the circumstances.

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

Add a new method for material animation. This function would allow for independent channel animation on different faces of the same link or faces throughout a linkset. Rules for a material channel override containing an empty list are not animated. New/Improved Mode Flags: ANIM_ON: Starts the animation. LOOP: Repeats the animation indefinitely. REVERSE: Plays the animation backward. PING_PONG: Alternates between forward and backward animation. SMOOTH: Provides smoother transitions between frames. ROTATE: Rotates the texture map (e.g., for rotating textures). SCALE: Animates texture scaling. BLEND: Cross-fades between frames for smoother transitions. RANDOM_START: Randomizes the start frame in the animation sequence. SYNC_ALL_LINKS: Synchronizes animations across all linked objects. SYNC_CHANNELS: Synchronizes animation material channels. ie base, metallic, normal, emission. FRAME_BLEND: Allows frame blending (interpolation between frames). The material rules would contain the following: string material_UUID: Defines the texture asset to be used for the material. integer size_x: Defines the grid size (for sprite sheet-based animations or texture tiling). integer size_y: Defines the grid size (for sprite sheet-based animations or texture tiling). float start: Start position in the animation cycle. float length: Length of the animation cycle. float rate: Speed of the animation. float transition_time: Optional parameter for smooth transitions between frames. Example Useage: // Define mode flags integer mode_flags_face_0 = ANIM_ON | LOOP | SMOOTH | SCALE; integer mode_flags_face_1 = ANIM_ON | LOOP | REVERSE | PING_PONG; integer mode_flags_face_2 = ANIM_ON | LOOP | SMOOTH | ROTATE | FRAME_BLEND; // Animation rules for face 0 (Base Color, Metallic, Normal, Emission) list base_color_rules_face_0 = ["UUID-of-BaseColor-Texture", 4, 4, 0.0, 1.0, 0.5]; list metallic_rules_face_0 = ["UUID-of-Metallic-Texture", 2, 2, 0.0, 1.0, 0.8]; list normal_rules_face_0 = ["UUID-of-Normal-Texture", 3, 3, 0.0, 1.0, 1.0]; list emission_rules_face_0 = ["UUID-of-Emission-Texture", 4, 4, 0.0, 1.0, 1.2]; // Animation rules for face 1 (Base Color, Metallic, Normal, Emission) list base_color_rules_face_1 = ["UUID-of-BaseColor-Texture2", 3, 3, 0.0, 1.0, 1.0]; list metallic_rules_face_1 = ["UUID-of-Metallic-Texture2", 3, 3, 0.0, 0.5, 0.5]; list normal_rules_face_1 = ["UUID-of-Normal-Texture2", 3, 3, 0.0, 1.0, 1.0]; list emission_rules_face_1 = ["UUID-of-Emission-Texture2", 3, 3, 0.0, 0.8, 1.2]; // Animation rules for face 2 (Base Color, Metallic, Normal, Emission) list base_color_rules_face_2 = ["UUID-of-BaseColor-Texture3", 5, 5, 0.0, 1.0, 1.0]; list metallic_rules_face_2 = ["UUID-of-Metallic-Texture3", 5, 5, 0.0, 1.0, 1.5]; list normal_rules_face_2 = ["UUID-of-Normal-Texture3", 5, 5, 0.0, 1.0, 1.0]; list emission_rules_face_2 = ["UUID-of-Emission-Texture3", 5, 5, 0.0, 1.0, 1.2]; // Set animations for face 0 llSetLinkMaterialAnim(2, 0, mode_flags_face_0, base_color_rules_face_0, metallic_rules_face_0, normal_rules_face_0, emission_rules_face_0); // Set animations for face 1 llSetLinkMaterialAnim(2, 1, mode_flags_face_1, base_color_rules_face_1, metallic_rules_face_1, normal_rules_face_1, emission_rules_face_1); // Set animations for face 2 llSetLinkMaterialAnim(2, 2, mode_flags_face_2, base_color_rules_face_2, metallic_rules_face_2, normal_rules_face_2, emission_rules_face_2);

llDialogTimed( key avatar, string message, list buttons, integer channel,float timeout ); and llTextBoxTimed( key avatar, string message, integer channel,float timeout ); Two new functions behaving like originals but that vanished after a time Very often we set a timer event after a dialog or textbox after witch we listenRemove putting same time will cause it to disappear when no more expected.

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

Currently, the only way to attach an object is to rez it in world and then have the object call llAttachToAvatar or llAttachToAvatarTemp. Could we have new functions can directly attach an object from the inventory of the object the script is located in? For example: llAttachInventoryToAvatar(string inventory, integer attach_point) llAttachInventoryToAvatarTemp(string inventory, integer attach_point) The PERMISSION_ATTACH permission will still be required with the destination avatar determined based on the permission - same as how llAttachToAvatar and llAttachToAvatarTemp works today. Having these new functions improves the main use cases - a store could directly attach a demo product to an avatar without having to first rez it somewhere in the store. A roleplay sim could attach temporary items to players. Vehicle HUDs could be attached when driving. The current 'rez in world first' requirement causes the object to flash in world or require other strange workarounds. If there are potential security concerns (e.g. guests without rez access trying to cause trouble) then this new functionality could require parcel rez access, even though it wouldn't be directly used.

Some external services deny a request if a HTTP_ACCEPT header is present. However, llHTTPRequest enforces that header, using "text/plain;charset=utf-8" if no other header (out of a small list of available options) is present. As Monty Linden confirmed in https://community.secondlife.com/forums/topic/521090-grid-ssl-cert-updates-coming-soon/#findComment-2881062 , empty HTTP_ACCESS headers are not allowed. I would like to suggest that making a llHTTPRequest call with an explicitly empty HTTP_ACCEPT header will remove that header altogether in http-out calls. Examples: llHTTPRequest(url, [],"" ); No HTTP_ACCEPT set, default "text/plain;charset=utf-8" gets used. llHTTPRequest(url, [HTTP_ACCEPT, "application/json”],"" ); Specific HTTP_ACCEPT set, so only "application/json” gets accepted. llHTTPRequest(url, [HTTP_ACCEPT, ""],"" ); Empty string gets passed - HTTP_ACCEPT header gets removed completely. The chances for breaking existing content are slim, since a scripter would have had to explicitly pass an empty string (in violation of the documentation), and then rely on it being substituted with text/plain. Since work on the http-out part is underway anyway, this would be an ideal opportunity to add this feature.