llAvatarOnSitTarget with multiple sit targets?

Okay, lets assume an object with ten prims. Eight of them have sit targets and menu-based animation changing that is local to the prim. Assume that this functionality works brilliantly if you click on your own seat.

Here are the problems I'm having:
1. The object is supposed to spawn a menu for the user when s/he first sits down. It does that, but it also pops the menu for everyone sitting on any of the seats.

2. If the user click on someone else's seat, it pops a menu *in the clickee's client*. This is really annoying to others, if you miss your seat.

I'm hoping that there's some way to distinguish which user is on which prim. I'm working under the assumption that I just have the dumb today.

you have to either track on sit target in the individual prims, then filter by that key, or or track the positions they are at in the root (to get occupied seats), and filter by key and and prim number clicked.

to tired right now to guess why it's duplicating across on sit, but it's almost assuredly not using filtering by sit target for key, on click

You probably need to add some statefulness to your changed event handlers. A very recent thread with a similar problem: /54/35/318247/1.html


Once you've captured the sitting avatars as above, you can use that key to compare against llDetectedKey. Only put up a dialog if you have a match.

Problem 2 is simple. A menu goes to the avatar you post it to.

If A sits, B clicks, and A is getting the menu, it's because that's what your code does. You're sending the menu to the sitter, not the clicker. You should ignore the click unless it's by the sitter.

Problem 1 is a little trickier. Evidently every prim's script is getting an event when someone sits on another prim. Now, I don't remember seeing that, but I started with poseball scripts that essentially worked well when in a linked object. But I can't think of any code in the "changed" handler to figure out whether the change was for this prim or another prim.

So, I think you have something odd going on here.

Put an llSay() in your changed() and run_time_permissions() handlers and see exactly what's happening when you sit on another prim. My guess is, the changed() handler is NOT being invoked (at least, not with the change indicating avatar sit/unsit), so you shouldn't be requesting permissions or getting them. I suspect your script is calling llDialog() (or asking permissions) for some other reason. Find out what that reason is, and fix it.

It's very helpful to put llSay() calls (or llOwnerSay(), to avoid disturbing your friends) at a number of points in your script so that you understand the exact sequence of events. Be sure to give every prim a different name, because the prim's name is what will be printed.

The results for llDetectedKey() are not defined for a changed() or run_time_permissions() handler. Be sure you're not using llDetectedKey() for any handler that isn't passed a "integer total_number" parameter.

It's a common mistake, we've all done it. Often, when adding a new handler and calling a function that worked for the touch_start() handler, or something like that.

You didn't understand the posting. llDetectedkey is for the touch event, and the comparison is made against the variable previously stored in the changed event.


Yes, you just did

That is how CHANGED_LINK works, every script with a changed event gets it, no matter where in the link set a prim (or avatar) is added or removed.

You will find that such scripts store the value of llAvatarOnSitTarget on each CHANGED_LINK, and compare against the value previously seen.

which means it need to check it's own stored on sit target versus an new call to that function, and only THEN pop a dialog if they are different.

SWIW I was thinking only the root and the originating prim got that changed event, but it makes sense that they'd all get it.

so the recap is.
on changed link, compare on sit target to stored value,
if different, set the new, and request permissions
when permissions are granted, pop a dialog

when touched, check stored value vs person touching, and pop a dialog for that person if they match


you can probably cheat instead of storing the av, simple check if there is a valid key sitting, if not release permissions and if so, check it against permissions, if no permissions, request them, if permissions exist, they didn't just sit down. then similarly filter touch versus the permissions key

generalized example

key gKeyAv;

default{
  changed( integer vBitChanges ){
     //-- did someone sit or get up?
    if (CHANGED_LINK & vBitChanges){
       //-- who is sitting on me
      key vKeyTest = llAvatarOnSitTarget();
       //-- has the seated Av changed??
      if (vKeyTest != gKeyAv){
         //-- testing just type key returns fals for null or invalid keys
        if (vKeyTest){
           //-- yay store our new av so we know they're there
          gKeyAv = vKeyTest;
           //-- get some permissions for this av!
          llGetPermissions( gKeyAv, PERMISSION_TRIGGER_ANIMATION );
        }else{
           //-- av got up, clear the stored value
          gKeyAv = "";
        }
      }
    }
  }

  run_time_permissions( integer vBitPerms ){
    //-- anim permissions are auto given for seated avs
    //-- trigger initial animation
    //-- trigger initial dialog for gKeyAv
  }

  touch_start( integer vIntCount ){
     //-- @-jump loops are faster and smaller
     //-- so is walking the testing backwards
    @loop;
      if (llDetectedKey( --vIntCount ) == gKeyAv){
        //-- pop dialog for gKeyAv
      }
    if (vIntCount) jump loop;
  }
}

I think permissions are preserved on state change, so you can still use a timer/state change to clear open listens on dialogs (which I didn't include in the example.) probably best to listen for the exact av, to avoid collisions. you can make a channel out of part of their key for uniqueness too (store a channel number when you store the key with this method)

Actually, I misread your post. Sorry!

Right, thanks!

Makes me wonder how the scripts that handle multiple avatars sitting on one prim work, but that's beyond the scope of the course.

multiple scripts, or just re request permission on ever change to permissions.... that has the bad side effect of needing to be stopped BEFORE the av gets up, or else they'll need an stop animation of their own, or have to be fed a permission dialog, which isn't as nice a scenario.

Sure, that much is obvious. I just wondered what llAvatarOnSitTarget() really does, if more than one av sits on a prim at a given time. My guess is it's the last to sit, and actually has nothing to do with "on sit target", but rather, is "last to sit on prim".

oh I see what you mean.... no actually it IS whoever is on the target offset, unless you move them off of it (important point)

the sequence there is is detect changed link, check if you have an av stored, if not check the sit target, if there's one there MOVE THEM to a position, and store their name. if you do have a stored AV and you're prim count is right for having two then when another av sits pas them off to the other script, which stores them. if it's the highest number of sitters allowed it DOESN'T move the av (and then the next change will put the av in the first position.

at least that's one way to do it (round robin)

1) You need to have the seats detect when someone sits on them, not just when a seat changes. There are a couple ways of doing this. The easiest is to keep track of who is on the seat and only doing anything when that changes, not just when the changed event is fired. This can be done by caching the seated users UUID.

2) Your second problem is easy to solve, just check the detected key against the user who is seated. If they match, generate the dialog.

Now in the bad old days you could get ghosted seated avatars; they would appear in the linkset but weren't actually there. The effect would be object damage. The solution was to make sure the seated user was in the sim and then if they weren't to unsit them.

still a problem with ghosted av's on vehicles that cross sim borders... unsit doesn't work, the prim gets locked into thinking there's an av there... only solution so far has been to rez a new seat after delinking the old.

They still haven't fixed that? delinking the old seat works? My solution into detecting that was to make sure the av was in the sim.

someone had the issue within the last week here on the forum... jira's still open AFAIK =\

Link?