Scripting Features

New script development settings have been added to the Advanved tab in the preferences. please make these settings accessible from the script window along side the other menu items.

As of right now, if you want to test that someone is member of a group, you need this person to be actually wearing the group. Which is fine when dealing with vendors or fidelity. However there are scenario where you want to be able to test if a person is a member of a group without them actually wearing it. For example, accessing something or security or special functionality. In the same fashion as llSameGroup(uid) works, we should have a llHasGroup(uid) which would let you test if someone has the group even if not explicitly "wearing it".

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.

A use case that I have in mind: building an array of values in one script that another script needs to process. An encoding step is necessary since linkset message/linkset data/say strings can't contain nulls (I sure wish they COULD but that's probably too much to ask). Building it into a binary buffer or string is not flexible (need to know exact structure and length ahead of time) and doesn't support all basic data types directly. Building a string awkward and inefficient. Table.concat can't handle all types either, and a big CSV string is very much not compact and can't be string.split to original data types at the receiving end. lljson+llbase64 can of course handle a typed array already, but that's even less compact. So my idea is: an encoder and decoder in llbase64 that take/produce an array-like, contiguous and flat table that supports all basic data types. llbase64.encodearray(t:{}, start:number?, end:number?): string handle each table "t" element from "start" (defaults to 1) to "end" (defaults to #t) similar to string.pack producing the most condensed binary representation tagged with a type byte (e.g. "0" for nil, "t" for boolean true, "f" for boolean false, "n<8 bytes>" for a number, "s<length><data>" for strings, "v<8 bytes>" for vectors, etc... I don't remember how lljson did the type tagging, but maybe use the same tags), then base64 it. Errors on failure (table is not flat, contains userdata/threads/whatever else). llbase64.decodearray(s:string, base_index:number?, limit:number?): {} decode base64 string "s" to a binary string and produce an array-like table starting at index "base_index" (defaults to 1), parsing at most "limit" (defaults to no limit) entries. Errors on failure. Edit: since this was moved to Scripting Features from the Lua section, I'll just point out this is definitely a Lua request foremost: LSL is extremely limited with dealing with any kinda binary data and lacks the llbase64 library, even though the same logic could be applied to lists instead of array-like tables.

We currently don't have a way for scripts to know if bots are allowed or not in a region. Please add "deny_bots" to llGetEnv(). This should point to the same value set by the parameter of the same name in the region console. Thanks.

I am working on a suite of object management scripts, and would find it useful to able to discriminate between locked objects and objects left unlocked. This would allow me to discriminate between stray objects and perma-builds in my roleplay sim when looking for stray objects that need cleaning up.

There are many animations out there which were uploaded with a low / default priority. These are fine provided other overlayed animations running at the same time don't override their actions. It would be useful to be able to change that priority when starting the animation. eg: llStartAnimationPriority("animation", 6);

The VSCode plugin to work with scripts in SL from an IDE over a local connection to the viewer is nearly ready, so I'd like to add this request when it comes along: Any chance we'll be able to commit scripts into objects...within objects? Use case: Item gives a temp-attach HUD, which has scripts. Game rezzes pieces, which have scripts. Tons of use cases. Challenge: Finding out what's inside an object. The simulator doesn't know until it fetches the sub-object. I see a path forward here: When we use the local address to connect to an object, and that object has contents, the simulator fetches those sub-objects and their content. Sub-Objects are represenred as sub-folders in VSCode, with contents inside. When contents are synced back up to SL, it's all existing functionalities. The simulator unpacks sub-object(s) to get to the intended resource and replaces the script, then re-takes the objects. So a kind of automated "unpack to find out the content" and then existing capabilitiesthat power script pin and derez to re-pack. Most of this exists. Rezzing to get the object info from the asset server, replacing scripts in objects (via script pin in LSL, so the simulator knows how to do this), and recently, the derez ability to take things back into an object. The current gap: Rezzing is a bit of a problem. This automated "unpack the sub-objects" setup could cause unintended side-effects from rezzing things in ways they weren't intended to rez. Proposed fix: The simulator "rezzes" the content objects, but in a way that is out of the user's control. Li-less, permission-agnostic, invisible, non-physical, owned by simulator process, with scripts non-running. To the user, nothing happens. The simulator fetches the info it needs, sends this to the localhost , and discards the objects. On check-in, a similar process will invisibly get to the right sub-object and replace the script without allowing it to run (but without toggling its run state), and taking the object back. This all runs as an elevated simulator process that simply ignores no-copy, etc. The permissions to do all this editing are checked up-front; the simulator doesn't mess with anything. This has some performance implications, so let's imagine that recursion shouldn't go more than 2 levels or X sub-objects, whichever is met first, where X is whatever LL finds reasonable. Bonus!! If this can work in VSCode (via this shadow-simulator-agent rezzing thing), then I could see a future Viewer UI piece as well. Trivially, drag a script onto an object inside the contents area, get a menu asking whether you want to copy to Contents, or within object XYZ. If you choose object XYZ? Same routine; invisibly rez, add/replace the script, take back.

key llGetRegionWorldMapTile(string region_name) A LSL function to return the UUID of the current world map tile for a named region, so that it might be placed on a face using PRIM_TEXTURE. This could also be added to llRequestSimulatorData Currently the only ways I know to accomplish this depend on MOAP and voodoo to get an image from slurl.com , or pulling the CDN UUID from gridsurvey.com via a HTTPRequest. Which all seems pretty hacky and unfun.

In scripting, currently we only have support for the following methods in SL: GET, POST, PUT, DELETE There is a new HTTP method QUERY: https://www.rfc-editor.org/info/rfc10008/ There are many benefits laid out in the proposal document that I feel would be beneficial for Second Life scripts. I am proposing adding this new method.