Scripting Features

Any user can get this information through their viewer, and rightly so as you're connecting with an external server and should be able to know where. I'm not sure what we're protecting by restricting access to this information to land owners only in LSL, but it'd be a useful thing to be able to get without requiring manual button clicks in the viewer.

Background and Motivation: LSL provides llCreateLink, llBreakLink, and llBreakAllLinks for scripted linking and unlinking of objects. Before any of these may be called, the script must hold PERMISSION_CHANGE_LINKS, obtained by calling llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS). This causes a dialog to pop up at runtime, asking the owner of the object whether to allow it to link and unlink things. Only the owner can grant this permission, and it must be requested and granted each time the script resets. This model is correct for its original purpose: a script inside one object is trying to reach out and attach itself to any other object in the world. The permission answers the question: "Do you, the owner, allow this specific script, right now, to perform linking operations?" The Analogous Script Pin System: Second Life already includes a beautifully designed precedent for pre-authorizing cross-object operations: the llSetRemoteScriptAccessPin / llRemoteLoadScriptPin system. A creator places a script inside a target prim that calls llSetRemoteScriptAccessPin(pin). A calling script then passes that same pin to llRemoteLoadScriptPin to inject scripts into the target — no runtime dialog, no owner prompt. The permission was established ahead of time , by someone who had modify rights to the prim, when they placed the pin-setting script inside it. The pin is the credential, and possessing it is the grant. The key insight: A link pin system would allow objects to be 'set up to accept linking' in the same way that script pins allow objects to 'set up to accept remote script loading'. The hard permission work is done at configuration time by someone with mod rights, not at runtime by an owner who may not be present. The Problem This Solves • It requires the owner to be present and attentive when the script runs, even if they already "authorized" the behavior by crafting the product. • It makes fully-automated, physics-driven, or time-triggered linking impractical in products where the owner is not online. • It introduces UX friction that discourages creative use of a powerful simulation feature. • It is conceptually mismatched to the scenario where both objects were built by the same creator specifically to work together. The linking permission was designed for open-ended scenarios : a script that might try to link anything to itself. The proposed link pin is for closed scenarios : specific objects that have been explicitly configured to participate in a linking relationship. Backwards Compatibility Placing a link pin requires mod rights. Objects with mod rights can already be linked/unlinked without scripting. Link pins do not elevate capability — they only reduce the runtime friction for capability the creator already possesses. The new functions are additive. Existing calls to llCreateLink, llBreakLink, and llBreakAllLinks are completely unchanged. Scripts that currently request PERMISSION_CHANGE_LINKS via the dialog continue to work exactly as before. No existing behavior changes. Objects without a link pin set cannot be linked or unlinked by the new pin-based functions. An object that was never given a pin is invisible to the new mechanism. Spec • The pin is a 32-bit integer. Creators should treat it as a private shared secret between the orchestrating script and the pin-holding object. • A pin of 0 means "no pin set" (cleared state). Setting a pin of 0 removes any existing pin. • Both objects must still be owned by the same person. The pin bypasses the dialog, not the ownership requirement. • A prim's pin persists across link and unlink operations (same persistence model as llSetRemoteScriptAccessPin). • A creator can change or clear a pin at any time from within the object by calling llSetLinkPin again. llSetLinkPin(integer link_number, integer pin) Attempts to link the calling object to target, using pin as the authorization credential in place of a runtime permission dialog. The target's root prim must have a matching link pin set (via llSetLinkPin). Both objects must have the same owner and both must be modifiable. If the pin does not match, or the target has no pin set, the call fails silently (no error is shouted). llCreateLinkPin(key target, integer parent, integer pin) Attempts to link the calling object to target, using pin as the authorization credential in place of a runtime permission dialog. The target's root prim must have a matching link pin set (via llSetLinkPin). Both objects must have the same owner and both must be modifiable. If the pin does not match, or the target has no pin set, the call fails silently (no error is shouted). llBreakLinkPin(integer link_number, integer pin) Breaks the link of a prim identified by link_number from the current linkset, using pin as the authorization credential. The targeted child prim must have a matching pin set. This is called from the root/parent prim's script, not from the child being removed.

I'd the ability within LSL, possibly tied to a runtime permission, to be able to adjust the following parcel settings. This would be for moderation, estate management, and event management. Parcel name (string) Parcel description (string) Parcel sale (integer price, key buyer, integer sell_objects_with_land - NULL_KEY for anyone can buy, negative price (or const) to set not for sale. Should always be possible for an object running with estate manager permission, tying this to its own runtime permission for safety would probably be wise) Everyone can: Edit terrain, fly, build, object entry, scripts Group can: build, object entry, scripts Safe (damage) Pushing Show in search (+ category) Adult content Avatars on other parcels can see and chat with avatars on this parcel Landing point (quaternion (x,y,z,rotation) - have const values for blocked TP and anywhere) Snapshot (key texture_id - NULL_KEY for default/unset) Abandon land (Possibly its own runtime permission for safety, should always succeed if owned by an estate manager) Locking these adjustments behind estate manager permissions would be acceptable but not ideal only if absolutely necessary, also completely acceptable would be a reasonable script sleep penalty to prevent unfair use of server resources or abuse. Being able to specify the position or the parcel UUID to act upon for this would be nice to allow for the efficient management of estate regions and large event spaces, possibly with a const to reference the parcel the object resides in currently for convenience in non-centrally managed applications. Any changes that are not authorized would fail and result in an error. This would greatly reduce the reliance on bots / scripted agents which are currently used to accomplish these tasks. Allowing these tasks to be completed totally on-platform would simplify event/venue and estate management dramatically and reduce the load on servers by eliminating the need for bots to idle around waiting to handle these management tasks as needed.

