Scripting Features

Scripters have long bemoaned the limitations of llStartAnimation and llStartObjectAnimation , and proposed a number of enhancements. It could be a lot better with only minimal changes to the simulator and the simulator-viewer protocol. Here are examples of great enhancements that could be made by just sending a little bit more data to the viewer along with the llStartAnimation message. To illustrate, I will name the new functions: llStartAnimationWithParams llStartObjectAnimationWithParams 1. Queuing When I ask others how the animation system is lacking, the most common complaint is Queuing one animation to play after another. Now, a script can send the viewer the message: llStartAnimationWithParams(anim, [ANIM_QUEUING]); When the viewer receives this message, it will do one of the following: If the avatar has no other active animation marked ANIM_QUEUING , it will play the animation normally Otherwise, the viewer will delay the animation start until all earlier ANIM_QUEUING animations on that avatar have stopped, either from ending, or by calling llStopAnimation . Caveat: This will currently not work well on Animesh, because animesh animations never automatically stop. I find this caveat acceptable. This is similar to the existing sound function llStartSoundQueuing . 2. Syncing This one is near to my heart. A script is animating two or more avatars. It designates one of those avatars as the leader: llRequestPermissions(leader, PERMISSION_TRIGGER_ANIMATIONS); llStartAnimationWithParams(leader_anim, [ANIM_SYNC_LEADING]); It designates the other avatars as followers: llRequestPermissions(follower, PERMISSION_TRIGGER_ANIMATIONS); llStartAnimationWithParams(follower_anim, [ANIM_SYNC_FOLLOWING, leader]); When the viewer is asked to start an animation marked ANIM_SYNC_FOLLOWING , it: Downloads the animation Waits until any leader animation marked ANIM_SYNC_LEADER encounters a loop point (including waiting until an ANIM_SYNC_LEADER animation is started at all) Starts the animation normally This is very similar to these existing sound functions: llLoopSoundMaster llLoopSoundSlave llPlaySoundSlave It would be up to the animator to create animations suitable for syncing. Synced animations should usually: Have identical loop durations Have no loop-in period The most flexible leading animation will be 0 priority and an animate zero bones; providing nothing but a looping beat. This is also true of llLoopSoundMaster ; The best master sounds are silent. 3. Property overrides Animation assets have a number of parameters you can set at upload time, but can't be changed afterward. It would sometimes be nice if you could change them, and, llStartAnimationWithParams provides a convenient place to override them. The most useful ones to override would be: ANIM_PRIORITY ANIM_DURATION ANIM_EASE_IN ANIM_EASE_OUT 4. Speedup Similar to ANIM_DURATION above, but, speed up the animation by a constant factor, regardless of the asset's native duration: llStartAnimationWithParams(anim, [ANIM_SPEED, 2.0]); // Double speed = half duration llStartAnimationWithParams(anim, [ANIM_SPEED, 0.5]); // Half speed = double duration 5. Blending Allow an animation to not fully replace any channels in animations in overrides, but, linearly blend the bones between this animation, and the next-lowest one in the animation stack: llStartAnimationWithParams("breathing", [ANIM_BLENDING, 0.1]); This one would require the most changes to the viewer, but would open up new ways to animate characters, and would often allow multiple animations to be consolidated together more flexibly Summary I hope you can consider this proposal. I considered it carefully so that it can be implemented with minimal changes to either simulator or viewer. I heavily limited the scope, so it has a clear end point, unlike Puppetry: It does not require changing the animation asset format It does not require any new viewer -> simulator communication, beyond the existing message "hey this animation ended". It does not require the simulator to download or understand animation assets. It does not require new simulator -> viewer communication. It only adds a few new fields to the existing "animation started" message llStopAnimation and llStopObjectAnimation require no changes

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

Currently, if you want to walk, you have to hold down the W/↑ key, which can get annoying and - for people with arthritis, for example - painful. Many modern platforms therefore have an auto-walk feature which makes walking a toggle. For SL, this would also be a nice feature. You can assign a key, tap it, and you walk until you hit the toggle, W/↑ or S/↓.

