When is LL going to fix the llSetPos sit bug?

I was hoping a developer could answer when (and if it's a priority) the sit bug for llSetPos and llSetPrimParams would be fixed?

I've bugged this a few times, and followed up in the Linden Answers a while back.

The bug is that llSetPos and llSetPrimParams does not move a person sitting on a linked prim. Since a person is moved when the entire object is llSetPos, it stands to reason that the behavior should be that an avatar sitting on a prim should be moved with that prim.

Currently, there is no way to move an avatar while sitting on a child prim.

Hiro - shouldn't this read "Currently, there is no way to move an avatar while sitting on a child prim?"?

If not, stop by the Shelter when you get a chance. Our 'Elevator' there uses Sit & llSetPos() to move an avatar to the destination of choice.

Granted, the whole object is being moved (its 1 prim), not a child object.

I think i can tell what Hiro meant, as i petitioned that as bug allready multiple times

Lets go step by step :

When youre sitting on an unlinked Prim, youre position is changed with that prim if youre moving that single prim, right ?

Now lets say that prim is an Poseball on an Couch ( and the poseball isnt the root ),
if you move the poseball in the linked set ( without moving the entire couch ), wouldnt you think youre position should move with the prim youre sitting on ?

Now .. SL behaves differently, youre not moved, youre position would only change to the accurat position by standing up and sitting down again !

For that reason, we think this is an bug and should be changed

If you think of the av as simply becoming another prim in the linkset it makes sense. It's not linked to the prim, it's linked to the linkset as a whole.

That does bring up the question... do you really need a separate prim for each sit pos on something like a vehicle where the seats are typically loaded sequentially. Can you just have three or four scripts in the root prim and have each script holding the animation permissions for a different av?

Regardless of your mindset, the problem is that AVs aren't really treated like full linked prims. They are seperate cases. You can't send link messages to them, you can't edit them with scripts, etc.

Now there's no way to move an avatar in relationship to the rest of the linked set. This kind of functionality would mean a lot for vehicle, furniture, and game builders.

I consider it a bug rather than a feature because of the nature of what we call the action - "sit". It's not "link". It's "sit". So if it's "sit", then it should behave like a "sit", which would mean that if you move the linked child prim that an avatar is sitting on, you move the avatar with it.

Hehe agreed it seems like a bug. All I meant to question was Hiro's statement that "Currently, there is no way to move an avatar while sitting."

I think I understand what he meant too.... but just to be sure, I'd had to ask

In the same vein, changing the llSetTarget's position or rotation while an avatar is sitting on it will not update the avatar's position. So while you could change an avatar's pose animation in a chair, you can not change the position that animation should play to match. Very unfortunate.

Yes, that would be very valuable as well, and perhaps as an alternate fix?

Well, you can send link messages to them, they just don't hear them.

In the absence of hierarchical linking (which is what you really need to fix this... and, yes, you really do), it'd be nice to be able to call llGetLinkNumberOfSitPoint and llSetLinkPos. Actually, llSetLinkPos would be real handy for all kinds of reasons...

That's because what you're doing there is setting a new Sit Target, not moving an old one.

The other thing that would solve this would be to have llSetAnimationOffset(vector position, rotation rotation);, which would effect the displayed position of the avatar that you currently have animation permissions for.

Argent, two more good suggestions.

Another I'd like with heirearchical / tree-based linking:
llSetBranchPos and llSetBranchRot
that act on a link and all linked pieces

No, not "llSetBranch" anything. hierarchical links shoudn't change the "objectness" of the tree.

llSetAttachPoint(vector position, rotation rot)
llAttachLinkset(key id)
llAttachToLinkset(key id, integer attachpoint)

Then you can attach a new object to the "attach point". It moves with and as part of the linkset, but it's not actually linked in with it. The root prim will see its link number as something special, probably a negative number (-1 for first attach point) and only the root prim can act as a member of the parent linkset for link messages, getRoot*, setLocal*, and so on. The rest of the linkset doesn't even know it's attached.

Attach would not require mod rights, because it wouldn't modify the linksets at all.

Attached objects could be "phantom" without the parent object being "phantom", but if the parent object is physical they would be treated as being part of the same physical object just like they were attached to an avatar sitting on it.

This would provide a lot of the functionality of joints, too, but without the physics engine being involved it wouldn't load the system down. Plus it'd let people effectively create extra attachment points.

In your case, you'd just attach a poseball. When you sit on it, you and the poseball are one linkset, and when the poseball moves, you'd move.

I'd still like an official Linden response on whether the original bug can become a priority to be fixed.

Argent, you bring up several good points. The basic crutch is that adding heirarchical linking (link your armchair and ottoman together, but unlinking them doesn't reduce them to their component prims... you are left with the two original linked objects instead) is that major changes to permissions would have to be done at the same time.

But if permissions would have a major change at the same time, how about this: Several types of link permission. You mentioned one, Attach, that wouldn't require mod rights in the current system of permissions. In a more advanced world, the Modify right can be expanded into greater detail. Such as:

1. Modify
   1. Texturing
      1. Texture
         
      2. UV Coords
         
      3. Color
         
      4. Properties
         
      
      
   2. Scaling
      
   3. Linking
      1. Link
         
      2. Unlink
         
      3. Position
         
      4. Rotation
         
      5. Script Communication
         
      6. Physics
         
      7. Phantom
         
      
      
   
   
2. (etc)
   

This way you could toggle Modify all-on or all-off to have the same behavior as today, or you can expand it and dig down to individual action permissions. If, in the Linking section, only Link, Unlink, and Position were enabled, then I could link my ottoman to my armchair and when I moved the chair it would follow. But if I rotated the chair, the ottoman would not change position relative to the chair's center. Nor would link messages in the armchair, for when you bring the footrest up, be heard by the ottoman since Script Communication would be off. And if either the armchair or ottoman were set physical or phantom, the other would be unaffected. (For physical, this would have the effect of pinning a physical object to one spot (if positions were linked) and one rotation (if rotations were linked).

If only Link, Unlinked, and Script Communication are checked, then I could link a whole set of furniture together and be able to position them however I like (within normal linking ranges) in my house. I could take them to inventory as a single unit, and they could use link messages to communicate.

Of course, this is top-o-my-head stuff here, and would obviously be a MASSIVE change.

The need to just move an avatar that's sitting on an object is one that would be much easier to meet in the near term.