Scripting Features

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'd like llGetAttachedListFiltered to be expanded to let me search attachments by a regex. https://wiki.secondlife.com/wiki/LlGetAttachedListFiltered This would allow me to quickly detect eg. roleplay objects etc without needing to bring every attachment key the agent has worn into memory.

Summary llLinksetDataReset() can currently be called by any script anywhere in a linkset. It deletes the entire linkset datastore, including entries created with llLinksetDataWriteProtected() . This means that an unrelated script in any child prim can erase all protected data, despite being unable to read, overwrite, or individually delete those entries without the correct password. Use case Complex linksets are often assembled from independently scripted products. For example, a rezzer-managed building may contain linked furniture whose scripts were written under the assumption that the furniture owns its entire linkset. Such a furniture script might reasonably call llLinksetDataReset() during initialization or a factory reset to guarantee an empty datastore. Once that furniture has been linked into a larger build, the same call silently destroys the datastore belonging to the entire build, including protected entries used by the rezzer. Conversely, protected entries cannot simply be made immune to resets. When two linksets are joined, their datastores are merged. The controller of the resulting linkset must remain able to remove protected data inherited from the other linkset, since it cannot be expected to know passwords chosen by unrelated products. Proposed behaviour Restrict llLinksetDataReset() so that it succeeds only when called by a script located in the current root prim. A call originating from a child prim should be ignored or otherwise fail without modifying the datastore. This provides a natural authority boundary: * A standalone product can reset its own datastore because its controller is in its root prim. * After that product is linked beneath another root, its scripts can no longer erase the resulting linkset’s complete datastore. * The controller in the new root can still wipe and rebuild the datastore, including removing protected records inherited during linking. * Password protection continues to govern individual protected-entry operations. Rationale The linkset datastore is itself a property of the root prim. Giving only scripts in that prim authority to erase the entire datastore is consistent with that ownership model. Currently, protected entries are protected against every destructive operation except the most destructive one. Restricting wholesale reset authority to the root prim would close that gap without making inherited protected entries impossible for the resulting linkset’s controller to remove.

Allow modification of a shape (provided it is modifiable) setting any of the parameters available on Edit shape. Prerequisites:- Script must be on a worn attachment (& therefore belong to the wearer) Worn shape is modifiable New permissions request - say Permission_Change_Shape = 4096 LSL functions: (list)llGetShape[list params1); Delivers list in correct format to be supplied to ... (integer)llModifyShape(list params2); Delivers True is successful params1 = [Body_Height, Body_Leg_Length ...] -> params2 = [Body_Height,50, Body_Leg_length,40 ...] Even if the modifications don't survive a relog this would be most useful. If they are not saved then editing shape then saving should really save the changes or unwear & rewear picks up original again

Currently, a mod script gives a full stack trace of an error, no mod scripts do not. As a creator, this means it is not possible to get a detailed error report from a script you have sent to other users. Example of error when the script is mod (current behavior): Object [script:test error debug lua script] Script run-time error 'state_entry' is not a supported event name [C] function on [C] function __newindex lua_script:2 Example of error when the script is no mod (current behavior): Object [script:test error debug lua script] Script run-time error runtime error This is rightfully done due to the concern of leaking source code info publicly. However, it can be a major headache when trying to troubleshoot issues. Adding a debug flag to scripts to enable public stack traces so a creator can choose to send a no mod script with debugging enabled would solve this use case. With the debug flag enabled, the script would then report the errors just like they do when the script is mod, but the script could remain no mod. This flag should apply to both lsl-luau and lua as they are both affected by this behavior.

Please add an OBJECT_SIT_TARGET_COUNT constant for llGetObjectDetails() so applications/users can remotely know how many "seats" a vehicle or furniture piece has. Thanks.

What parameters can currently be used with llSetLinkGLTFoverrides I want it to be usable with llsetLinkPrimitiveParamsFast With gun effects, drawslings, and option switching I want to write PBR and BP so that their appearance can be switched at the same timing Currently I just want to switch the alpha, but I need to hold the UUID as a variable It has caused quite a bit of inconvenience in terms of memory consumption and ease of understanding of descriptions

