"Event on sit"

Howdy guys. I'm pretty new to scripting; need some advice.

Here's the plan. I've got an object - let's call it "Object A". Object A has a couple of things in its inventory - Object B and Object C, as well as a script. The script makes it so that if you click on Object A, it rezzes Objects B and C from its inventory. It works, of course, and I'm all proud of myself for this mediocre achievement, most of which can be credited to the wiki.

Question: How do I make it so that this happens by SITTING on Object A, rather than clicking on it? I'm looking and digging and searching, and I can't find any function that gets this done.

Help, please?

You can use the CHANGED event and check for CHANGED_LINK.
Its in the wiki http://wiki.secondlife.com/wiki/Changed

Edit: And in the post below

You'll get a changed(CHANGED_LINK) event when somebody sits on an object.

changed (integer mask)
{
if (mask & CHANGED_LINK)
{
key id = llAvatarOnSitTarget();
if (id != NULL_KEY)
{
// ... do stuff
llUnsit (id); // toss user off
}
}
}

I think you'll need to also call llSitTarget with some non-zero vector or you won't get the event. You'll also get this event if you play with the link set (add prims to the object) but the llAvatarOnSitTarget check will spot that and only work if somebody's sitting.

Code above's untested but should be pretty close..

A (very?) simple script:

default
{	 
	changed(integer change) {
		if (llAvatarOnSitTarget() != NULL_KEY)
			llRequestPermissions(llAvatarOnSitTarget(), PERMISSION_TRIGGER_ANIMATION);	 
	}
 
	run_time_permissions(integer perm) {
		string anim = llGetInventoryName(INVENTORY_ANIMATION, 0);
		if (anim != "") {
			llStopAnimation("sit");
			llStartAnimation(anim);
//Do some other stuff
		}
	}
}

Great! I'll play around with these solutions. Thanks much guys!

You WILL get the changed/CHANGED_LINK event if someone sits (or stands), even if no sit target has been set. You'll just never get anything but NULL_KEY back from llAvatarOnSitTarget(). Remember that an avatar sits on the OBJECT, not the PRIM, and any change to the link set of the OBJECT causes the changed/CHANGED_LINK event. Sit targets are just a convenience test for scripts and a positioning/space hint for the sim.

And the one last gotcha to remember is that a sit target has to be defined and can not be all zeroes.

If there is no sit target then the CHANGED_LINK will not fire when an avatar sits down.

llSitTarget(<0.0,0.0,0.0>, ZERO_ROTATION); is all zeroes and the CHANGED_LINK will not fire when someone sits down.

llSitTarget(<0.0,0.0,0.001>, ZERO_ROTATION); will work!!!!!

Not correct. See my last post. Or try it, if you like. Just print out when the changed/CHANGED_LINK comes in, ignoring completely the result of llAvatarOnSitTarget().

Have tried it before because I was bitten by it a couple of times. If you do not have a sit target defined NULL_KEY will be returned when someone sits down.

Per the wiki:

"This will only detect avatars sitting on sit targets defined with llSitTarget."

&

default {
    state_entry() {
        llSitTarget(<0.0, 0.0, 0.1>, ZERO_ROTATION); // needed for llAvatarOnSitTarget to work
        // Note that if both the vector and the rotation are zero,
        // the SitTarget is removed instead of set and the following will not work:
    }
    
    changed(integer change) { // something changed
        if (change & CHANGED_LINK) { // and it was a link change
            llSleep(0.5); // llUnSit works better with this delay
            if (llAvatarOnSitTarget() != NULL_KEY) { // somebody is sitting on me
                llSay(0, "Get off!");
                llUnSit(llAvatarOnSitTarget()); // unsit him or her
            }
        }
    }
}

I'll agree with this; I tried it several times without a sit target defined and kept spamming the debug channel with "cannot find agent..." notices. Setting a sit target solved this problem.

I would've needed it in either case; one of the (several) functions is a llStartAnimation, and it's a standing pose, so I had to use the sit target to position the avatar properly, poseball-style.

Glad to see you taking an interest in scripting Dakota!

BTW, did you find the Linden sword in the treasure chest in the cave at Windfall? I never noticed the side passage until I was in there a couple of times.

I'm not debating that, but the changed event with the CHANGED_LINK flag definitely DOES fire. If you wanted to you could use it to iterate through the list of link keys to find what avatars are sitting and compare to a previously saved list. Sit targets are not necessary for determining whether and what avatars are sitting on the object; they are just a convenience so a script can say, "Is an avatar sitting in this location that I have decided is interesting for this prim?" And they also serve as a positioning hint for the sim code; a way of deciding where to place avatars first (note that once the sit targets are "filled", avatars can sit anywhere there is "room"; that's why vehicles often have an extra prim with a sit target used solely to eject the N+1st sitter).

Sorry Heewee,
pick one:

