Passenger Seating doesn't seem robust

[Wulfie Reanimator]

1 hour ago, Ample Clarity said:

Cheating a bit? I respectfully disagree. When you are done sitting, the "poseshell" deletes itself instantly and the furniture goes back to 1LI

 

It's impossible to reliably sit more than 1 avatar on 1 prim. My pose system rezzes an invisible shell which you sit on that has 1 prim per seated avatar. My bed sits 4 avatars but the shell is just 2LI (4 cubes linked together).

It's cheating in the sense that if your land has exactly 1 LI left, you can't rez and use any furniture from PrimPossible. You could if the shell was set to 'temporary,' but they didn't think that far.

 

Do you think anybody 99% of us here are saying it's possible to reliably sit more than 1 avatar on 1 prim?

[VirtualKitten]

3 hours ago, Love Zhaoying said:

See earlier posts in this thread (I brought it up, I think Wulfie clarified). UUID only should be used for "built-in" (system) anims. Names of anims in object inventory should be used otherwise.

So this was correct then i thought they stayed with the item is this no longer the case the UUID stays with it ?

[Qie Niangao]

45 minutes ago, VirtualKitten said:

So this was correct then i thought they stayed with the item is this no longer the case the UUID stays with it ?

I don't know who is saying these things, they're all confused. The problem isn't that animation UUIDs change, it's that animations simply cannot be invoked by UUID* and must instead be in the same link as the script that uses them.

I suspect this was a simple expedient for protecting the intellectual property of animators; in any case it's been this way for longer than I've been scripting.

____________
*with the very special exception of built-in animations, which can also be invoked by name, despite not being in the scripted link's inventory.

[Love Zhaoying]

13 minutes ago, Qie Niangao said:

I don't know who is saying these things, they're all confused. The problem isn't that animation UUIDs change, it's that animations simply cannot be invoked by UUID* and must instead be in the same link as the script that uses them.

I suspect this was a simple expedient for protecting the intellectual property of animators; in any case it's been this way for longer than I've been scripting.

____________
*with the very special exception of built-in animations, which can also be invoked by name, despite not being in the scripted link's inventory.

Sounds totally legit.  If someone told me "new UUID's were being assigned" is the reason I can't use UUID's (not the reasons we discussed previously), I would give them this..

[VirtualKitten]

I tried to move my anims to my inventory and get keys from them and removed them from my item . As soon as i restarted i got could not find animation error messages.Now clearly it will not get a UUID from your inventory for an anim any more .  I am sure i remember being able to do this ?

 

Now I can do this with images why cant you with animations ? Are there others you cant too?

Edited July 15, 2020 by VirtualKitten

[Love Zhaoying]

7 minutes ago, VirtualKitten said:

I tried to move my anims to my inventory and get keys from them and removed them from my item . As soon as i restarted i got could not find animation error messages.Now clearly it will not get a UUID from your inventory for an anim any more .  I am sure i remember being able to do this ?

 

Now I can do this with images why cant you with animations ? Are there others you cant too?

Don't use keys for animations from inventory, use "names" - period.

As for "why"..got any more cosmic questions you want answered while we are at it?

 

[Fenix Eldritch]

 

[Mollymews]

12 hours ago, VirtualKitten said:

I tried to move my anims to my inventory and get keys from them and removed them from my item . As soon as i restarted i got could not find animation error messages.Now clearly it will not get a UUID from your inventory for an anim any more .  I am sure i remember being able to do this ?

it has never been possible to use a key with llStartAnimation(string anim).  Where anim is a named animation in the same object inventory as the script

llStopAnimation accepts a key (uuid) or a name. The ability for llStopAnimation to accept a key is so that we can stop an animation that is playing on our avatar which was started by another process external to our script.  Animation keys which we can obtain with llGetAnimationList

 

the ability to use keys for textures is because of historical intent. When SL was first created there was this Linden idea that SL would be some kind of shared building experience with little to no monetary trade between the residents. It didn't take long for the residents to dissuade Linden of this

animations came some time later, by which time trading had become established. To facilitate trading then we got named animations. Each object had to have a copy of the animation in object inventory

Linden never regressed textures to be the same as animations, as this would have broken a lot of then current content which were scripted to use texture uuids

[VirtualKitten]

