Scripting Features

Implementation: https://gist.github.com/FelixWolf/d6b78b39a06419693a93046046913e15 LSL has the issue where some lists need to be typed, cough llSetLinkPrimitiveParams cough . It's important to be able to store types when storing a string, say to either a remote server, or llLinkSetData , or even just transmitting it from one object to another. The design philosophy behind this idea is three points: Be compact Be easy to implement (for residents who need to make code to do this) Solve the issue The functions are: * string llList2TypedString(list data); * list llTypedString2List(string data); The syntax is as follows: * i precedes a integer, if no integer is found, it represents 0. (Hexidecimal is supported because of std::stoi ) * r ("r" as in Real!) precedes a float, if no float is found, it represents 0. Preceding zero are optional for values between 0 and 1. * v precedes a vector, if no vector is found, it represents zero. If any value is zero, it may be omitted. I.E. v,1 is valid for <0,1,0> , as well as v,,1 being for <0,0,1> . * q precedes a quaternion, it shares the same behavior as a vector (Quite literally the same code!) * k precedes a key. It reads exactly 36 BYTES, unless the first byte is "-" * s precedes a string. It is defined by specifying a integer length, followed by a colon, then the string. If no string or simply a semicolon, it represents a empty string. * Lists are unsupported, lists may not contain lists. * Any of the above may be combined in series to form a list. I've provided a lscript implementation at the top of this post.

Please consider adding an endpoint to the map API for fetching data useful for navigating the grid. This data would be readily available map information. At the present, this is a very, very strange task to accomplish. We can pound LL's servers using this API: https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=region&grid_x=1000&grid_y=1000 And scanning every possible range of coordinates we think is useful. Or We can use a bot on a custom viewer, making MapBlockRequests until we've got the whole grid. Each of these really need an external service running, and hit your servers pretty hard--but it's all for information that you already have that would be valuable to us to use for scripted applications (eg for navigation HUDs, custom maps, games with distributed locations, exploration apps, touring pods) and also, just in general to know how our world is doing. Proposal: Two https endpoints to fetch paginated region info lists. First API endpont: region list by number. The order is determined by LL and is arbitrary, but is used for pagination. A script can ask for the first N regions, then another set of regions starting from N and so on. In this way, scripts can parse the region list without hitting the api server, sim, or script memory too hard Second API endpoint: region list by name. Similar to searching a word on the map and getting one or several regions that match the name. Responses are delivered as JSON, with each region'd details in an object of the following form: { { "name" : "Da Boom", "coordinate" : "<1000.0, 1000.0, 0.0>", "estate_name" : "mainland", "region_map_image" : "7963f194-82f9-23b3-3d89-c21f1bd0a8bc", "access_name":"Moderate" } } Example of using the first endpoint, the enumerated API: The endpoint can be called with a page number, and an optional maximum. For example, suppose we are permitted up to 25 list items in a single call: Example: Fetch default 25 items starting with the 437th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=437 Example: Fetch only 5 items starting with the 75th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=75&length=5 In this way, external services we write and LSL code in-world could reasonably work with the large list of region data in a way that doesn't flood the API (feel free to rate limit) and that permits us to work within script memory limits. Example of using the second endpoint, the named API: The endpoint is called with a search term, and returns one or more regions that have a name starting with the term. There should be a minimum character limit. Ecample: Fetch regions starting with the name "Da B" https://cap.secondlife/com/cap/NAME_ENDPOINT?search=Da%20B Summary: There are many standing requests for access to the map tile information, map region names, and map grid coordinates, all in separate feature requests. I propose this API mechanism to capture data you already have in a way that solves every request.

Reading over the wiki, I found that the only way to set the scale, offset, or rotate a texture in a linkset is to use PRIM_TEXTURE, which requires that you supply it with a texture otherwise, it will remove the texture from the face you're trying to modify. llScaleTexture(), llOffsetTexture(), and llRotateTexture() do not have an llSetLink or llGetLink equivalent or flag for setting those values directly for the other links in the linkset. It would be really nice to be able to set those values directly via llSetLinkPrimitiveParamsFast() rather than having to worry about supplying a texture or getting and setting or removing a texture. This should also be extended to work with GLTF materials.

We noticed that the SIT_FLAG_INVISIBLE flag was not implemented as proposed by Signal on https://feedback.secondlife.com/scripting-features/p/add-llsetsitflags-sitflaginvisible-et-al . We were hoping to have this implemented to make the avatar invisible so it would not require detaching all objects and wearing an alpha layer so you would not be rendered in smaller vehicles. It affects interacting with vehicles in a FPS setting when multiple avatars are on the objects. (For example, Avatars in the Commander Seat, Gunner Seat, and Driver Seat) This would also allow us to scale down vehicles without considering avatars rendering and ruining the immersion.

With the introduction of PBR and new features in SL the The 64k memory limit is becoming increasingly hard to work with and not suitable for modern designs. When designing more feature intensive HUDS its hard not to keep running out of memory, suggestion to double or increase the limit would be very much welcome for 2024.

