multiple avatars on one prim sit target don't work

Hi,

I have a long bench where I want to sit several avatars. I don't want to use poseballs to save prims, so I tried this sit script to give each avatar a unique sit position on the bench:

vector sit = <-0.76425, -0.56393, 1.0>;
vector size;
default
{
    state_entry()
    {
        llSitTarget(sit, <0.46244, -0.52195, -0.47623, 0.53565>);
        size = llGetScale();
    }

    changed(integer change)
    {
        if (sit.z >= (size.z / 2))
        {
            sit.z = -(size.z/2);
        } else {
            sit.z += 0.5;
        }
        // llOwnerSay("new sit pos: " + (string)sit);
        llSitTarget(sit, <0.46244, -0.52195, -0.47623, 0.53565>);
    }

}

This works ok when I try it with one avatar, each time i sit down, the new sit postion will be set. But it seems not to work if an avatar is already sitting on the prim.

Is it possible the the sit target will have no effect if an avatar is already sitting?

TIA

Jim

According to the wiki if you set the sit target to <0.0, 0.0, 0.0> it will removed the sit target, and since you don't get a handle for a sit target it makes me think that you can only have one per prim, so you are probably just changing the sit target instead of making a new one. But I'm a newb so I may be wrong.

Instead of moving the sit target, try moving the avatars as soon as they sit, using llSetLinkPrimitiveParams.

Since things like llStart & llStopAnimation don't take a key, how do you deal with the animations for people who sit (and then stand) on this? Or are you trying to use the default sit anim with multiple positions?

Sorry, I think you're out of luck, and you'll need a prim per sit target.

Meade, a script can have at most one avatar holding permissions,and the functions you mention implicitly affect only that avatar.