@Mollymews hmm i am confused and maybe I was doing it with art not animations . That said I am not sure how it protects intellectual animators property rights of animation as if its in the account of the rights owner how can this be more secure placing it in the item than in your own personal inventory. I can imagine this was done to cut traffic messages for key requests. and is more in line with OOP. 

I still have not had an answer from Firefox about the 'stand' browser button . It seems this can be pressed in world with no control from a user script behind it  .  I would like to take control of the exit and walk my passenger or primary seat avatar away. They tell me this problem is the same in the second life viewer too. I understand large physics are being employed to move avatars off seats which doesn't sound like a great idea. I thought changed event fired before the link/unlink but I am not sure it does now. Is there anyway of capturing this unlink so that I can make my avatar look nice standing and walking to a clear spot prior to the unlink .  

Edited July 16, 2020 by VirtualKitten

[Mollymews]

35 minutes ago, VirtualKitten said:

@Mollymews hmm i am confused and maybe I was doing it with art not animations . That said I am not sure how it protects intellectual animators property rights of animation as if its in the account of the rights owner how can this be more secure placing it in the item than in your own personal inventory. I can imagine this was done to cut traffic messages for key requests. and is more in line with OOP

we have llGetAnimationList() which returns a list of uuids playing on our avatar.  If we have the uuid and llStartAnimation(key uuid) then we wouldn't need a copy of the animation file to play the animation on our avatar

we could go to an animation shop, sit on the vendor, play the vendors animation(s), capture the animation uuid(s) with llGetAnimationList(). Code this uuid(s) into our own script and the animation(s) would play on our avatar

[VirtualKitten]

I have been reading this with a lack of hope of the criteria for animation requests. I have now a working single prim with seats stored in a Json SEAT_DATA record. This works perfectly with every different touch. It only becomes a problem when another avatar sits down and i need to change previous animated animater that may be laying on the item to sit up. Nothing I do will get this to work the llRequestpermissions is requested for the first avatar is not moved. I remember when writing a Dance Hud I needed a Server and Doll script. However this does not seem necessary if the hud is touched to change animations only if the script does it now this is a little strange as the criteria in  on WIKI bellow doesnt say this massive use of scripts is required  something LSL tells us t cut back on . 

Do I understand that the thing I am missing is STATE and i clearly need to set a different STATE before each Request ie Requesting a permission in one state, then changing state before the agent response, will cause run_time_permissions to be fired in the new state once the agent responds.
 

Caveats

• A dialog is presented to the agent to grant these permissions except when granted automatically as shown in the table above.
• If object is attached to agent, "automatic" permissions are granted without notification upon request.
• Permissions persist across state changes.
• Regardless of whether granting is automatic, you should always use the run_time_permissions event. Granting permissions takes time, and you shouldn't assume it's completed until the run_time_permissions handler gets invoked.
• The menu-option "Stop Animating Me" will release certain permissions (PERMISSION_TRIGGER_ANIMATION and PERMISSION_OVERRIDE_ANIMATIONS), if the script which holds these permissions is in the same region as the agent, and the script is not attached to the permission granter.
• Permissions do not accumulate.
  • If a permission was requested with a previous call to this function and granted, then in subsequent call was not requested, that permission is released (lost).
  • To request two or more permissions at the same time, use the bitwise OR (|) operator, e.g.:

    llRequestPermissions(AvatarID, PERMISSION_TAKE_CONTROLS | PERMISSION_TRIGGER_ANIMATION)

• Permissions are requested and granted separately for each script, even if they are located in the same object.
• It is currently not possible to request no permissions at all (see Issues below); as a workaround llResetScript can be used.
• Scripts may hold permissions for only one agent at a time. To hold permissions for multiple agents you must use more than one script.
• The result of granting permissions affects the return of llGetPermissions and llGetPermissionsKey immediately, despite the run_time_permissions event being queued, or dropped if the object's event queue is full.
• Permission request dialogs never time out.
• If a script makes two permission requests, whichever response is last is considered the granted permissions.
• The viewer limits permission requests from any agent to any other agent to 5 dialogs in 10 seconds.
• Permission requests and changing state ...
  • Requesting a permission in one state, then changing state before the agent response, will cause run_time_permissions to be fired in the new state once the agent responds.
  • Requesting only auto-granted permissions in one state, then immediately changing state, will never fire run_time_permissions.

