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

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.

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.

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.

[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.

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

With the creation of llRezObjectWithParams, which offers far more flexibility and scalability than the llRezObject/llRezAtRoot functions, I felt that it would be an excellent idea to re-visit a couple of old classic's as well: llSensor and llSensorRepeat These two have been a staple in this program for many years, however with the advent of llCastRay, as well as the Combat 2.0 suite of functions coming soon, it would be fair to at least revisit these two functions and give it a proper facelift and some TLC. In a similar spirit as llRezObjectWithParams, I would like to propose the creation of llSensorWithParams. The principle is the same as its predecessor, which will do a scan and it will return a list based on the filtered results. llSensorWithParams(list params ); *An empty list should only trigger a no_sensor event Parameters should include, but not limited to, the following: SENSOR_NAME - Object or avatar name SENSOR_KEY - group, avatar or object UUID SENSOR_TYPE - mask (AGENT_BY_LEGACY_NAME, AGENT_BY_USERNAME, ACTIVE, PASSIVE, and/or SCRIPTED) SENSOR_RADIUS - distance in meters from center, [0.0, 96.0] SENSOR_ARC – the max angle between the object's local X-axis and detectable objects, [0.0, PI] SENSOR_RATE - how often a scan is performed SENSOR_RC - Performs similar to llCastRay, however start/end vectors could be offset of both endpoints. A TRUE/FALSE flag should be made for the offset based on Global Position or with Rotation factored in. The start vector is the prim calling the Sensor event, while the end is the llDetectedPos. All other RC flags should still apply from llCast Ray SENSOR_HEALTH - Prims/Objects with OBJECT_HEALTH set. (See https://feedback.secondlife.com/combat-20/p/new-llsensor-flag-mask-object-health ) A practical application of this new function is for combat/fantasy role play sims. For example, if a player wants to do a melee attack, throw something explosive like a rocket or fireball, you could call the function as follows for a wall-safe detonation what will filter out those that are in range, but are behind cover: llSensorWithParams([ SENSOR_TYPE ,AGENT, SENSOR_RADIUS, 10, SENSOR_ARC, PI, SENSOR_RC, ZERO_VECTOR, TRUE(global), //start vector ZERO_VECTOR, TRUE(global), //end vector OTHER_FLAGS ]); These are some of the applications that can be involved with this new function. More folks might want to chip in to expand the functionality of it.

When using Combat 1.0 weapons, the on_damage() event caps at the 32 limit, but further damage is still processed. This makes it impossible to prevent death using llAdjustDamage and on mainland, that means they get sent home. My fastest attempt at preventing this only works 50% of the time. We've asked to remove the Teleport Home on Death option for our sim, but were denied. We'd like to control combat deaths ourselves through Experiences, but cannot with mainland rules. Acceptable solutions: * Increase the event queue to 64 for on_damage() // Maybe sufficient * Stop processing damage after it hits the event limit // Absolutely sufficient Either of these would allow us to use the new Combat 2.0 system in role-play situations without needing any mainland estate setting changes.

llGetParcelPrimOwners() currently only returns upt o 100 results, with them being sorted alphabetically by agent uuid. this makes it impossible for scripts to reliably obtain a complete list of object owners when a parcel has more than 100 agents with rezzed objects, which can be common in places like sandboxes or shared rental parcels Being able to specify options like the result count, sorting order, etc would make the function much more useful. script memory usage from large lists is also less of an issue given the fact that lua/the lsl-lua compiler will provide 128kb instead of lsl's 64kb, and the result count option would allow scripts to control memory usage This would be a new function instead of adding onto llGetParcelPrimOwners , so it doesn't break existing scripts: llGetParcelObjectUsage(vector pos, list options) vector pos - position in region coords list options - list of configurable options options: LIST_COUNT - amount of result pairs to return SORT_BY - sorting order of the return list SORT_BY_UUID_ASC/DESC - alphabetically by uuid SORT_BY_USAGE_ASC/DESC - by usage amount llGetParcelObjectUsage(llGetPos(), [LIST_COUNT, 50, SORT_BY, SORT_BY_USAGE_DESC]) The list formatting, permission requirements, etc. could be similar or identical to llGetParcelPrimOwners()

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.