Scripting Features

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.

Currently the function rotates the avatar and camera, I think it would be useful if we had a flag to enable or disable the camera being rotated with the function. llSetAgentRot(rotation rot, ROTATE_CAMERA); I Believe this would add useful functionality

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.

Similar to https://feedback.secondlife.com/feature-requests/p/change-sound-pitch but with more details that would greatly increase usability. I would use this for realistic aircraft engine sounds, instead of having to upload 11 distinct engine sounds (throttle 0 through 100, step 10) I could upload one or a few and use this to set the exact correct pitch. A throttle setting of e.g. 35 doesn't have to use the sound for 30, I can use finer gradations at lower throttle settings for higher precision, etc. This is not just about vehicles. Anything a game designer would expect from UnrealEngine, Unity, etc. should be possible here as long as it doesn't require spatial audio or output chain effects (awareness of obstacles, EQ/reverb, etc.) ROI: I don't have to upload 10 sounds to get 10 engine pitches, and you don't have to pay to store or stream them. The client's CPU does the work instead of your opex. You enable MUCH richer audio experiences that can give people a very large number of reasons to come back. Right now, SL is full of beautiful places that there's no reason to visit more than once because they are _not interactive at all._ The more ways you give us to do "game engine"-style stuff relevant in _this_ decade, the more acquisition and retention we can help you drive. Some use cases would be: Vehicles (obviously) Musical instruments (you could do a full sequencer with this), whether preprogrammed, manual, or algorithmic/generative Interactive games/toys/art installations Mutable/frangible objects that respond to stress/tension/compression Various user interfaces (HUDs, kiosks, etc.) Critters Weapons Weather (beyond just the wind) Industrial machinery (motors, turbines, pumps, etc) that respond to conditions Anything else where a creator would want to go beyond "play it or loop it". API: integer handle = llPlaySoundEffect(list attributes); // >= 0 on success, <0 = error code integer llAdjustSoundEffect(integer handle, list attributes); // 1 = success, <0 = error code integer llStopSoundEffect(integer handle); // 1 = success, 0 = fail Attributes is a strided list, just like llSetPrimitiveParams() etc. Some particulars were selected to make them easy to integrate with OpenAL. Basics: LINK_NUM, integer: Which prim in the linkset. Optional. Default current. SFX_SOUND, string|key: Same as llPlaySound(). Required. SFX_VOLUME, float: Same as llPlaySound(). Required. Time: SFX_START_TIME, float: Moves the playhead to this many seconds into the sample at the beginning of playback. Optional, default 0. SFX_END_TIME, float: Can be used to shorten the sample at runtime. Optional, default full sample length. If <= SFX_START_TIME, throw an error SFX_SET_TIME, float: Immediately moves the playhead to a particular time index in a sound already playing. Optional. Does not account for playback speed. Setting time before SFX_START_TIME or after SFX_END_TIME throws an error. Does not modify playback direction (so if it's in SFX_PINGPONG [below], playback will keep going in whatever direction it was before.) Speed: (This just makes the sample play faster or slower, inherently causing a pitch change, which is the main point for any game developer. It doesn't Paul-strech or pitch-correct it.) SFX_SPEED_START, float: Adjusts playback speed multiplier at start of playback. <1 = slower, >1 = faster. Optional, default = 1. SFX_SPEED_END, float: Sets target playback speed multiplier. Optional, default = 1. When SFX_SPEED_END != SFX_SPEED_START, the playback speed will be linear-interpolated (ramped) between SFX_SPEED_START and SFX_SPEED_END. SFX_SPEED_ADJUST, float: Adjusts the current playback speed multiplier of a sound already playing. If there's an active ramp (lerp) between SFX_SPEED_START and SFX_SPEED_END, it's cancelled. The ramp occurs between SFX_START_TIME (default 0) and SFX_END_TIME (default end of clip). The ramp will restart from SFX_SPEED_START if in SFX_LOOP (see below). The ramp will reverse direction along with playback direction if in SFX_PINGPONG (see below). Loop/pingpong (mutually-exclusive, error if you try to set more than one): SFX_ONE_SHOT, boolean: Whether the sound should play once, and then stop. Optional. Default TRUE. This is only needed for adjusting a sound that's already playing in LOOP or PINGPONG, and will have the effect of canceling playback as soon as the playhead reaches either the start or end time, depending on whether it's in pingpong/loop. SFX_LOOP, boolean: Whether the sound should be played in a loop, like llLoopSound() except that it respects start/end time offsets. SFX_PINGPONG, boolean: Whether the sound should ping-pong (play forward from SFX_START_TIME until reaching SFX_END_TIME, then backwards to SFX_START_TIME, then again forwards, etc., until the sound is stopped.

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

I am not the world best typist, my slightly cramped hands mean I make a lot of typos , and in particular i don't type capital letters when I should, or I type more capitals than I want to. n LSL, case in function name is significant, so for example, llLinksetDatafindKeys has to be typed exactly. But realistically why is that so? nobody is going to create their own function llLINKSETDATAFINDKEYS , and if they did they're totally daft. I propose that the LSL compiler (and the incoming LUA compiler) simply ignore the case of LSL functions. Imagine the savings in human and computer time.

full script

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.