[Profaitchikenz Haiku]

2 hours ago, VirtualKitten said:

It only becomes a problem when another avatar sits down and i need to change previous animated animater that may be laying on the item to sit up. Nothing I do will get this to work the llRequestpermissions is requested for the first avatar is not moved.

I'm sure I already answered this  See the two specific caveats you have posted, permissions persist across state changes, and a script can only hold permissions for a single avatar.

If you want to have several avatars on a single prim and animate each of them you need a second script for the second avatar, a third for the third sitter, and so on. For the second sitter, send a link message to the second sitter script giving the avatar key and name of animation to play. The second script must do the request permissions and start/stop animation for the second avatar.

The State change will not alter which avatar has currently got permissions held by the script, that remains unchanged until the avatar stands.

 

 

Edited July 20, 2020 by Profaitchikenz Haiku

[Qie Niangao]

I don't know what script is under consideration at this point, but technically it's possible to use a single script to control animations for multiple sitters but that script will need to be very careful about having permissions over the specific avatar on which it's manipulating animations, re-requesting it as needed if it's gotten permissions from the other sitter. All this can happen without needing to explicitly ask either sitter for permissions -- they're both sitting on the object, so the grant is implicit -- but the script must nonetheless make sure it has permission from the avatar it's animating at the moment. So, instead, almost everybody uses a separate script for each avatar -- it's much simpler.

You almost never need a separate state. They're mostly useful for turning off event handlers -- so, for example, the mouse cursor doesn't show a touch hand when there's no touch handler relevant. Otherwise, a state is just a fancy and exclusive alternative to testing the value of one global variable.

[VirtualKitten]

I have been reading this with a lack of hope of the criteria for animation requests. I have now a working single prim with seats stored in a Json SEAT_DATA record. This works perfectly with every different touch. It only becomes a problem when another avatar sits down and i need to change previous animated animater that may be laying on the item to sit up. Nothing I do will get this to work the llRequestpermissions is requested for the first avatar is not moved. I remember when writing a Dance Hud I needed a Server and Doll script. However this does not seem necessary if the hud is touched to change animations only if the script does it now this is a little strange as the criteria in  on WIKI bellow doesnt say this massive use of scripts is required  something LSL tells us t cut back on . 

Do I understand that the thing I am missing is STATE and i clearly need to set a different STATE before each Request ie Requesting a permission in one state, then changing state before the agent response, will cause run_time_permissions to be fired in the new state once the agent responds.
 

Caveats

• A dialog is presented to the agent to grant these permissions except when granted automatically as shown in the table above.
• If object is attached to agent, "automatic" permissions are granted without notification upon request.
• Permissions persist across state changes.
• Regardless of whether granting is automatic, you should always use the run_time_permissions event. Granting permissions takes time, and you shouldn't assume it's completed until the run_time_permissions handler gets invoked.
• The menu-option "Stop Animating Me" will release certain permissions (PERMISSION_TRIGGER_ANIMATION and PERMISSION_OVERRIDE_ANIMATIONS), if the script which holds these permissions is in the same region as the agent, and the script is not attached to the permission granter.
• Permissions do not accumulate.
  • If a permission was requested with a previous call to this function and granted, then in subsequent call was not requested, that permission is released (lost).
  • To request two or more permissions at the same time, use the bitwise OR (|) operator, e.g.:

    llRequestPermissions(AvatarID, PERMISSION_TAKE_CONTROLS | PERMISSION_TRIGGER_ANIMATION)

• Permissions are requested and granted separately for each script, even if they are located in the same object.
• It is currently not possible to request no permissions at all (see Issues below); as a workaround llResetScript can be used.
• Scripts may hold permissions for only one agent at a time. To hold permissions for multiple agents you must use more than one script.
• The result of granting permissions affects the return of llGetPermissions and llGetPermissionsKey immediately, despite the run_time_permissions event being queued, or dropped if the object's event queue is full.
• Permission request dialogs never time out.
• If a script makes two permission requests, whichever response is last is considered the granted permissions.
• The viewer limits permission requests from any agent to any other agent to 5 dialogs in 10 seconds.
• Permission requests and changing state ...
  • Requesting a permission in one state, then changing state before the agent response, will cause run_time_permissions to be fired in the new state once the agent responds.
  • Requesting only auto-granted permissions in one state, then immediately changing state, will never fire run_time_permissions.

