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.

New LSL function that allows scripts to toggle an object’s Animesh property state at runtime. llAnimeshEnabled(integer enabled); ## Overview Currently, enabling Animesh on an object significantly increases its land impact, even when the object is idle. In contrast, a comparable non-Animesh object—especially one with well-optimized geometry and materials—can often remain at a land impact of 1. At the same time, Animesh animation itself is already fully script-driven. Functions like: llStartObjectAnimation(string anim) llStopObjectAnimation(string anim) llGetObjectAnimationNames() allow scripts to control animation playback dynamically. However, these functions only operate after an object is already in an Animesh-enabled state. This creates a structural limitation: creators can control what an object does, but not whether it needs to be Animesh at all at a given moment. ## How Animesh Currently Works Animesh objects function by associating a skeleton with a rigged mesh linkset. When a script plays an animation, the skeleton drives deformation of the mesh. Importantly: An object does nothing by default when set to Animesh Animations must be explicitly triggered via script The visual position of the mesh is driven by the skeleton and active animations, not strictly the object’s base transform This means Animesh is fundamentally an on-demand animation system , but it is currently forced to be always enabled at the object level , regardless of whether animations are playing. ## Problem There is currently no way to: Disable Animesh when no animations are running Return an object to a low land impact idle state Dynamically enable Animesh only when animation is required As a result, creators must choose between: Keeping Animesh permanently enabled (high land impact, unnecessary overhead) Building complex systems involving object swapping, rez/re-rez logic, or duplicate assets ## Use Case There is a strong need for objects that can dynamically transition between static and animated states. For example: A robot or pet that remains dormant until activated Creatures that only animate when a user is nearby Props that “wake up” briefly to perform an action Environmental elements that animate only during interaction In all of these cases, the object does not need continuous skeletal evaluation. ## Expected Behavior enabled = TRUE - Enables Animesh on the object - Allows use of llStartObjectAnimation and related functions enabled = FALSE - Disables Animesh - Stops all active animations - Returns the object to static mesh behavior - Restores lower land impact where applicable ## Benefits Land Impact Optimization Objects only incur Animesh cost when actively animating Performance Efficiency Reduces unnecessary skeletal evaluation on idle objects Cleaner Content Architecture Eliminates the need for duplicate objects or rez-based workarounds Better Alignment with Existing API Design Complements existing animation control functions by adding missing state control ## Additional Considerations State transitions should preserve: - Object transform - Linkset integrity - Script execution state Simulator safeguards may be needed: - Throttling or cooldown on toggling - Permissions checks to prevent abuse Documentation should clarify: - Effects on physics and collision - Bounding box changes - Interaction with pathfinding and attachments

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.