Scripting Features

The problematic bots are those that are not marked as bots so that they may enter locations where bots are banned. The solution is for LL to actively monitor for avatars that are teleporting all over SL while sending data from a LSL script to an offworld or inworld server. I'm talking about data that can't be collected by the viewer/bot-software directly. The pattern should be quite distinct - teleport, data collected, data transmitted, repeat. Or even several teleports and then transmit the data if it's cached for a while in the script. Ditto for detecting the LSL commands being run after each teleport. The regions are in the best position to detect and collate this bot-like behaviour from avatars that are not flagged as bots. With the unmistakable bot behaviour being the frequent teleporting, collection and transmission of specific information. Once the offworld/inworld server is identified all avatars sending information to this server should be suspended from being able to login immediately to prevent new bots being created to replace suspended bots. This will ensure new bot accounts are instantly blocked the moment they start reporting data to their database. The goal is for all bots to be flagged as bots in their profile so that people can block them by using the region setting to deny bots entry to the region. Of course we will need similar functionality to block bots from mainland parcels too. What we should not be doing is adding limitations to existing LSL commands, or the ability for new accounts to explore SL as some people have suggested. Bot behaviour is quite distinct and detectable by the regions and this is where we should be enforcing the bot policy on the bots directly.

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

Since texture transforms aren't part of the PBR asset, we can't just use the "" hack in llSetLinkPrimitiveParamsFast(...) to preserve their values. Instead we need to record the transforms (offset/repeats/rotation) for each face and reapply them with the new alpha value. A function like llSetLinkPBRAlpha() would be very much appreciated. Coming to think if it, most use cases (except for fading) could actually be addressed by having something like llLinkVisible(LINK_THIS, ALL_SIDES, TRUE) - llLinkVisible(LINK_THIS, ALL_SIDES, FALSE) - taking the usual LINK_* constants and face numbers.

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 if we need to set a timeout for script logic, a timer event needs to be created to check the status of the script logic. If multiple logical timeouts are needed concurrently, a more constant, fast(er), timer needs to be created to loop through each logic condition and determine if a timeout for each has occurred. I propose a new Function/Event pair. A function to setup a timeout condition, and an event that would be raised when this condition is met. Scripting wise, it'd be a matter of simply calling the function to turn on a timeout check and responding to the Event if it's raised. The calling function will be used to turn off the timeout check if the script logic dictates. See examples below. Function: llExpire(string Event_tag, integer duration_in_seconds) -- if Duration is 0 or a negative number, remove that event tag. to turn on an expire event: > llExpire("listener_01", 30); to turn off a defined expire event: > llExpire("listener_01", 0); provided that an expire tag has not raised the Expired Event, it can be reset with a new value (this would turn off/remove the event tag and apply it again in one step) > llExpire("listener_01", 15); Setting multiple timout event would a simple as: > llExpire("listener_01", 30); > llExpire("change_color", 15); > llExpire("rotate_object", 60); Event handling would be as follows. Event: Expired(string tag) Example in use would be > Expired(string Tag) > { > if (Tag == "listner_01") > { // do the things desired on timeout; } > } if two timeout events expire at the same time, two Expired event would be queued up, one after the other, to simply logic. Additional notes: Any timeouts defined by the llExpire would only raise one event then be discarded. Alternatively, it maybe that llExpire events could be made to repeat on the defined interval and it'd up to the script to turn off a given expire tag in the Expired Event if needed. This would prevent the timeout from being lost if the even queue got over filled.

Would like a new function that can change parcel's landing point via script. Can be useful for avoiding people landing on top of each other, as well useful for RP places to put them in different interesting spots each time someone teleport in. Obviously, the object would need to be deeded to a group, matching parcel's group, for it to work.

Today, Monty Linden mentioned that future Experience KVP database work is required and if there were any feature requests, they should be filed soon. So with that said, here are some much needed functions: llInsertKeyValue(string key_name, string key_value, integer index); inserts key_name and value at index number (this is a create) llMoveKeyValue(string key_name, integer index) moves key_name to index number (alternative to delete, then insert) llFindKeyValue(string key_name) returns the index number key_name is at The Experience KVP database is indexed. Having the above functions will allow sorting/grouping/partitioning/defragging/cleanup capabilities. This will significantly cut down on mass lookup/find protocols, wasting literally millions of requests per user a year and in some cases, per week. Regex for Experience KVP would be far better though...

Hard coding link numbers into scripts is usually bad practice. So it's often best to search for something more concrete like the name of a linked prim and assign it to an integer using a loop by using llGetLinkName and comparing it to the link name you want to find. This isn't very friendly to new scripters who want to work with linked prims. A function that checks all of the prims in a linkset and finds the first instance of a specified link name would make scripts like this much easier. If I wanted to find the first instance of 'door left' in a linkset this could look like; llFindLinkNumber("door left");

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.

Parcel privacy settings prevents avatars on other nearby parcels from rendering or hearing avatars that are on a parcel with "Avatars on other parcels can see and chat with avatars on this parcel" toggled off. LLGetObjectDetails should also respect parcel privacy setting so objects outside of the parcel are not allowed to get a list of attachments from avatars standing on a parcel with this privacy setting enabled. This would essentially allow land owners to opt out of roaming bots gathering attachment data since there isn't a setting to disallow bots at the parcel level, especially for those who live on mainland.