Scripting Features

llGetUnixTime() , because of LSL integer type limitation, can return only 32 bits of epoch seconds. This means that around 19 January 2038, scripts that rely on counting the delta between two unix times will likely fail to function. Some workarounds are possible, but requires a lot of code to implement. Short of introducing a new type, integer64 , a (probably) much simpler workaround is to implement the following 2 functions: list llGetUnixTime2() returns a list whose first member is the higher-order 32 bits of a 64-bit unix epoch, while the second member is the lower-order 32-bits of the same unix epoch. The latter part is a bit tricky because it should be unsigned, so manual arithmetic might be a bit complex; hence, a second function: integer llDiffUnixTime2(list unixtime_a, list unixtime_b) given two list constructs as returned by llGetUnixTime2() , the function returns the number of seconds difference according to the rule of a - b . Alternatively, encode the 64-bit unix time into string using Base64. And introduce the functions string llGetUnixTimeB64() and integer llDiffUnixTimeB64(string a, string b) . This might use less memory because list is a complex structure that requires more memory than a string .

I'd like an LSL function to find out whether a teleport would land at the intended destination. Currently if the destination is in another region, the only way to know if the avatar will arrive at the target is to teleport them and find out. I would like to check the destination first, so i dont need to start a teleport that won't arrive at the target. For example, if i wanted to teleport an avatar to another sim at <128, 128, 3020> there's no way to know if they'd actually land at that point or 3000m away on a ground landing point, or if they can't teleport into that parcel at all. The proposed function would send the avatar id and group and target position, and the remote sim would return a vector back indicating where the avatar would land. This would either be at the target destination, at the parcel's landing point, or zero_vector if they dont have permission to enter the target parcel. This would mean a teleport script can check the target first, and not teleport the avatar if they will end up far from the intended destination.

key llGetRegionWorldMapTile(string region_name) A LSL function to return the UUID of the current world map tile for a named region, so that it might be placed on a face using PRIM_TEXTURE. This could also be added to llRequestSimulatorData Currently the only ways I know to accomplish this depend on MOAP and voodoo to get an image from slurl.com , or pulling the CDN UUID from gridsurvey.com via a HTTPRequest. Which all seems pretty hacky and unfun.

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);

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.

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

Linkset data is amazing for persistent storage and sending data between scripts. Having a set of data for avatars would be great too. It would enable synchronizing settings between multiple items of the same brand a lot easier. Storing shared settings, for example access block lists for interactive attachments. Or storing settings data when before swapping to a redelivered version of the same item, that can then read it. Sending password protected data between HUDs and other attachments, instead of using chat channels. I’m sure scripters would fine plenty of uses for something like this. Functionally it should have all the features of the LinkSetData, with some differences: • No equivalent for LlLinksetDataReset, as we wouldn’t want one brand’s items destroy other brand’s item’s data. • Larger storage than 128k, as there can’t be 30k avatars in a sim, compared to regular prims, more storage shouldn’t be a problem, I’d say 1mb or more sounds reasonable starting point. • Equivalent of https://feedback.secondlife.com/scripting-features/p/edit-linksetdata-from-inside-the-viewer would be a must, with a reset all button for the viewer. We wouldn’t want a broken item filling in someone’s whole storage, so ability for the Residents to clear all data or just select data would be required. • Maybe add a permission request before item can Write/Delete AvatarData, no read permission, or auto-grant read on attach. Again, since it is permanent storage on avatar, we wouldn’t want it to be corrupted by a broken script. • In terms of documentation there should be caveats pointed out that the data can be reset at any time by the Residents and that it should not be used for storing any license key or authorization type data. • Should have a listener functionality (similar to chat listen) for specific key changes instead of an equivalent of linkset_data event, as we wouldn’t want to trigger loads of scripts on many different attachments with each change.

I'm posting this here since my original post as a bug was closed with an "expected behavior"-type reply. As referred to by the discussion mentioned in the LSL portal documentation for llGetLinkPrimitiveParams() ( https://community.secondlife.com/forums/topic/486118-only-set-ambiance-on-prim_projector/?_gl=11wd89ez_ga_T7G7P6DCEC*MTcwNjU2MzkwNS4xLjEuMTcwNjU2MzkwNy41OC4wLjA.#comment-2446570 ) the call with PRIM_PROJECTOR currently triggers shouting on the DEBUG_CHANNEL about an unsupported parameter. I understand that PRIM_PROJECTOR is considered, for now, as write only, but I see no valid reason why it could not be readable at all. The current situation is inconsistent in my opinion. While I understand the potential problem with texture rights, I believe the behavior of this parameter should be consistent with that of PRIM_TEXTURE: if the texture is in the prim's inventory, return its name, else if the owner has full permissions over the object return its UUID. Otherwise return NULL_KEY. This is important to be able to "copy" a user-set parameter from one object to another for example, I want to read the parameters and send them to another object. Please make PRIM_PROJECTOR behave just like PRIM_TEXTURE in this regard, as described in the discussion. Thanks!

The existing mono memory cap of 64kb per script is based on simulator hardware that is no longer in use. The 64k limit is regularly subject to workarounds by use of 'slave' scripts to hold on to memory, at excessive cost to performance, from having multiple scripts doing the job of one, resulting in a net loss of performance versus a single script with increased memory. Is there any possibility that this could be increased, even slightly?

With the introduction of PBR and new features in SL the The 64k memory limit is becoming increasingly hard to work with and not suitable for modern designs. When designing more feature intensive HUDS its hard not to keep running out of memory, suggestion to double or increase the limit would be very much welcome for 2024.