Scripting Features

Texture offsets for phong and PBR textures work differently now. If you apply a phong texture and offset it, then do the same thing with a PBR texture, you'll end up with a different result. The PBR Y axis texture offset (but not the X) must be inverted in order to display the same area of the texture. In a similar vein, when you scale a phong texture it stays centered. Scaling a PBR texture "zooms into" the top left corner of the texture, instead. The attached images showcase both issues. In order to display the white part of the texture, phong requires a <-0.25, -0.25, 0> texture offset while PBR requires <0, -0.5, 0>. As an example of why this is a problem, think of a chess game that has all its piece textures in a single texture atlas. Each tile on the board is a separate texture face, and you can choose which piece is in which position by adjusting the offsets for each face. Since PBR offsets work differently, if you want to add PBR support to this game you'll be forced to add additional code and use more memory to change the different offsets. As keeping both texture sets synced is a must, this means extra work for developing and maintaining this kind of code, while also adding to the extra memory load required to handle PBR textures in a script. Making offsets and scaling work the same way for both PBR and phong would make this sort of scripting much easier.

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.

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

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.

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.

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?

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

By its own admission, llGiveInventory is not reliable: https://wiki.secondlife.com/wiki/LlGiveInventory Because of this, delivery scripts have to resort to tricks to attempt to work-around the problems. The most egregious trick required is testing the online status of the intended recipient. This is a huge privacy violation. Technically, it is in violation of the Terms of Service. At the very least, llGiveInventory should return an error if the intended recipient is offline, though even this is also a privacy violation. Also, no-copy objects are too easily lost. Marketplace manages to avoid these problems. Perhaps llGiveInventory can be changed to add an entry to Marketplace's delivery queue. This would also have the benefit that many/most redeliveries could be handled through Marketplace.

We have no way to know how long sounds are in our inventory in the sound properties or in LSL. We need the ability to see how long sound files are. Having this function would be great for making sure we can queue the next sound properly. this would be ideal for song loopers when we have a lot of sound files we're handling that have differing lengths. llSetSoundQueueing is limited and does not offer anything more than 1 level deep and will discard the last sound your trying to queue, so that isn't useful.

Add the the texture coordinate system to the projector and allow it to be animated just like llSetLinkTextureAnim() so we can project sprite images.