This would be an extension to llGetInventoryAcquireTime but to get the last time an object's inventory items was updated. Primarily useful for INVENTORY_NOTECARD inventory items. Currently when a note card is edited within an object the CHANGED_INVENTORY change event is triggered. For an object with multiple control and/or configuration settings note cards there is no easy method to check to see which note card has been updated and possibly needs to be processed. And so instead of just processed the one needed changed note card, all the control/config note cards have to processed in turn. It would still be up to the script maker to track the update times on the various needed control note cards of course, but having a way to determine which files actually need to be processed and those that can be skipped would help in reducing some load on the servers and speed up internal script updating. This would also be in Slua for ll.GetInventoryModifiedTime of course.

llGetParcelPrimOwners() currently only returns upt o 100 results, with them being sorted alphabetically by agent uuid. this makes it impossible for scripts to reliably obtain a complete list of object owners when a parcel has more than 100 agents with rezzed objects, which can be common in places like sandboxes or shared rental parcels Being able to specify options like the result count, sorting order, etc would make the function much more useful. script memory usage from large lists is also less of an issue given the fact that lua/the lsl-lua compiler will provide 128kb instead of lsl's 64kb, and the result count option would allow scripts to control memory usage This would be a new function instead of adding onto llGetParcelPrimOwners , so it doesn't break existing scripts: llGetParcelObjectUsage(vector pos, list options) vector pos - position in region coords list options - list of configurable options options: LIST_COUNT - amount of result pairs to return SORT_BY - sorting order of the return list SORT_BY_UUID_ASC/DESC - alphabetically by uuid SORT_BY_USAGE_ASC/DESC - by usage amount llGetParcelObjectUsage(llGetPos(), [LIST_COUNT, 50, SORT_BY, SORT_BY_USAGE_DESC]) The list formatting, permission requirements, etc. could be similar or identical to llGetParcelPrimOwners()

I'm posting this here since my original post as a bug was closed with an "expected behavior"-type reply. As referred to by the discussion mentioned in the LSL portal documentation for llGetLinkPrimitiveParams() ( https://community.secondlife.com/forums/topic/486118-only-set-ambiance-on-prim_projector/?_gl=11wd89ez_ga_T7G7P6DCEC*MTcwNjU2MzkwNS4xLjEuMTcwNjU2MzkwNy41OC4wLjA.#comment-2446570 ) the call with PRIM_PROJECTOR currently triggers shouting on the DEBUG_CHANNEL about an unsupported parameter. I understand that PRIM_PROJECTOR is considered, for now, as write only, but I see no valid reason why it could not be readable at all. The current situation is inconsistent in my opinion. While I understand the potential problem with texture rights, I believe the behavior of this parameter should be consistent with that of PRIM_TEXTURE: if the texture is in the prim's inventory, return its name, else if the owner has full permissions over the object return its UUID. Otherwise return NULL_KEY. This is important to be able to "copy" a user-set parameter from one object to another for example, I want to read the parameters and send them to another object. Please make PRIM_PROJECTOR behave just like PRIM_TEXTURE in this regard, as described in the discussion. Thanks!

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.

Basically it does the same as putting a script with llSetRemoteScriptAccessPin in the object's on_rez Right now if you have a project that relies on updating scripts of rezzed objects, you'll need to make a script that sets the pin and requests an update via the llSay system. This makes said script a major failure point because llSay has a tendency of being dropped during lag spikes, forcing you to set up a syn/ack system. And if you later discover that your syn/ack system wasn't as robust as you thought, or want to change it in any way, you may potentially have hundreds of items that you need to manually rework. Being able to set the remote script access pin directly on rez would eliminate the need for a syn/ack system entirely. Because you could: Rez object with pin Remote load the script(s) immediately in object_rez Profit! Another added benefit of this system is that you could rez the object without the scripts that you intend to overwrite with remote loading, saving time rezzing the object.

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.

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.