Scripting Features

Add a new function, llSetSitFlags which can be used to control behavior of the agent seated at llSitTarget. This would be useful for vehicles and other applications where making the avatar invisible or removing its physics shape from the physics simulation would be useful. Flags SIT_FLAG_INVISIBLE SIT_FLAG_NO_COLLISION *Note: the SIT_FLAG_INVISIBLE flag should not hide the avatar's nametag.*

Add a function to retrieve the description of items in object inventory. Something along the lines of: string desc = llGetInventoryDesc(string inventoryName);

There is no way for a script to determine the friendship relationship between an owner and another agent. This would be useful for security orbs and other features. Function: integer llIsFriend(key agent_id) Tests if the agent identified by agent_id is on the friends list of the owner of the script. Returns TRUE if the agent is a friend, otherwise FALSE . If agent_id does not identify another avatar this function returns false. One of the two agents must be on the region.

This feature request is for the following function: llDeleteMyRezzedObject(key object_id) This function, when called by a rezzer object, allows for remote culling of object_id if it was rezzed by the host that contains the script. If object_id is attached, nothing happens. One very common use case would be "scene rezzers", which currently require the creator to prior set up each rezzed component with a script to facilitate communications to either execute llDie() or to remove the script itself. This is one of many potential, rezzer authority based functions that can benefit both combat and non-combat environments. I will post those at a later date.

On April 18, last year in the Server user group meeting, a developer mentioned interest in implementing BUG-4906. Since that time, a synchronous notecard line reading function was implemented. Still, interest in implementing notecard text find/count functions continued. Since we now have a synchronous notecard line reading function, I feel it is necessary to update the spec of how find/count functions should work. list llNotecardTextFind(string name, string pattern, integer start, integer count, list options) The above function works similar to llLinksetDataFindKeys() in that it uses regex and synchronous return. Instead of keynames, notecard line numbers/columns where line data matched pattern are returned instead. If name is not in inventory nor a UUID, start is outside of notecard line count or no matches found, this function returns an empty list. If notecard data is not cached, a list containing NAK is returned. With a list of notecard lines where matches were found, llGetNotecardLineSync() can used to read line data synchronously as well. string name - Name of notecard in inventory or UUID string pattern - A regular expression describing which notecard line numbers/columns to return. integer start - The first occurrence of pattern to return. integer count - The number of occurrences of pattern to return from start. list options - Provision for optional inputs and a modular means of updating the functionality of this function in the future. One Linden mentioned wanting the means of including occurrence counts with line numbers. Another Linden mentioned the desire for case sensitive searches. Another method could be a way to look for blank only. The options param would allow for this work to be added in a follow-up. integer llNotecardTextCount(string name, string pattern, list options) The above function works similar to llLinksetDataCountFound() in that it uses regex and synchronous return. A count of the number of matches made is returned. If more than one match is found on a line, the match count is used, not 1, so the overall count can potentially be greater than number of notecard lines. string name - Name of notecard in inventory or UUID string pattern - A regular expression describing which notecard line numbers to return. list options - Provision for optional inputs and a modular means of updating the functionality of this function in the future. This is the safe means of checking for presence of search terms in notecards without worry of stack-heaping the script. If a count is returned that could stack-heap a script, a looped alternative can then be made using llNotecardTextFind() with an incremented start param and lower count param.

Add a new llGetNotecardLineFast function with the same signature as llGetNotecardLine . This new *Fast version will not have a delay if the notecard being requested is already in the region asset cache. Rationale llGetNotecardLine is infamously slow, with a built-in delay of 0.1s per line. This adversely impacts all sorts of scripts in Second Life, notably when scripts need to load user-customizable configuration (Furniture, etc.) By introducing a new *Fast permutation of the function (Similar in style to llSetLinkPrimitiveParamsFast , etc.) we can allow any behavior that depends on the built-in delay to function as expected while giving creators the ability to opt-in to a faster method. The new function would feature a delay (0.1s or similar) if the notecard being requested needs to be downloaded into the current region's asset cache. This is necessary as notecards can be referenced by asset ID, and presents a more transparent and fair representation of lookup cost.

float llGetAspectRatio(); This would return the aspect ratio of the wearing agent's screen. For privacy purposes(i.e. preventing "fingerprinting"), this should only work on the agent wearing the object, and if the object is attached to the hud. The data would be pulled from the existing AgentHeightWidth packet, and would be the result of AgentHeightWidth.HeightWidthBlock.Width / AgentHeightWidth.HeightWidthBlock.Height. This is currently possible, but in a tedious way. A resident must attach a object to one of the corners of the HUD with the following script: default { touch_start(integer total_number) { vector scale = llGetScale(); vector off_point = llGetLocalPos(); vector face_pos = llDetectedTouchST(0); vector screen_pos = llDetectedTouchPos(0); float screen_width = ((face_pos.x-.5)*scale.y-off_point.y+screen_pos.y)*2; llOwnerSay((string)screen_width); } } Example output: Assuming the following block has been sent to the server: AgentHeightWidth AgentData AgentID 796b1537-70d8-497d-934e-0abcc2a60050 SessionID 00000000-0000-0000-0000-000000000000 HeightWidthBlock GenCounter 0 Height 1061 Width 1920 And object's root is attached to ATTACH_HUD_* Then the following should be true: llGetAspectRatio() == 1.8096135721017907 //(1920 / 1061) If not attached to HUD, or the simulator has no AgentWidthHeight cached, then return 0 or FALSE. This will be safe as no screen will can have a ratio of zero.

Increase the objects returned by sensors to 32.

In vehicle racing communities it becomes necessary to prevent people 'boosting' themselves to cheat. In some places this is by insisting a classic avatar with zero scripts, or unwieldy speed monitoring systems to highlight boosted behaviour. The cheaters use a HUD or other attachment to 'push' the vehicle they are sat on (and they can push it, because they own it). If a script inside the vehicle could be able to detect these pushes, it could react from within against the cheating. Or if there was a way to set a vehicles status that it does not react to pushes, even by its owner? extra note : this is not about 'grabbing' your vehicle to give it a push - that can already be prevented with llSetStatus tools.

It would be terrific to have a function or family of functions to convert between popular binary-as-text representations. This could be used, for example, to take the base64 output of llHMAC and convert it to the more commonly used base16 (hex) encoding. Option 1: llBase64ToBase16(string src) llBase16ToBase64(string src) Option 2 (Suggestion from Bleuhazenfurfle): string llBaseToBase(string src, string from, string into) Rationale Working with base64 and base16 encoded data is relatively common, (JWTs, digests, et al.) and converting between one and the other is also a frequent demand. This is currently rather arduous and expensive with LSL. As an example of a practical application: the llHMAC function returns base64 but most applications using HMAC expect hex.