[Profaitchikenz Haiku]

I'm not sure why you posted the same thing a second time, maybe you hope that we'll all suddenly go "Oh Ok, we've been having a laugh, actually all you need to do is..." but I'm afraid it isn't so.

However, I can suggest a line of investigation.

I read what Qie posted, and after sleeping on it, I am wondering if this is an issue with multi-sits, the first avatar gets the auto-granted permission because they sat, but what of the second and so on? Are they getting an auto-grant that over-rides the first one? Are they not getting an auto-grant because they are being added to a link-set instead of becoming a sitter?

Try this:

Inside run_time_permissions, as soon as you have tested for the required one being On, use llGetPermissionsKey and llKey2Name to see exactly who is about to be animated.

It might be the most recently-added sitter, it might always be the first sitter who actually claimed the sit target, but whoever it is, you need to know who is the intended target of the animation.

If it isn't who you were expecting it to be, then you need to look backwards through the sequence prior to any call that would cause run_time_permissions to occur and see what is being set up, or not.

 

Edited July 21, 2020 by Profaitchikenz Haiku

[Wulfie Reanimator]

2 hours ago, VirtualKitten said:

I have been reading this with a lack of hope

Me too. Me too...

[Qie Niangao]

3 hours ago, Profaitchikenz Haiku said:

I read what Qie posted, and after sleeping on it, I am wondering if this is an issue with multi-sits, the first avatar gets the auto-granted permission because they sat, but what of the second and so on? Are they getting an auto-grant that over-rides the first one? Are they not getting an auto-grant because they are being added to a link-set instead of becoming a sitter?

Maybe to clarify my wording with "implicit grant" of permissions: no agent seated on an object will see the permissions request, but also every one must be requested by the script, and a script always has permissions from only the one agent who most recently granted permissions (llGetPermissionsKey). Hence, if the same script is being used to animate multiple sitters, it will be calling llRequestPermissions over and over again to have current permissions from the agent it wants to animate at the moment.

[Profaitchikenz Haiku]

28 minutes ago, Qie Niangao said:

if the same script is being used to animate multiple sitters, it will be calling llRequestPermissions over and over again to have current permissions from the agent it wants to animate at the moment.

Looking at some of VK's code snippets (see thread Identified seating bug with running animations without a touched seat ) I do see calls to llRequestPermissions and have to say I can't see at first glance why there should be a problem, that is why I suggested adding a diagnostic inside run_time_permissions. This could be a timing thing, of course,  except that RTP will occur as a result of llRequestPermissions and so it's hard to see how it could have the wrong avatar key when it gets to work.

Really out on a limb here but supposing the script has permissions for agent-1, then it has a perms request for agent-2 , so it queues RTP, but it hasn't finished changing the stored key of the agent it last held permissions for by the time RTP actually gets to see what it's meant to be doing?

The other trunk-hugging possibility though, is that there might be an issue with the key returned from the Json for the seats, or there is more than one point in the code where the call to request perms is being made and it is not using the expected key.

Edited July 21, 2020 by Profaitchikenz Haiku

[Kyrah Abattoir]

The more I read this topic the more I start to think about the Dunning-Kruger effect.

[Profaitchikenz Haiku]

It's a fair cop guv, you got me bang to rights

 

[Love Zhaoying]

3 hours ago, Profaitchikenz Haiku said:

It's a fair cop guv, you got me bang to rights

 

 

[Love Zhaoying]

4 hours ago, Kyrah Abattoir said:

The more I read this topic the more I start to think about the Dunning-Kruger effect.

Every. Post.!

[Love Zhaoying]

4 hours ago, Kyrah Abattoir said:

The more I read this topic the more I start to think about the Dunning-Kruger effect.

Every. Post.!

[Love Zhaoying]

11 hours ago, Profaitchikenz Haiku said:

Looking at some of VK's code snippets (see thread Identified seating bug with running animations without a touched seat )

I dun know because can't read past this 

[Mollymews]

about the one script multi-sitter I posted an example of this here