Please increase the separator/spacer allowance for llParseString2List() and llParseStringKeepNulls() from 8 to 16 for Mono and 8 to 32 for LSL3 / SLua. There are times when the parsing functions are preferred over writing/finding with Linkset Data, especially when separators, when combined with llDumpList2String(), act as multi-string replacements. We do have llReplaceSubString(), but it, sadly, can only handle one replacement string per call. Thanks in advance.

Currently, we have no way to rotate the avatar. This function would rotate the owner of the script on the Z-axis and would work as an attachment. With this, we can rotate the avatar to the surface normal of a wall, table, or other avatars without the need to use RLV functions that manipulate the camera or having to sit and unsit the avatar. This would allow for things like wall climbing and a host of other useful applications. https://gyazo.com/7d441967232c304a4fa20ce722ec18ce rotation RotNormal(vector _normal){ vector vLeft = llVecNorm( _normal % llRot2Fwd(llGetRot())); vector vFwd = vLeft % _normal; rotation rRot = llAxes2Rot(vFwd, vLeft, _normal); return rRot; } wall_climb() { vector scale = llGetAgentSize(owner); vector vStart = llGetPos() + <scale.x/2,0,scale.z/2> * llGetRot(); vector vEnd = vStart + <0.25,0,-1.0> * llGetRot(); list CN = llCastRay(vStart, vEnd, [RC_DATA_FLAGS,RC_GET_NORMAL, RC_MAX_HITS, 1]); float FW_Dist = llVecDist(vStart,llList2Vector(CN, 1) + <scale.x/2,0,0> * RotNormal(llList2Vector(CN, 2))); /* Set the position and agent rotation to the surface normal of the detected object. */ }

I've seen a rise in griefing tools being used as the hangout I run gains popularity and I've had to create a number of automated security tools to combat them so that the peace & comfort of my patrons is minimally interrupted by griefer attacks. The only problem is that due to imposed limitations on various functions, at best these security tools can only intervene retroactively & my patrons are still subjected to these attacks. If it were possible for me to get information on visitors worn hud attachments without needing them to opt into an experience (and requiring the hud attachment to also be scripted for the experience), then I could prevent these attacks nearly every time by booting visitors wearing items made by blacklisted users and such. But as it is now, griefers can still get away with carrying out an attack due to the loophole of attaching a griefing tool to their hud instead of their avatar, thus avoiding detection until they're put to use. Allowing the full use of the llGetAttachedListFiltered() function for estate managers without the experience requirements seems like a fair way to prevent abuse of the function while also allowing for more robust land security tools to be made.

Add a new function LSL function named llRenderText or similar, which allows users to dynamically render text, with limited but flexible formatting, onto the face of their choosing. Concept: // Signature llRenderText(integer face, string text, list params); // Basic example llRenderText(ALL_FACES, "Lorem ipsum...", [ FONT_ALIGN, "right", FONT_WEIGHT, "bold", FONT_FAMILY, "sans serif" ]); Rationale Text is ubiquitous, yet Second Life has no way for users to display text other than uploading a texture, setting floating text using llSetText , or using relatively resource intensive solution such as XyText/Furware/et al. This absence precludes interesting features, such as being able to create a responsive interactive terminal in Second Life, HUDs with dynamic text, etc. A scripted and efficient text solution that displays on the face of a prim/mesh would give Second Life the biggest bang for the buck: Limited in scope (easier to implement than grand UI-creation ideas) Easy to kitbash into existing and new creations For inspiration, you can look to how the Text Display widget is implemented in the Playstation game Dreams. It has limited options: a finite number of fonts and formatting options, but the fact that it can be combined with other content makes it rather powerful. Other details Font color, opacity, glow, etc are controlled by prim properties (Example: setting face color to red sets font color to red) Questions Should the background always be transparent? Creators could put another prim behind the text display face to give it a background, or it could be a property of the render params. Possible Parameters FONT_WEIGHT FONT_STYLE FONT_FAMILY FONT_VERTICAL_ALIGN FONT_HORIZONTAL_ALIGN FONT_TEXT_WRAP FONT_LINE_HEIGHT FONT_SIZE Possible Features Markdown / rich text

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

full script

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