Scriptable prim property: llSitAnimation(string anim)

llSitAnimation(string anim);

Changes the default sit animation for a primitive or linkset.

VOTE: http://secondlife.com/vote/index.php?get_id=1630

This function would allow a script to set the default animation that plays upon sitting on an object to be different from the standard avatar sit animation. While objects can currently be scripted using llStartAnimation() to offer this behavior, there are several benefits to having a specialized function for this. These benefits include:

* Prevents the standard sit animation from ever being triggered.
* Easier to script for simple objects like chairs, couches, beds, etc.
* No need to request permissions which isn't required for attached/sitting agents anyway.
* Becomes a property of the prim, eliminating the need for a "sit script" once set.

As with llSitTarget() and particles, custom sit animations become a property of the prim. So if a script gives a prim a custom sit animation, and that script is deleted, the custom sit animation remains. This would allow builders to create objects with custom sit animations that can be, in the end, scriptless.

You can clear a custom sit animation, returning a prim to the default sit animation, by calling llSitAnimation("";

When triggered by sitting on the object, a custom animation's priority level is retained.

Yes yes yes, oh please yes!!

The most important reason for this feature would be your last one, preventing the need for a billion sit-animation scripts. As I detailed here, those extra scripts really impact the performance of a sim, even when they're not doing stuff 99.99% of the time. With a feature like this, I could remove hundreds of scripts from my sim, drastically increasing performance (and adding room for a lot more scripted effects) while also adding a lot more sit targets and animations to prims in the sim.

It'd also be neat if we could set this and a sit target via the UI. That would allow a lot more people who don't have any understanding of scripting (or of the arcane rotation math required to set a sit target) to set sit targets that play custom sit animations. I don't know about you, but I spend a fair amount of time on sit targets, and it's a process of repeated trial and error trying to get the numbers right, even though I know enough rotation math to take a decent guess at the right numbers. I know this litters the asset server with the intermediate versions of my sit-target script, and this feature suggestion would eliminate the need for that.

How about a proposal in the feature voting tool?

A proposal has been created at the following URL. Thank you for your support.

http://secondlife.com/vote/index.php?get_id=1630

Sit animation scripts that don't use listen on zero shouldn't significantly impact sim performance.

Follow my link above, Argent. It's not that the sit animation script will do much processing itself, it's that a running script in and of itself puts a noticeable load on the server, even if it has absolutely no code in it at all. This means that putting sit animation scripts in a lot of prims across a sim definitely will have an impact on that sim.

Er, I did follow that link. You're talking about an effect so small you'd need thousands of poseballs in the sim to have a noticable load. There's 45 physics frames a second, so you're not even going to see scripts being lagged (let alone user-visible lag) up to a bit over 20 milliseconds per frame. By your calculations that's 1280 scripts. That's an awful lot of poseballs.

Sure, it'd take a lot of poseballs to load a sim down, but that's not all that people are doing in a sim. Other scripts will be used for doors, vendors, and other little details. Then you need to consider the fact that the average av brings with it at LEAST a hundred scripts a piece, sometimes drastically more, and that can load your sim down very quickly. My sim has something on the order of 500 scripts in it, but often when 10 avs show up, our number of active scripts goes up to 2500.

The point is that every script saved is very important, because by their sheer numbers, scripts load a sim down. Especially when you've got script-intensive effects like I do that will start to degrade as the script load brings the total frame time above 22.2 ms and scripts have to start jostling for processing time, it's very much necessary to save scripts when I can. This often means forgoing adding cool sit-pose scripts to as many prims as I'd like to, because that uses up scripts. You've got only a certain number of scripts you can realistically add to a sim before they start shoving each other around, and sit-pose scripts take up those valuable slots.

Being able to get rid of a lot of them (and do sit animations "for free", from the point of view of script load) would be a huge win. There's also the fact that, as more people who really have no idea about script-load use a feature like this, we'll see a drop in the number of scripts in mainland sims. This is good, since it's not unheard of for mainland sims to have 5, 6, and 7000 active scripts, which makes any script run hideously slowly.

Indeed. And you could implement extra capacilities in SL for every one of them... you could even make ALL scripts irrelevant by implementing them all in the client. Why start with poseballs? They're not a large part of the problem and you'd need implement more functions to finish the job. For example, most actual poseballs are still going to have a script in them to hide them when you sit on them.

Here's how I'd prioritize things:

1. llSetLinkParams(list links, list params)

Apply the listed params to all prims in "links". This would remove the need for 10-100 scripts in any avatar with wings.

2. llReplaceAnimation(string default_name, string new_anim);

Replace animations on the avatar. Get rid of animation overriders.

3. instant_message(key sender, string message)

Event... recieve an instant message from another object. Get rid of almost all high listeners with this one.

Sure, those are all three really good ideas that I can get behind. It'd be neat if llSetLinkParams() just took a list, so that you'd specify [link_number, param specification, link number, param spec...] so that you could do, conceivably, changing the alpha on an entire subset of prims all at the same time -- otherwise people might still be tempted to use multiple scripts so things all happen at once.

Anyway, I don't see why prioritizing your stuff higher in your mind invalidates what we're saying here, I just think this is a good idea, along with those :) I think it'd get a lot more use than you might guess... it'd allow me to make my builds far more immersive "for free", by putting a pose on a good portion of the prims lying around. Also, it's probably a lot easier to implement than any of the three ideas you listed. Given the benefit vs implementation effort, I think that puts this feature right up there in contention with your three.

Incidentally, do you have feature voting proposals in for those?

I think what Argent Stonecutter is saying is roughly something like :
1) LL can only bring in a few new features every month.
2) Given #1, we should channel all our energy into pushing for the most useful new features.
3) Given #2, we should probably focus on pressuring them to add instant_message(key sender, string message)..... because that function alone will eliminate so many listeners that the net gain would dwarf other proposals mentioned in this thread.

Catch the big fish first.