Scripting Features

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

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

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

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.

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.

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. */ }

A use case that I have in mind: building an array of values in one script that another script needs to process. An encoding step is necessary since linkset message/linkset data/say strings can't contain nulls (I sure wish they COULD but that's probably too much to ask). Building it into a binary buffer or string is not flexible (need to know exact structure and length ahead of time) and doesn't support all basic data types directly. Building a string awkward and inefficient. Table.concat can't handle all types either, and a big CSV string is very much not compact and can't be string.split to original data types at the receiving end. lljson+llbase64 can of course handle a typed array already, but that's even less compact. So my idea is: an encoder and decoder in llbase64 that take/produce an array-like, contiguous and flat table that supports all basic data types. llbase64.encodearray(t:{}, start:number?, end:number?): string handle each table "t" element from "start" (defaults to 1) to "end" (defaults to #t) similar to string.pack producing the most condensed binary representation tagged with a type byte (e.g. "0" for nil, "t" for boolean true, "f" for boolean false, "n<8 bytes>" for a number, "s<length><data>" for strings, "v<8 bytes>" for vectors, etc... I don't remember how lljson did the type tagging, but maybe use the same tags), then base64 it. Errors on failure (table is not flat, contains userdata/threads/whatever else). llbase64.decodearray(s:string, base_index:number?, limit:number?): {} decode base64 string "s" to a binary string and produce an array-like table starting at index "base_index" (defaults to 1), parsing at most "limit" (defaults to no limit) entries. Errors on failure. Edit: since this was moved to Scripting Features from the Lua section, I'll just point out this is definitely a Lua request foremost: LSL is extremely limited with dealing with any kinda binary data and lacks the llbase64 library, even though the same logic could be applied to lists instead of array-like tables.

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.

llSaveBack2Rezzer() When an object was rezzed by another object then modified. a lsl function to replace the original inside rezzer by a copy of the rezzed one. This exists in the Build menu of Firestorm

Rationale We have sit targets to define where an avatar should sit on a linked object. But when standing up, it's always at that exact same position. This is awkward for things like vehicles where the user will unsit inside the vehicle instead of stepping out gracefully. This goes together with a possible unsit event as proposed here: https://feedback.secondlife.com/scripting-features/p/unsit-events Proposal Add a possibility to let us define the exact spot and rotation where the avatar will be positioned/moved to at the moment of unsitting.