Scripting Features

As a high-performant and modern alternative to the llHTTPRequest and llRequestURL , (web)sockets would be a great addition. It will allow objects and HUD elements to have direct bi-directional communication with back-end server software. The same can be achieved with the existing HTTP methods, but it requires a lot of effort to implement. The (web)sockets would have to be proxied through the Linden Labs servers just like the HTTP requests to avoid the leaking of IP addresses. If websockets are to be used, the benefit of HTTPS certificates exist for a secure connection. I am not requesting (web)sockets in the script to act as a server like llRequestURL , but for the script to always be the client to an external server (though feel free to implement that as well!). The functions could look like: key llSocketOpen( string url /*, Other options... */ ); llSocketSend( key id, string data ); // llSocketSend does not need a 'key' to return; packets identify themselves llSocketClose( key id ); The events could look like: socket_receive( key id, string body ) {} socket_close( key id, integer code ) {} // Code would follow the standard, but code '0' could be "closed by own script". There could be events for when the socket is opened or errors, too. In that case the llSocketOpen function can be non-blocking. Example code: key handler; default { state_entry() { handler = llSocketOpen( "wss://example.com:8081" ); llSocketSend( handler, "Hello world!" ); } socket_receive( key id, string body ) { if( id == handler ) { llSocketClose( id ); } } socket_close( key id, int code ) { if( id == handler ) { if( code == 0 ) { llSay( 0, "The socket was closed by us!" ); } elseif( code > 0 && code <= 99 ) { llSay( 0, "The socket was closed by the Linden proxy with code: "+ (string)code ); } else { llSay( 0, "the socket was closed by the remote server with code: "+ (string)code ); } } } }

[Feature Request] - llGetScriptType(), a function to get which compile type an inventory script uses. integer llGetScriptType(string inventory_name); returns -1 for non-scripts, 0 for LSO, 1 for Mono, 2 for LSL on Lua, 3 for Lua Different icons currently show in object inventory for different scripts.

I need to get these values to initialize the camera on furniture after a user has changed/saved their view via llSetCameraParams() and wants to reset/remove this change. I'd like a native approach instead of having to save this data to linkset data when I drop in a temp setup script during the creation process. These prim properties are set via llSetCameraEyeOffset()/llSetCameraAtOffset() or llSetLinkCamera(). Thanks.

Add INVENTORY_SOFTOBJECT to llGetInventoryType, or any other name to denote a soft-linked (aka, coalesced) object. Because there is currently no way to distinguish those from a singlle object. And this is vital for rezzers and such.

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

Currently, the only way to play sounds for only the avatar wearing an object is to use llPlaySound in an object attached to the users HUD. Sometimes, a creator might want to play a sound only audible to the avatar wearing a particular non-HUD object. The only way to achieve this currently is by force attaching a separate HUD-object using RLV. Without RLV it is impossible. A function along the lines of llPlaySoundForWearer and/or llPlaySoundForOwner would be a great addition.

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

Per https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/ This is putting the respawns part of what Rider had drafted up as a proposal into a feedback. The Teams portion of the draft is available at: https://feedback.secondlife.com/scripting-features/p/combat-21-teams Respawns builds upon Teams. Adding additional mechanisms to support reliable server-side respawns. That means that Teams can be built as a feature first and Respawns can be considered and built in after. Respawns have a current viable workaround with Experience but Teams are a more fundamental issue that all of SL can benefit from beyond SLMC but also Games and RP sims. --- Currently respawns can only be done through Experiences. Setting the DEATH_ACTION to disable server-side checks and teleportation. Instead upon avatar death, an experience manages via scripts the teleportation to a respawn. But as shown in the Teams proposal, there are many difficulties around identification, checks and logistics. For reference the current implementations either work via Combat Log, observing DEATH events to then teleport an individual to respawn. Or via temp attachment HUDs that rely on on_death to then trigger a teleport to respawn. --- So I would like to see Rider's implementation of Respawns. Which builds upon Teams to enhance it further. See the thread for more details: https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/

This would be very useful in menus for homes,skybox,etc. Lock it so it cant accidently be changed. Yes i know you can do this manually. But would be nice.

I'm currently developing an Experience that is to be packaged as a product that people can install in their land. One of the difficulties I can see is that in order to allow an experience a user must do a series of steps:- Open About Land Go to allowed Experiences Click add experience Type in the name of the experience The last step is especially prone to user and merchant error. Typo's causing the user not to find the Experience, adding the wrong Experience. Or the Merchant might have since renamed the Experience and the user no longer knows what to search for. To solve these pain points I propose adding the LSL function llRequestAllowExperience. It will ask the user with a dialog if they'd like to allow the experience the script is compiled to in their land, and offer the user to allow it for either 'Parcel' or 'Estate' depending on the permissions over the land the user has.