Right now there's no way to make a dolly camera in SL, aside from manual panning. Similarly, chase cameras are limited to following vehicles that the avatar is sitting in. With these features, scripters could implement: Remote control vehicles Security camera views that rotate from side to side Machinima camera scripting engines Scripted tours of sims with dynamic motion Cameras that follow other avatars Independent top-down cameras for strategy games (think isometric!) and platformers (think side-scrollers!) Technical details CAMERA_POSITION_KEY would set the UUID of an object to use for the eye position and rotation. Any changes to this object's position, including via keyframed motion or omega rotation, should affect the camera's eye position according to what the client sees. Only effective while CAMERA_POSITION_LOCKED is TRUE. CAMERA_FOCUS_KEY would be the same, but for the camera focus position only. Only effective while CAMERA_FOCUS_LOCKED is TRUE. A simple implementation of this feature can reasonably ignore most other camera settings (LAG, OFFSET, THRESHOLD, PITCH, etc.) when both CAMERA_POSITION_KEY and CAMERA_FOCUS_KEY are set, without compromising on utility to scripters. Such an implementation should also adopt the rotation of the CAMERA_POSITION_KEY when CAMERA_FOCUS_LOCKED is TRUE but CAMERA_FOCUS_KEY is nil (see use cases below). A more ambitious implementation might enable CAMERA_*_OFFSET (which already exists for FOCUS) as overrides, and re-use the CAMERA_DISTANCE attribute to determine the depth-of-field target when CAMERA_POSITION_KEY is employed without CAMERA_FOCUS_KEY. Dynamic control of camera position in response to user feedback is currently unusable Although implementing position changes is possible, but involves updating the camera position to track an object with a high-resolution timer. This is both needlessly cruel to the simulator and very janky. Back-to-back llSetCameraParams() calls that update the camera position cannot be smoothed with CAMERA_POSITION_LAG in response to control() input, as the camera attempts to spline back to the non-scripted avatar camera after every input unless the CAMERA_POSITION_LAG is 0. Controlling camera rotation is currently incomplete Because SL currently assumes the avatar always wants a sensible camera orientation, there's no way right now to make an upside-down or sideways camera except in mouselook. To deal with this, it should be possible for scripters to indicate they wish to also use the rotation of the CAMERA_POSITION_KEY, at least when no camera focus is in use. (I'd really like to be able to make a car that can drive up curved walls and onto the ceiling...)

Add a new function to allow objects to take back into their inventory a rezzed object. Something like: void llTakeObject(key id, string name) or (if dataserver event is to be used): key llTakeObject(key id, string name) Where id is the UUID of the object to take and name is the proposed inventory name. The empty string "" for the name can be used to signify the taken object's name should be used. In either case, the renaming of a duplicate would still apply. This function would be restricted to only taking objects that: a) were created by llRezObject, llRezAtRoot or llRezObjectWithParams b) hasn't changed owner Taking an object will take some time, so a script would use the change event's CHANGED_INVENTORY to know when the item was in the inventory. Alternatively a dataserver event could also be raised. This function would be useful for enabling rezzers to support rezzing out no-copy objects. The rezzer would be able to take back the no-copy object when asked to derez. It could also be used to rez out a no-transfer object that can be interacted with by a user and then taken back, obviating the need to have a transfer object that the user has to take to their inventory and then drag onto the original object (I've seen cases where people drag the wrong thing into objects, and worse where multiple items got accidently included in the drag).

Add the the texture coordinate system to the projector and allow it to be animated just like llSetLinkTextureAnim() so we can project sprite images.

I propose the following API: key llStartAnimationOptions(string animation, list options); key llStartObjectAnimationOptions(string animation, list options); Params: animation: The name of the animation to start options: An option list, in the same style as llSetPrimitiveParams and other such functions. Return value: A key which can be passed to llStopAnimation to cancel the animation. When animations are started in this way, they are not uniquely identified by their name in the way that traditional animations are. There can even be multiple copies of the same animation running. So this key is needed toi identify an instance of the animation. Options: [ANIMATION_RATE, float rate]: A multiplier applied to the rate of the animation, so 2.0 plays at double speed, and 0.5 plays at half speed. [ANIMATION_OFFSET, vector offset]: Offset the root position of the animation by the given vector. Defaults to 0. [ANIMATION_SCALE, vector, scale]: Scales the root position of the animation by the given vector. Defaults to 0. [ANIMATION_PRIORITY, integer priority]: The priority of the animation. If not specified, defaults to the priority set at upload time. [ANIMATION_LOOP, integer loop]: If TRUE, the animation is looped. If FALSE, not. If not specified, defaults to the setting at upload. ... ditto for overriding other upload options. JUSTIFICATION: It is currently very difficult or impossible to use off the shelf animations purchased from other creators in scripted objects. The relative timing between animations has to be just right. The scale of the animation has to match the size of the object, meaning creators often have to resize their objects to match the animation rather than their own vision, and it's impossible to make an animated object resizable without screwing up the animations. When layering animations, you have to just hope the creators uploaded them with the right relative priorities, but you always get that one creator who decided that if you're catching a ball you legs should be exactly in this position at the max priority, so the avatar stands up awkwardly when the catch anim is played, and so on. These options are intended to return some control over how an animation is used to the user of that animation, so that it can be adjusted to match a build. Of the upload options that can be overridden, the most important are the priority (to layer animations reliably) and the in percent or frame. The latter can be used for all sorts of interesting tasks, like resynchronizing animations in the middlke of playback by restarting them with a different input frame; or selecting just portions of longer animations to use in specific contexts.

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.