Of course, once a script starts an anim, it can get permissions from another av. But to turn the anim OFF when the av wants to leave, it would need to ask permission again. (You may notice that for some dance balls, when you want to quit, it asks you for permission to animate you, and unless you say "yes", it can't UN-animate you. I found this rather confusing as a newbie!)

But I don't think one prim can have multiple people sitting. I'm pretty sure about that.

Some objects can appear to have multiple people sitting on what looks like one prim, using the ability to "pass" events -- see the LSL wiki for more info. But even in that case there's at most one sitter per prim. The avs just appear to be sitting on the same prim. At least, that's how I think it must work.

...unless you _don't_ specify a sit target. In that case, you can have more than a couple people sitting on a single prim - you just don't have any control over where they sit.

Make it to where the cushion or ball or whatever sit target rezzes another cushion, ball etc a set distance over when the changed event triggers.

For example; you could have bleachers with one sit ball in the air. WHen someone sits on it then another will rez one meter over and when that one is sat on then it rezzes another etc. In this manner you could fill the bleachers with no more then one sit target available at a time.

Right, a prim can have at most one sit target.

If it has no sit target, as many avatars as can "fit" can sit on it, but their position is determined (more or less) by where they click when they choose "Sit". It's still possible to animate them all with a master script that detects the CHANGED_LINK of sitting and farms out the animation to slave scripts, one per seated avatar, kinda like how dance machines work. In the past, this didn't really work because without a sit target, there was no control over the avatar location, so the animations were apt to look silly; but now, with the ability to position a seated avatar with llSetLinkPrimitiveParams, it should be possible to "fake" sit targets, as Deanna suggests, to make the anims look right.

If a prim has a sit target (like a poseball), it defines the avatar position, and animation can be done in the same script that detects the CHANGED_LINK event of sitting. Since primcount was mentioned as a concern: the sit target prim can be temp-on-rez; the sim won't steal it out from under a sitting avatar. (But of course a temp-rezzed prim would be a bad place to put a no-copy animation!)

Separate scripts are unnecessary. Just request permission from the specific agent immediately before starting or stopping an animation. Unlike a dance machine, the avatar is sitting on the prim, so PERMISSION_TRIGGER_ANIMATION is granted automatically when requested, and you don't have to wait for a user response.

Except if you want to stop the animation once they stand up.

Of course, if you are dealing with multiple people on a single prim without a sit target, you won't get notice that they stood up anyway, so they will have to use an animation stopper to stop the animation.

I've been doing some tests, and it appears that any animation started while the av was seated is automatically stopped when they stand, but I could be wrong about that.

Sure you do. The changed( CHANGED_LINK ) event is still raised when someone stands, even if someone else is still sitting, so it's just a matter of figuring out *who* stood up.

I deal with some poses for sit targets on a regular basis and I can confirm Deanna's statement that if you stop the default sit anim and start a custom one, when you stand up, you don't have to stop the anim as it is stopped on its own.

As to the figuring out which av stood up, I can think of several ways, but it's too early for me to really think too clearly about it though lol.

It seems to be the case, though I have seen people get stuck in anims after standing; not sure if it was related to lag, or just an artifact of that issue, but at any rate, I wouldn't depend on it a) working all the time, or b) not changing at some point in the future.



Hmm. for some reason, I thought changed() wouldn't fire without a sit target.. must be thinking of something else. Obviously llAvatarOnSitTarget() won't work, though.

Yes, even if you do get notification, you can't tell who it was that stood up. You can't even tell if someone stood up or sat down, without a sit target, or even if you have a sit target, and it is already occupied, so basically notification is useless for multiple avs.

I think that's right. I guess the script could request permissions again--for real this time--of the just-stood avatar, if one really didn't want to use slave scripts. And every once in awhile the script will get lucky and the sit/stand operation will be LIFO, saving one of those requests. I knew I'd eventually have to wake up my lazy alt and test this hare-brained scheme. Turns out to work as I'd expected: the script keeps getting CHANGED_LINK events whenever any of the sitters stand--they're all part of the linkset as long as they're seated--so it would be possible for the animating slave script to stop the animation, as normal.

This reminded me, though, that there's a gotcha in the other scheme I mentioned about temp-on-rez poseballs. I remember now that I had to make them permanent--llSetPrimitiveParams([PRIM_TEMP_ON_REZ, FALSE]);--while an avatar was seated, in order for the script to stop the animation when they stand; otherwise the sim may clean out the poseball before the script can do anything.

Well, the script that does the animating has to remember who it animated, then on CHANGED_LINK hunt through the linkset to see if that avatar is still seated; if not, stop the anim and make ready for next sitter.

Now, I realize that what I *just* posted about temp-on-rez poseballs may have to do with something very exotic I'm doing to get the avatar animated in the first place, so it may be that if that temp poseball evaporates on stand, the custom animation that it does to the avatar would be stopped... Yet another thing to try.

EDIT: Update: Well, so far I haven't seen it fail: if I stand from a prim that animated me, that animation is getting stopped--even if it's a temp prim that gets GC'd by the sim before the script can even say that it saw a CHANGED_LINK upon standing. So now... how confident are we that every poseball script is just being superstitious in stopping the animation when the avatar stands? It would be pretty nasty to find out later that some of the time, under some conditions, avatars get stuck in anims without that step... but one feels pretty foolish about doing it if it's never actually necessary.

Really the only way you can get stuck in an animation that I've seen from a 'sit object' is if you teleport while still seated. Anytime I've hit the stand button I've always had my animation stop automatically...though depending on lag I might retain the pose until I move since for some reason my client was too busy with the lag to render my new animation pose.

The more-common problem I've seen is where Other people will continue to view you in a bugged pose. This usually happens from them logging in or teleporting right at the time that you stood up. There are various other random occurances of this problem however that have no real reason evident.

You could still make a single prim seatable by multiple AV's and track them if you combine a number of things regarding the link commands. It would require a few steps that might make it too slow to be worth it, but then I'm not quite the performance guru in scripting that I should be.

If you use llGetNumberOfPrims inside the changed event, you can effectively tell if someone sat or stood up as that number would go down if someone stood, or go up if someone sat. To tell Who got up or sat down, you could keep track of the new 'prims' with llGetLinkKey or llGetLinkName in a list. If someone sits, you would just add another name to the list, and if someone stood...well that's the bad part of my logic. From what I can tell, you would need to redo your list of keys or names and compare to see who is missing if someone stood up.

You could also use llSetLinkPrimitiveParams to sort of set sit targets by having a list of local pos vectors that controls where people are when they sit.

Really though, this would all probably become more complicated than it was worth. I would want more than one script...one with the sitting/standing controls and another to keep track of the list of sitters so there won't be some big delay caused whenever someone stood up because the script is too busy trying to figure out who left.

Ooh.. yeah.. that will work; didn't think about the llGetNumberOfPrims() trick. Heh. I should; I play with llSetLinkPrimitiveParams on sitting avatars all the time.

But, yeah, you're right; I think that is what we're all coming to the consensus on; it's a lot of work to try and work around something which would probably be better managed with multiple sit targets in multiple prims ultimately.

If you want to save prims, don't make dedicated sit prims, just use the rest of the prims in the object/vehicle, and put in offsets and rotations to put them where you really want the avatars to appear seated. Come to think of it, that's what I need to do do to my train cars...

Typical: I was obsessing on this while a consensus was forming that it wasn't worth the trouble.

Anyway, here's a dirty little hack that seems to work with *very* cursory testing. This uses the single script approach with no attempt to stop animations--they do indeed seem to stop when the avatar stands from the prim that contains the script that animated it. (... that lay in the house that Jack built. ) For illustrative purposes... do with it what you will... your mileage may vary...

list sitOffsets =
    [ <0.5, 0, 1>
    , <0.5, 1, 1>
    , <0.5, -1, 1>
    , <0.5, 2, 1>
    , <0.5, -2, 1>
    ];

integer numSeats;
rotation sitRot = <0, 0, 0, 1>;
integer baseLinkCount;
integer currLinkCount;
string theAnim;
list seatedAvatars;

default
{
    state_entry()
    {
        currLinkCount = baseLinkCount = llGetNumberOfPrims();
        theAnim = llGetInventoryName(INVENTORY_ANIMATION, 0);
        numSeats = llGetListLength(sitOffsets);
        integer seatNumber;
        for (seatNumber = 0; seatNumber < numSeats; seatNumber += 1)
            seatedAvatars += NULL_KEY;
    }
        
    changed(integer change)
    {
        if (change & CHANGED_LINK)
        {
            integer newLinkCount = llGetNumberOfPrims();
            if (newLinkCount > currLinkCount)
            {
                key newSitter = llGetLinkKey(newLinkCount);
                if (newLinkCount > baseLinkCount + numSeats)
                {
                    llInstantMessage(newSitter, "Sorry, out of places to sit");
                    llUnSit(newSitter);
                    return;
                }
                else
                {
                    // Find empty seat
                    list currSeatedAvatars;
                    integer sitterLink;
                    for (sitterLink = baseLinkCount;
                        // could be baseLinkCount+1 for multi-prim seats.
                        sitterLink <= currLinkCount; 
                        sitterLink += 1)
                            currSeatedAvatars += llGetLinkKey(sitterLink);
                    integer seatNumber = 0;
                    while (-1 != llListFindList(currSeatedAvatars, [llList2Key(seatedAvatars, seatNumber)]))
                            seatNumber += 1;
                    // Empty seat found at seatNumber
                    seatedAvatars = llListReplaceList(seatedAvatars, [newSitter], seatNumber, seatNumber);
                    //debug: llOwnerSay((string)newSitter+ "..." +llDumpList2String(seatedAvatars, ", "));
                    llRequestPermissions(newSitter, PERMISSION_TRIGGER_ANIMATION);
                    llSetLinkPrimitiveParams(newLinkCount, 
                        [ PRIM_POSITION, llList2Vector(sitOffsets, seatNumber)
                        , PRIM_ROTATION, sitRot / llGetRot()
                        ]);
                    llStartAnimation(theAnim);
                }
            }
            currLinkCount = newLinkCount;
        }
    }
}

Ah see, I was too lazy to write it....my only concern with making it multiple scripts is I'm not sure how fast it will be able to fire with the while loop...guess it would really depend on how many people max you allowed to sit and how big the list is, but I was thinking more like 6 or more. With 3 I would think you could have pretty reasonable refresh, though I don't Think the while loop will stop the changed event from firing, so my only fear would be if 2 people stood up at the same time.

That's really the reason why I don't know as it would be worth the bother as that might cause it to freak out, but then your mileage will vary depending on the application of it.