A) I misread intent

B) Skimmed over your post without fully reading

C) My sig has all of the explanation necessary

D) Residual pharmaceuticals from my youth broke loose and decided to exert their effect

E) Age and pre-dementia

F) Completely confused

lmao.

i just had an odd thought. will:

llGetLinkName(llGetNumberOfPrims())

get the same result as:

llKey2Name(llAvatarOnSitTarget))

assuming, there's only one avatar sitting on the object

and what about if you have 2 or more prims in an object and with the sit targets set right so that the avatar is in the exact same pos when they sit on either prim. would llAvatarOnSitTarget pick them up in both scripts?

That's a very good question that I have been wondering about for a while. If you move an avatar away from a sit target, another avatar can sit on it while the first is still sitting on the object. If you move an avatar ONTO the sit target (very close to it), I'm pretty sure another avatar cannot sit on that sit target, but I haven't tested whether llAvatarOnSitTarget() starts registering them (I suspect it does). Nor have I tested what happens when two sit targets are very close together.

This would be a very good area to do some more investigation. Can multiple sit targets share a sitter? If they are close enough together, CAN two avatars still sit on the different sit targets, or will the sim's logic decide they are both full? H.mm.

I did! I found it right away, in fact. I'm a sucker for exploring caves and tunnel builds.

OK, while I've got somebody's ear, I've got another question.

First, to provide some situational awareness. The object I'm making is supposed to do a couple of things. The particular script I'm struggling with is supposed to do two "sets" of things when you sit on the object the script is in:

Set 1) Position your avatar properly, stop your default sit animation, and start an animation from the object's inventory.

Set 2) Rez two objects from the main object's inventory, which are supposed to attach to your avatar.

The function of the animation, aside from the obvious, is to freeze your avatar in a very specific pose, so that when the two objects attach to you, they look like fixed parts of the original object.

Here's the script as I've written it so far:



The attachable objects rez like they're supposed to; they have their own scripts which make them ask to attach to you as soon as they rez. That's fine, it all works fine there.

My problem is with the positioning and animation. Firstly, although when I uploaded the animation I gave it a priority of 4 (the highest available), and my avatar -does- get animated, it happens incorrectly. It's a standing animation; when I'm standing on flat ground and use the animation by itself, it works perfectly. But for some reason, when the object's script animates me, my lower legs become bent back at a random angle, so it looks as if I'm float/flying, rather than standing. Occasionally, my upper torso is tilted back at a small angle as well. The particular angles change with each sit. Although the avatar IS "frozen" when animated thus (except for the head, which don't matter), the avatar just doesn't look the way it's supposed to.

Also, although my avatar's physical XYZ coordinates relative to the object are always right, my avatar's "rotation" (i.e., the direction I'm facing) seems to be ever-so-slightly different every single time. Why is this important? Because when I align the two attaching-objects, then copy and paste them into the original object's inventory (so the next time they rez, they should already be aligned properly), they AREN'T aligned right. Oh, they're aligned perfectly -with each other-, but never with the primary object, because I'm always just a little "off". That's not right; I've seen and used objects before which animate you in the exact same position and attitude every single time, and whose animations work completely every single time without random deviations, and whose rez-and-auto-attach objects line up properly every single time.

I've tried defining a rotation in the sit target parameter (i.e, changing ZERO_ROTATION to something like <0, 0, 0.001, 1>, but this doesn't solve the problem. Am I missing a parameter or definition somewhere? Did I make a mistake with the animation itself (made using QAvimator) somehow?

This could be a reason. You have to make sure, that all joints in the first and the second frame are different in QAvimator. The days I used QAvimator (now using Blender for animations), I made the startpose in second frame, copied that second frame completly into the first, and then I moved all joints to another position in that first frame. Then going on with the other parts of the animation. This way you can make sure, that SL notice that all joints are part of the animation.

Ah, I see...so, unless you change a joint's value at least in some small way, SL will assume it's not part of the animation and thus won't "freeze it" into place (in the case of a pose)? OK, I think I can fix that. Thanks!

llGetLinkKey(llGetNumberOfPrims() - 1);
//-- must remember multiprim objects index from 0 not 1

it'd get the last sitting Av (or the last prim) regardless of sit targets. IIRC Av's disobey the joined links rule and stack on the end, not insert after root, or before each other.

Actually there is only a prim at link index 0 (the root prim) if it is a single-prim object. Multi-prim objects DO index from 1, with 1 being the root and llGetNumberOfPrims() being the last link. An avatar sitting on a single-prim object counts as a multi-prim object and will cause the numbering to start at 1.

Very unfortunate IMO (why not just use 0-based indexing always?!?!?), but true.

http://www.lslwiki.net/lslwiki/wakka.php?wakka=link

good catch, for some reason I had it reversed. thought the change from llGetLinkName to llGetLinkKey stands.