Passenger Seating doesn't seem robust

[Love Zhaoying]

30 minutes ago, VirtualKitten said:

you maybe missing the point my same script worked in a 64x64 mega prim 

Just because it works in a mega-prim doesn't mean it will work in your (much smaller) mesh piano bench.

[Love Zhaoying]

11 minutes ago, Qie Niangao said:

Set it to physics type PRIM and remove all scripts, then add one that clears the sit target (sets it to ZERO_VECTOR, ZERO_ROTATION). You'll probably be able to seat two avatars on it, if the sit gestures are reasonably well-placed.

This is not a viable product, though, because people put their furniture next to other furniture with weird physics, inside houses with weird physics, surrounded by huge sculpted terrain with weird physics, so those people will forever have trouble with any product that doesn't provide a sit target for each seat.

Plus..the piano + bench probably depends on scripts in the bench to run when the "piano player" avatar sits. So, removing scripts is a proof-of-concept only. 

[Profaitchikenz Haiku]

1 hour ago, Qie Niangao said:

(In case it's not clear already: setting a sit target inside the same link multiple times NEVER generates multiple sit targets. It only moves the existing sit target and then it will only apply the next time some avatar is the first sitter on that link.)

In passing, while I was reading up on sit targets yesterday I spotted an LSL function to UPDATE a sit target which apparently worked even if it was being sat upon. Once I've got out of this serbonial mess that is prim-sittability I shall look further

 

I am still trying to grasp the changes that have occurred sometime in the past three years. It now seems you can sit on any prim if it has physics type PRIM, where previously I believed you had to actually give the prim a sit target. It also seems that you can clear the sit target in a prim but what then happens is that you now sit on the prim in the default position. To stop a prim being sittable-upon you either have to give it the scripted-sit-only prim property or you have to set physics to none. So it seems the order of sitting priority is

If it has the prim property Scripted_sit_only TRUE && it has a script to sit an avatar on it, sit via script

otherwise

If is is a Prim and has a sit target, use the sit target

If it is a prim and has no sit target or a zero sit-target, use the default sit position for a prim (which I believe might be equivalent to a cleared sit target?)

If it is physics none and has a sit target non-Zero, use the sit target

If it is physics none and has no sit target or a zero sit-target, no room to sit

 

Going back to the OP's problem I am wondering therefore if parts of the build have no physics.

 

Sitting should only be a pain in the backside if there happens to be a protuberance.

[VirtualKitten]

On 7/12/2020 at 5:35 AM, VirtualKitten said:

Well it works fine https://gyazo.com/71a66fbc4996b346575439475c8aa84c so there is plenty of room with two prims  please  video  The work around is not what was working in 2015 what you are suggesting is that all single prim furniture will no longer work  that you can sit on  does this include every thing Prim Possible has made?

@Qie Niangao there is no weird physics that you speak of near this bench . I have also proved to Prof this by placing a prim linked to the seat in the position the next seat is at and this worked as a linked set in the house in same place and position . You may have missed this in the posts above  but it was clear from this as bench could be sat on in the video that there was no problem seating in that vicinity other than on a single prim with one seat  and the dodgy  method of detecting subsequent seats employed by LSL that is  more akin to picking a card from a deck of cards. Please see video above or here https://gyazo.com/71a66fbc4996b346575439475c8aa84c  for proof with two links there is no such physics problem. D

[KT Kingsley]

6 minutes ago, Profaitchikenz Haiku said:

In passing, while I was reading up on sit targets yesterday I spotted an LSL function to UPDATE a sit target which apparently worked even if it was being sat upon. Once I've got out of this serbonial mess that is prim-sittability I shall look further

I guess you're talking about Strife Onizuka's Update(Link)SitTarget function. That updates the sit target using llSitTarget and then moves the avatar using llSetLinkPrimitiveParamsFast. The parameters passed to SLPPF are tweaked using the llGetAgentSize values to more accurately reflect the sit position produced by llSitTarget, which is subtly different to that produced by using PRIM_POS_LOCAL in SLPPF.

[VirtualKitten]

1 hour ago, Love Zhaoying said:

Plus..the piano + bench probably depends on scripts in the bench to run when the "piano player" avatar sits. So, removing scripts is a proof-of-concept only. 

Love, I think your only reading what you write. The Mega prim was proof of concept of the lSL Script working by copying it to a mega prim the script functioned seating two people. Surely i d o not need to explain this further as if i do you should not be really commenting 

There is no weird physics that you speak of near this bench . I have also proved to Prof this by placing a prim linked to the seat in the position the next seat is at and this worked as a linked set in the house in same place and position . You may have missed this in the posts above  but it was clear from this as bench could be sat on in the video that there was no problem seating in that vicinity other than on a single prim with one seat  and the dodgy  method of detecting subsequent seats employed by LSL that is  more akin to picking a card from a deck of cards. Please see video above or here https://gyazo.com/71a66fbc4996b346575439475c8aa84c  for proof with two links there is no such physics problem. D

 

[Wulfie Reanimator]

People need to stop confusing (or vaguely describing) user-functions written by other people with actual LSL functions. These are very distinctly different things, presented in a very different way on the wiki.

[VirtualKitten]

7 minutes ago, KT Kingsley said:

I guess you're talking about Strife Onizuka's Update(Link)SitTarget function. That updates the sit target using llSitTarget and then moves the avatar using llSetLinkPrimitiveParamsFast. The parameters passed to SLPPF are tweaked using the llGetAgentSize values to more accurately reflect the sit position produced by llSitTarget, which is subtly different to that produced by using PRIM_POS_LOCAL in SLPPF.

KT, I didn't write the great  script on wiki, which i point out works on a mega prim correctly , thus proving the LSL script is functional as it was intended to provide multiple seats on a single prim which it does if its 64mx64mx1.5m in size! As i said to Kie there is no phystics problem sin the area sth the linked version works in exactly same placement.

The Mega prim was proof of concept of the lSL Script working by copying it to a mega prim the script functioned seating two people. Surely i d o not need to explain this further as if i do you should not be really commenting 

There is no weird physics that you speak of near this bench . I have also proved to Prof this by placing a prim linked to the seat in the position the next seat is at and this worked as a linked set in the house in same place and position . You may have missed this in the posts above  but it was clear from this as bench could be sat on in the video that there was no problem seating in that vicinity other than on a single prim with one seat  and the dodgy  method of detecting subsequent seats employed by LSL that is  more akin to picking a card from a deck of cards. Please see video above or here https://gyazo.com/71a66fbc4996b346575439475c8aa84c  for proof with two links there is no such physics problem. D

Edited July 13, 2020 by VirtualKitten
Added more text as people are not reading the thread

[VirtualKitten]

59 minutes ago, Profaitchikenz Haiku said:

In passing, while I was reading up on sit targets yesterday I spotted an LSL function to UPDATE a sit target which apparently worked even if it was being sat upon. Once I've got out of this serbonial mess that is prim-sittability I shall look further

 

 

Yes Prof, i noticed that the UPDATE the  code in state change is different it now pre-processes before the sit and link or at least it did in my change causing the animation problem as I had placed a key check at the start  to check size of avatar  to check for non avatar. As the key was returned as NULL_KEY the sit had not occurred at the time of the change event this is different from about three days ago  when it was post the link. I removed my Avatar size check with the NULL _KEY  and it worked again  with the animation however this was only for single eat as i have not tried someone else  as passenger on it yet

 

I have to wonder what else it changed do you have a list of changes prof?

Edited July 13, 2020 by VirtualKitten
NA

[KT Kingsley]

29 minutes ago, VirtualKitten said:

KT, I didn't write the great  script on wiki, which i point out works on a mega prim correctly , thus proving the LSL script is functional as it was intended to provide multiple seats on a single prim which it does if its 64mx64mx1.5m in size! As i said to Kie there is no phystics problem sin the area sth the linked version works in exactly same placement.

The Mega prim was proof of concept of the lSL Script working by copying it to a mega prim the script functioned seating two people. Surely i d o not need to explain this further as if i do you should not be really commenting 

There is no weird physics that you speak of near this bench . I have also proved to Prof this by placing a prim linked to the seat in the position the next seat is at and this worked as a linked set in the house in same place and position . You may have missed this in the posts above  but it was clear from this as bench could be sat on in the video that there was no problem seating in that vicinity other than on a single prim with one seat  and the dodgy  method of detecting subsequent seats employed by LSL that is  more akin to picking a card from a deck of cards. Please see video above or here https://gyazo.com/71a66fbc4996b346575439475c8aa84c  for proof with two links there is no such physics problem. D

The post of mine was a response to Profaitchikenz Haiku, who mentioned an update function for sit targets that they might want to investigate at some time. I summarised what it does. And I attributed the function to it's author, Strife Onizuka.

[VirtualKitten]

6 minutes ago, KT Kingsley said:

The post of mine was a response to Profaitchikenz Haiku, who mentioned an update function for sit targets that they might want to investigate at some time. I summarized what it does. And I attributed the function to it's author, Strife Onizuka.

That is stranger then as this update happened with a state: change  over the weekend  I noticed it when Prof asked me to add a linked seat. It was noticeable  through my animation code but as i was testing for a linked prim being not a avatar  as follows:

key agent  = llAvatarOnSitTarget();

if(llGetAgentSize(avi) != ZERO_VECTOR) {

It seems state: change has been altered to pre-process a sit or link and llAvatarOnSitTarget(); returns NULL_KEY until a few cycle occurs when it can be located in another part of the code :

list getFreeSeat()
{
    avatarCheck=[];
    sittingAvis=[];
    i=llGetNumberOfPrims();
    //get current avatars on seat
    key agent =  llAvatarOnSitTarget();

Here above were it is successful. This was ok before last week so it seems something has been changed as an UPDATE

[Profaitchikenz Haiku]

It's amazing we're still here....

I might not be able to illustrate my final (Yes, there will be no more on this matter) investigations, but I decided it was necessary to simplify things to the basics.

The OP wants to sit two avatars on a particular object. Many of us have said things like "It's not big enough" or "there's no room".

So I decided to see if you could sit two people side by side on a small piano stool, both a prim and a mesh one. After all, if the simulator says you can't do it, no script on earth that runs on that simulator is going to be able to do it.

So I started with a prim the size of the intended piano stool, 0.3 x 0.6 x 0.5. In the picture the meshed stool is in the middle with the 

prim assembly from which it was made outside.

 

Two avatars at on it without even needed a script to give it a sit target. I used a script to make the default position to one side of the bench. Two avatars still sat on it.

I made up a prim piano stool and converted it to mesh, giving it a LOW level of detail in the upload and upping the triangle counts a bit but I didn't really care about triangular-degeneration. 0.5LI and L$11 as it's just a Proof-of-misconception

Two avatars could sit on it side by side even without a sit-target, I gave it one anyway.

 

 

The physics shapes of the prim, the mesh stool and the prim assembly look like this.

 

 

My conclusions therefore are that the OP's problem lies in the mesh object(s) they are trying to work with, since they already have proved the script they want to use works in a mega-prim. They went large, I went small, but the upshot is still the same, the object is the cause of the problem, not the script, nor the server code. In order to be able to sit one or more avatars on an object by a script, you must first be able to sit one or more avatars on the object, full-stop.

 

It is finished -

It is finished

It is the mercy

 

Phew

 

Can we get up now? I've got splinters in my backside.

Edited July 13, 2020 by Profaitchikenz Haiku

[VirtualKitten]

Hi Prof gives you some splinter cream I sent you my mesh object so you can put your script in it and let us have an outcome as you seem to think this is the object,. it has my script in it 

 

[VirtualKitten]

I had a very helpful gentleman around to my house in a top hat and looked very smart he showed me what was wrong and I need to  face up and take the blame apologizing even though  it is a mystery to me. I have an object around my house Y.B skybox mesh 64x64 Qezha REZZER bought from MP it seems this has been creating a physics around my house that  is stopping my bench seat seating two . This is very weird as my sofa and bed and other chairs can all seat two whilst in this physics skybox  removing it solved the problem  and i think i need to apologize to Wulfie , KT Kingsley, Kia  et all as this has been caused by @YB (yony.bing)  Y.B skybox mesh 64x64 Qezha REZZER object not LSL. However I do also believe there has been an update to LSL too so it cannot be that bad if we all achieved that I want to thank you all for your help especially the Prof . I will be asking YB why this is sold as a sky box and perhaps someone can shed a light on why this is a problem for just my scripts and a can accommodate other seating products , Kisses Denise

 

 

[Qie Niangao]

8 hours ago, VirtualKitten said:

[...] Prof I used your two link trick now my animations cant be found when this was working on seat one organically.Do I understand that you now cannot use animations as they are in root and cannot be located by child prim . This is becoming ridiculous I add as if you are suggesting these need to be duplicated in tho the child rim then honestly I have this is becoming fascicle.  And a self pontificating  denial that this should all work in 1 link. which then stops stupid duplication of the animations and other items needed to run the script.  [...]

This is from a ways back, but it occurred to me that there may be a subtlety not fully communicated about how animations work in multi-sit furniture. It's not necessary for the animations themselves to be inside the link on which the sitter is to be animated. It is, however, necessary that they be in the same linked object on which the sitter is seated in order to avoid getting an explicit request for permissions.

In the old days, there was a common multi-pose system called MLP that instead sat the sitters on animationless poseballs that talked to the main furniture item that held all the animations. With that system, every new sitter had to explicitly approve PERMISSION_TRIGGER_ANIMATION afresh, because it wasn't coming from the object on which they were directly sitting. Now, instead of those poseball seats, we can move seated avatars around on the object as just another link, and animate them without their needing to explicitly approve anything. There are several open source systems that do this including nPose and AVsitter.

(Something I said about Prim Possible's approach might have added to the confusion. I noted that they'd need to use copy-permission animations because they were contained and used in the rezzed-on-demand "shell" object, rather than in the persistent furniture mesh. That's true, but it may have left the mistaken impression that the animations were copied into every sit-targeted link of that shell object, which isn't the case.)

Edited July 13, 2020 by Qie Niangao

[Love Zhaoying]

22 minutes ago, Qie Niangao said:

It's not necessary for the animations themselves to be inside the link on which the sitter is to be animated. It is, however, necessary that they be in the same linked object on which the sitter is seated in order to avoid getting an explicit request for permissions.

They don't need to be in the same "object" (whether link or prim) as the script? Unless using UUID's, scripts can only see animations in the script's link's inventories, last I recall.

[Wulfie Reanimator]

19 minutes ago, Love Zhaoying said:

They don't need to be in the same "object" (whether link or prim) as the script? Unless using UUID's, scripts can only see animations in the script's link's inventories, last I recall.

Animations cannot normally be started by UUID. The viewer-built-in animations are the only exception.

What Qie is saying is that if you want to avoid the permission request, the avatar needs be part of the same linkset as the script. Scripts can still animate avatars who aren't in the same linkset, but the permission-request will be visible to them.

Edited July 13, 2020 by Wulfie Reanimator

[Love Zhaoying]

20 minutes ago, Wulfie Reanimator said:

Animations cannot normally be started by UUID. The viewer-built-in animations are the only exception.

What Qie is saying is that if you want to avoid the permission request, the avatar needs be part of the same linkset as the script. Scripts can still animate avatars who aren't in the same linkset, but the permission-request will be visible to them.

Thanks, but I was responding more to the OP's comment that the animations were "gone" (I cannot find the quote now, perhaps it was edited away).

[Qie Niangao]

1 hour ago, Love Zhaoying said:

Thanks, but I was responding more to the OP's comment that the animations were "gone" (I cannot find the quote now, perhaps it was edited away).

Ah. Perhaps this? (emphasis mine) :

10 hours ago, VirtualKitten said:

I have to agree with your original testing  1-15 analysis posted 15 hours ago , Prof but some sits are broken the reason is was defined by wulfie . The first sit is taken up and then the system is supposed to go off and use the old seating system model to find a seat . It doesn't and reports a simple message looking like its lazy coding . The seat according to Wulfie is not ever released until you unsit . Further more if you set the seat to zero the seat is removed and the menu option is also removed and no seating can occur. In additions to this adding a second third or sixth link to facilitate 6 seats is ridiculous as he system will loose the animations creating more wasted resources in the same link-set. D [...]

... which I admit I didn't really understand. But anyway you're certainly correct that the script that calls llStartAnimation() must be in the very same link as the animation it starts... and (as Wulfie correctly interpreted my ramblings), the to-be-animated avatar only needs to be seated somewhere on the same object (linkset) to avoid an explicit permissions request dialog.

[Love Zhaoying]

19 minutes ago, Qie Niangao said:

Ah. Perhaps this? (emphasis mine) :

... which I admit I didn't really understand. But anyway you're certainly correct that the script that calls llStartAnimation() must be in the very same link as the animation it starts... and (as Wulfie correctly interpreted my ramblings), the to-be-animated avatar only needs to be seated somewhere on the same object (linkset) to avoid an explicit permissions request dialog.

You got it, I was trying to interpret the "loose" of animations. 

[Mollymews]

7 hours ago, VirtualKitten said:

I had a very helpful gentleman around to my house in a top hat and looked very smart he showed me what was wrong and I need to  face up and take the blame apologizing even though  it is a mystery to me. I have an object around my house ... bought from MP it seems this has been creating a physics around my house that  is stopping my bench seat seating two . This is very weird as my sofa and bed and other chairs can all seat two whilst in this physics skybox

is good that you found what was causing you issues

just about the other sofa, bed and chairs.  They will have sit targets in them, one for each sitter. So they will work.  In your case you were attempting to sit more than one avatar on the same "prim".  Which we can do but only when each sitter can actually right-click on the "prim"

[VirtualKitten]

Yes Molly thanks for the update that makes more sense. 

The physics was just half of the problem but immediately made a difference to the functionality  I feel a bit silly about this as my assumption was that this was bought from MP that  item would not do this but the very nice man in a top hat showed me another in my house:).

I also now realise my script at top of this thread would not have worked .The reason for this was I had an unreal expectancy of what Linden was providing especially in regard to unlinking passengers in respect to  llAvatarOnSitTarget();. 

This  would not have worked as I expected:

  if(agent==NULL_KEY) {
             
                // Stop Got Up
                agent = Check_4_KeyNot_Linked();

              // .. do something

I replaced this first line with my own version   if(Check_4_KeyNot_Linked()!=NULL_KEY) { from the code i gave up the top I  changed to return variable  "i" rather than the "key". and made a separate routine. To explain as the agent is NULL for a unlink or unseat this didn't get  run. In fact I removed  llAvatarOnSitTarget(); in its entirety as it was really not helpful in providing the three pieces of data that the unlink section required to work with the json seat.

I also changed this at the start of state change  from key agent  = llAvatarOnSitTarget();to  key agent  = llGetLinkKey(llGetNumberOfPrims());

This said the Wiki Json  Multi script did not seem to clear down the data from an avatar replacing it with data from an avatar already seated in my unlink section i had to add  

i = Line_Check_4_LastKeyNot_Linked();
SEATS_data = llJsonSetValue(SEATS_data,["seat"+(string) i,"key"],"empty");

So that this was cleared on unsit to get the data set to work properly . I really think this page needs some additional work on wiki 

It certainly has been an interesting topic I want to thank everyone as I have also learned some things on the way too.

*Hugs*

D

[VirtualKitten]

20 hours ago, Love Zhaoying said:

Thanks, but I was responding more to the OP's comment that the animations were "gone" (I cannot find the quote now, perhaps it was edited away).

Thanks for your addition to this discussion Love , but just to clarify something I was told in a scripting group  in world in regard to UUID. I was told I could no longer rely on UUID being valid as they get re-assigned . I had to use names instead this means i have to put my animations in my build not in my inventory and use UUID. Is this correct or have you heard this being said.

[Ample Clarity]

On 7/11/2020 at 10:31 PM, Wulfie Reanimator said:

Elementary, my dear Watson. But you must not have any other objects too close to the seat. Your piano is too close.

In the first picture I showed, the table and chair are all one mesh object, not a linkset. But you must touch the object before you can sit, which causes it to rez a new object, which is a linkset with enough links to seat all intended avatars. That rezzed object is more than 1 LI, so PrimPossible is "cheating" a bit.

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).

Edited July 15, 2020 by Ample Clarity

[Love Zhaoying]

19 hours ago, VirtualKitten said:

Thanks for your addition to this discussion Love , but just to clarify something I was told in a scripting group  in world in regard to UUID. I was told I could no longer rely on UUID being valid as they get re-assigned . I had to use names instead this means i have to put my animations in my build not in my inventory and use UUID. Is this correct or have you heard this being 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.