Scripters have long bemoaned the limitations of llStartAnimation and llStartObjectAnimation , and proposed a number of enhancements. It could be a lot better with only minimal changes to the simulator and the simulator-viewer protocol. Here are examples of great enhancements that could be made by just sending a little bit more data to the viewer along with the llStartAnimation message. To illustrate, I will name the new functions: llStartAnimationWithParams llStartObjectAnimationWithParams 1. Queuing When I ask others how the animation system is lacking, the most common complaint is Queuing one animation to play after another. Now, a script can send the viewer the message: llStartAnimationWithParams(anim, [ANIM_QUEUING]); When the viewer receives this message, it will do one of the following: If the avatar has no other active animation marked ANIM_QUEUING , it will play the animation normally Otherwise, the viewer will delay the animation start until all earlier ANIM_QUEUING animations on that avatar have stopped, either from ending, or by calling llStopAnimation . Caveat: This will currently not work well on Animesh, because animesh animations never automatically stop. I find this caveat acceptable. This is similar to the existing sound function llStartSoundQueuing . 2. Syncing This one is near to my heart. A script is animating two or more avatars. It designates one of those avatars as the leader: llRequestPermissions(leader, PERMISSION_TRIGGER_ANIMATIONS); llStartAnimationWithParams(leader_anim, [ANIM_SYNC_LEADING]); It designates the other avatars as followers: llRequestPermissions(follower, PERMISSION_TRIGGER_ANIMATIONS); llStartAnimationWithParams(follower_anim, [ANIM_SYNC_FOLLOWING, leader]); When the viewer is asked to start an animation marked ANIM_SYNC_FOLLOWING , it: Downloads the animation Waits until any leader animation marked ANIM_SYNC_LEADER encounters a loop point (including waiting until an ANIM_SYNC_LEADER animation is started at all) Starts the animation normally This is very similar to these existing sound functions: llLoopSoundMaster llLoopSoundSlave llPlaySoundSlave It would be up to the animator to create animations suitable for syncing. Synced animations should usually: Have identical loop durations Have no loop-in period The most flexible leading animation will be 0 priority and an animate zero bones; providing nothing but a looping beat. This is also true of llLoopSoundMaster ; The best master sounds are silent. 3. Property overrides Animation assets have a number of parameters you can set at upload time, but can't be changed afterward. It would sometimes be nice if you could change them, and, llStartAnimationWithParams provides a convenient place to override them. The most useful ones to override would be: ANIM_PRIORITY ANIM_DURATION ANIM_EASE_IN ANIM_EASE_OUT 4. Speedup Similar to ANIM_DURATION above, but, speed up the animation by a constant factor, regardless of the asset's native duration: llStartAnimationWithParams(anim, [ANIM_SPEED, 2.0]); // Double speed = half duration llStartAnimationWithParams(anim, [ANIM_SPEED, 0.5]); // Half speed = double duration 5. Blending Allow an animation to not fully replace any channels in animations in overrides, but, linearly blend the bones between this animation, and the next-lowest one in the animation stack: llStartAnimationWithParams("breathing", [ANIM_BLENDING, 0.1]); This one would require the most changes to the viewer, but would open up new ways to animate characters, and would often allow multiple animations to be consolidated together more flexibly Summary I hope you can consider this proposal. I considered it carefully so that it can be implemented with minimal changes to either simulator or viewer. I heavily limited the scope, so it has a clear end point, unlike Puppetry: It does not require changing the animation asset format It does not require any new viewer -> simulator communication, beyond the existing message "hey this animation ended". It does not require the simulator to download or understand animation assets. It does not require new simulator -> viewer communication. It only adds a few new fields to the existing "animation started" message llStopAnimation and llStopObjectAnimation require no changes

An async sleep function is probably very handy for lua scripts that are written entirely around coroutines. I haven't yet needed it myself, but, I also haven't yet written a simulation script. It might be equivalent to one of these: function llscript.sleep(time: number) -- async sleep. Does not pause event loop local thread = coroutine.running() assert(thread, "Must be called from a coroutine") LLTimers:once(time, function() coroutine.resume(thread) end) coroutine.yield() end or function llscript.sleep(time: number) -- async sleep. Does not pause event loop if called from a coroutine local thread = coroutine.running() if thread then LLTimers:once(time, function() coroutine.resume(thread) end) coroutine.yield() else ll.Sleep(number) end end

There are many animations out there which were uploaded with a low / default priority. These are fine provided other overlayed animations running at the same time don't override their actions. It would be useful to be able to change that priority when starting the animation. eg: llStartAnimationPriority("animation", 6);