Scripting Features

LSL badly needs functions along the lines of string llHTMLEncode(string txt) string llHTMLDecode(string txt) which handles HTML enties such as & -> & > -> &gtr; etc to handle all 8 bit characters. It seems the functions exists as part of the JSON implementation. This is a really serious lack if you're trying to serve web pages in SL.

The llTextbox function is frequently used to enter parameters as values or text. It could be useful to prefill the text field with the previous parameter especially if it's a long text. Example, this previous sentence was entered: "The quick brown fox jumps over the lazy cat." and need to be fixed. Currently, for edit it, I need to put the sentence as message in llTextbox. Then, copy it from the box label and paste it in the field. With the llFilledTextbox, the field would be prefilled with the sentence. Also, a text size extended to 512 characters would be welcome. To finish, the field needs to take the focus when the box is showed.

I've spent about the last week updating some scripts to handle both PBR and Blinn-Phong updates simultaneously. The scripts work fine, but the current way you have to update PBR values - through llSetPrimitiveParams and the full list of values - is not ideal. In order to avoid overwriting your existing values with blank or incorrect data, you have to have a way to know and store your existing values, modify those values, and send the whole list back in. Adding in some llFunctions for PBR values, so you don't have to modify the entire parameter array to change one value, would make scripting PBR modifications much more pleasant to work with. If llFunctions are not feasible, a way to update individual values in the parameter arrays without data loss (e.g. being able to pass a blank string as a texture and have it skip the value instead of applying it) would be appreciated. I've compiled a list below of how I would personally pop each value out into a Set function (they would have matching Get functions, a la llGetColor and llSetColor): --- For PRIM_GLTF_BASE_COLOR: llSetGLTFBaseTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFBaseColor(vector color, integer face); llSetGLTFBaseAlphaMode(integer gltf_alpha_mode, integer face); llSetGLTFBaseAlpha(float alpha, integer face); llSetGLTFBaseAlphaMask(float alpha_mask_cutoff, integer face); llSetGLTFBaseDoubleSided(integer double_sided, integer face); --- For PRIM_GLTF_NORMAL (this really only has one function): llSetGLTFNormal(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); --- For PRIM_GLTF_METALLIC_ROUGHNESS: llSetGLTFMetalRoughTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFMetallicFactor(float metallic_factor, integer face); llSetGLTFRoughnessFactor(float roughness_factor, integer face); --- For PRIM_GLTF_EMISSIVE: llSetGLTFEmissiveTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFEmissiveTint(float emissive_tint, integer face);

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.

Creates a new list or updates an existing list with the specified index of the provided list removed. There is currently no clean, easy way to remove an item from a list. This would provide a simple way to clear specific items from a list and reduce the currently needed loops and overhead to do this. Example Useage: list mylist = ["bob", "tom", "jack", "bill"]; mylist = llListRemove(mylist, llListFindList(mylist, ["jack"])); Result: mylist = ["bob", "tom", "bill"];

hi, has anyone ever asked for a function called llGetGroupKey(key id);? A function like this would make it easier for many stores to rez group gift giver in any group instead of the landholding group. llSameGroup & llDetectedGroup are not an option if it is group owned land and the store uses a different group. LG Dae

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

Pretty simple request: llClamp(integer val, integer min, integer max)

Add the ability to receive input from game controllers such as joysticks, Xbox controllers, etc. This will allow the creation ofhHelicopters and planes that use analog input from console controllers, attachments that control drones, arcade games, cranes, machinima puppetry, etc. This new feature will be implemented by adding a LSL event game_control(...) which script authors can use to capture and respond to input from users. For further details, see https://wiki.secondlife.com/wiki/Game_control

Right now, getting the NAME of an agent's group involves a http request to an offworld server: mygroup = llList2Key(llGetObjectDetails(llGetKey(), [OBJECT_GROUP]), 0); if (mygroup) { grouprequestkey = llHTTPRequest("http://world.secondlife.com/group/"+(string)mygroup,[],""); } This is cumbersome and places unnecessary load on the http requests to and from a simulator, and also needs parsing and sanitizing the HTML response. I would like to suggest a LSL command for this. Ideally, it would be a feature of llGetObjectDetails , thus avoiding the dataserver: mygroup = llList2String(llGetObjectDetails(llGetKey(), [OBJECT_GROUP_NAME]), 0); However, if the dataserver is needed, so be it: grouprequestkey = llRequestGroupName(llGetKey()); ... raising the dataserver once the name is in.