Scripting Features

In order to change the value of one parameter using llSetPrimitiveParams , the script must specify values for all of the parameters for the given flag. With the addition of PBR, which can be changed in child links only with this function, this has never been more cumbersome. I propose a new constant be added to preserve the existing value for the position it is placed in. A "NO_CHANGE" or "KEEP" constant could replace known or unknown values in order to preserve them while changing other values following a flag. Take this for example: llSetLinkPrimitiveParamsFast(2, [PRIM_TEXTURE, 0, "12345678-1234-1234-1234-123456789012", <1,1,0>, <0,0,0>, 0]); If we don't know the texture on face 0 of link 2, then we would need to add a second script in that link to change any of the above individual parameters, or we could have something like this: llSetLinkPrimitiveParamsFast(2, [PRIM_TEXTURE, 0, NO_CHANGE, <1,1,0>, <0,0,0>, 0]); Because some parameters require other parameters to be defined when changed, llSetPrimitiveParams should assume defaults (or revert to previously used values, if available) when not provided or currently in use, such as mask_cutoff when PRIM_ALPHA_MODE_MASK is used. This feature would provide a significant quality of life improvement to scripters working with objects that they don't have all of the source items for.

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

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

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

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.

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

Particle system sorely need an overhaul and additional settings to make the best use of it. I've broken up a list of features to make tracking for each one easier for the devs. Texture Animation for ParticleSystem Easing Interpolation for ParticleSystem Alpha blend mask mode for ParticleSystem Color Noise for ParticleSystem Reverse Target for ParticleSystem Emissive Interpolation for ParticleSystem Select Sprite for ParticleSystem Offset Position for ParticleSystem PBR for ParticleSystem "MID_" Flags for ParticleSystem Follow a chosen attachment point

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.

hi, has anyone ever asked for a function called llGetGroupKey(key id);? A function like this would make it easier for many stores to rez group gift giver in any group instead of the landholding group. llSameGroup & llDetectedGroup are not an option if it is group owned land and the store uses a different group. LG Dae

I use this in scripts to know if rez is possible integer canrez() { list parcelownerandgroup = llGetParcelDetails(llGetPos(),[PARCEL_DETAILS_OWNER,PARCEL_DETAILS_GROUP]); list objectownerandgroup = llGetObjectDetails(llGetKey(),[OBJECT_OWNER,OBJECT_GROUP]); integer parcelflags = llGetParcelFlags( llGetPos() ); integer result = FALSE; if(llGetOwner() == llList2Key(parcelownerandgroup,0)) result = TRUE; if(llList2Key(parcelownerandgroup,1) == llList2Key(objectownerandgroup,1) && (parcelflags &PARCEL_FLAG_ALLOW_CREATE_GROUP_OBJECTS)) result = TRUE; if(parcelflags & PARCEL_FLAG_ALLOW_CREATE_OBJECTS) result = TRUE; return result; } It not totally reliable. It would be nice to have a llCanRez() or llCanrez(vector position)