Passenger Seating doesn't seem robust

[VirtualKitten]

The link i showed you from wiki said its possible even if there a few workable problems with the script the premise was that it should now something has been changed passenger seating is no longer robust. The problem is not the script Prof LSL stops the script running saying there is no room

[Qie Niangao]

16 minutes ago, VirtualKitten said:

I have modified the JSON multi-seat on wiki http://wiki.secondlife.com/wiki/Json_multi_sit_array to work and have animations but it does not  multi-seat anymore I think something has changed in LSL to provide a non robust seating problem.even with it sees PrimPossible table and chairs.

No. We understand how PrimPossible stuff works now, Wulfie showed us (and I snuck in world earlier, too, but was too lazy to report). Those objects use the simplest workaround: just rez whole separate structures to sit on with enough links for each to-be-seated avatar. That's okay, but it's super basic and well understood.

I don't know who this "fox" is you keep talking about. If they've got something to contribute, get them posting here.

Until Wulfie said otherwise, I'd thought having a sit target made it impossible to seat more than one on that link, but apparently it's still possible, if you clear them far enough out of the way of each other. But I have to say, this is going to be incredibly tricky, and sitters are going to frequently get that error, as long as they're not actually using a sit target (which as far as I know, they can't, once the link's sit target has been occupied).

One trick that used to improve the odds (for no-sit-target seating) was to cam in tight to the prim and execute the "sit" operation directly on the FRONT surface, kinda between the knees of where the avatar would end up sitting. These were usually just simple box prims, but I'd strongly recommend you get whatever you're trying to do working first on the simplest possible prim structure before even thinking about trying it on any mesh object.

[Wulfie Reanimator]

Alright my dudes and dudettes, it's illustration time.

Let's continue with my example of a tiny cube, with a sit-target one meter above it.

When an avatar selects the "sit" option, a request is sent from the viewer to the sim.

Because the object has a free sit-target, an avatar can always sit here, even though the blue box is actually occupying that space and would normally prevent sitting.

Now another avatar wants to sit on the same object. Since the sit-target is already occupied, that cannot be used. Instead, the sim will now use the old method of "try to find the closest suitable surface to sit on." If I right-click on the back-edge of the prim, this is where the check happens:

Here, keep in mind that the blue box is a real object, with its own (identical) physics shape. The red box is the new physics-shape being checked by the sim, and clearly it overlaps with the blue box, so you will get "No room to sit here" and the viewer will not complete the sit-action. All of this happens before the script even becomes aware that someone is trying to sit on the object.

If I move both boxes out of the way so the sit-action can complete, the avatar that is already sitting and technically occupying the space above the second one seems to be ignored because it's on a sit-target. (And for illustration purposes I've moved the red box back into place after the sit has succeeded.)

The point I am making here is that you can have multiple avatars sitting on a single object. You can even have multiple avatars sitting on a single object which has a sit-target. But any avatar after the first will not be placed on the sit-target, but rather gets placed "normally" as if there was no sit-target at all, which is subject to physics-checks and can fail.

It's easy to conclude that "you can reset the sit-target to allow multiple avatars using the sit-target of a single object," but that's not what's actually happening. If you check llAvatarOnSitTarget, you will always get the avatar who sat when the sit-target was free.

Also, if you were to move the first avatar 3 meters forward (for example), the second avatar would still be subject to physics-checks around the original location of the object, not where they would be placed after they have already become part of the linkset.

Edited July 11, 2020 by Wulfie Reanimator

[Profaitchikenz Haiku]

Just to expand a little on my previous post, the sit-target of a prim has two important purposes. The first is obvious, where to place the avatar when it sits on the prim. The second is where to position the avatar when it stands. (Remember those TP pads where the sit target is way off from the prim and you simply unsit the sitter as soon as they're comfortable?)

Take a single prim, smaller than the size which actually allows two avatars to sit on it. Give it a sit-target, possibly in the middle of the prim but 0.4 m above the prim centre.

When an avatar clicks on the prim and selects sit, changed_link occurs.

Inside changed link, check the number of prims. If greater than last time, somebody has sat down (or a prim has been linked). If less, somebody has stood up (or a prim has been removed).

If prim-count greater, alter the prim local pos and rot of the most recently added child. Assuming it's an avatar, it will then be moved to the desired seating spot. If it wasn't, you've just mucked up your build but never mind, you've got a backup?

When a second avatar clicks and sits, repeat that procedure, choosing a different local pos and rot.

Note that when two or more avatars are sitting on the prim, llAvatarOnSitTarget won't update for the new arrivals. There is no need to amend the sit target, since it is only being used once when an avatar first clicks to sit, and again when they decide to stand.

The complexity of the script is in managing the details of how many prims are in the linkset now and prior to the changed link, which of the children are avatars, where the next free seat position is to be (1 2 and 3 are seated, 4 is the next spot but what if 2 gets up?)

I still don't understand all of what is occurring with bounding boxes, physics shapes, etc, but I anticipate see Wulfie will be  has been along soon with the answers @)

Edited July 11, 2020 by Profaitchikenz Haiku

[VirtualKitten]

Wulfie . I am not sure I follow what is the blue and red box supposed to represent  as they are not the physics or bounding box of the cube you are trying to sit on . You also miss the point that a second llLinkSitTarget( can be set so you should be able to have another seat so the system should not revert to any old method like you indicated but to the bnew seat created by  llLinkSitTarget( unless of course  llLinkSitTarget( does nothing to set a seat once the seat is taken up  up by llSitTartget(. IF this is the case this would be od as by the very fact that a link has been added to the seat it becomes a LINK_SET not a prim  therefore i would expect a llLinkSitTarget( to define a new seat in the LINK_SET. As we are aware this doesn't happen in practice and you get a silly message stating "No Room to sit , try another spot" is generated.  I presume then passenger seating is not robust and the code on wiki is redundant as the SERVER updates have rendered it unworkable as per the demonstration you gave of PrimPossible furniture.

 

I have to agree with @Profaitchikenz as he has the same questions  in his messages about the boxes.  llAvatarOnSitTarget  will not only work in the instance of the sit  and does not detect there after if someone has got up . I had to write a routine to do this from the JSON  seat Object as below:

key  Check_4_KeyNot_Linked() {
  integer j = llGetNumberOfPrims();
  list seated=[];
  j = llGetNumberOfPrims();
  for(; j--;) { if(llGetAgentSize(llGetLinkKey(j+1)) != ZERO_VECTOR) seated += [llGetLinkKey(j+1)]; }
  integer i = num_seats;
  for(;i--;) {
       avi = llJsonGetValue(SEATS_data,["seat"+(string)i,"key"]);
       if(avi!="empty" && llListFindList(seated,[(key)avi])==-1 ) return avi;
    } 
    return NULL_KEY;  
}

This returns the missing  avatar key from the seat object JSON  when an avatar that just got up currently  llAvatarOnSitTarget  returns NULLKEY to demonstrate something has occurred as it does when it holds a key to show the new arrival only . I also wonders what Wulfie will say as it seems he is on the back foot already as it is clear it was possible to Multi Sit on a prim from WIKI

 

Denise X

 

 

 

[VirtualKitten]

56 minutes ago, Qie Niangao said:

I don't know who this "fox" is you keep talking about. If they've got something to contribute, get them posting here.

Qie the clever  fox is in my Scripting group on SL  @Fox Paragorn a fabulus scripting group referred to me by Firestorm Support another great group that work very hard like the scripting groups I am part of in SL. 

[Wulfie Reanimator]

29 minutes ago, VirtualKitten said:

Wulfie . I am not sure I follow what is the blue and red box supposed to represent  as they are not the physics or bounding box of the cube you are trying to sit on . You also miss the point that a second llLinkSitTarget( can be set so you should be able to have another seat so the system should not revert to any old method like you indicated but to the bnew seat created by  llLinkSitTarget( unless of course  llLinkSitTarget( does nothing to set a seat once the seat is taken up  up by llSitTartget(. IF this is the case this would be od as by the very fact that a link has been added to the seat it becomes a LINK_SET not a prim  therefore i would expect a llLinkSitTarget( to define a new seat in the LINK_SET. As we are aware this doesn't happen in practice and you get a silly message stating "No Room to sit , try another spot" is generated.  I presume then passenger seating is not robust and the code on wiki is redundant as the SERVER updates have rendered it unworkable as per the demonstration you gave of PrimPossible furniture.

Your posts are very difficult to parse but hopefully I understood:

• You're using llLinkSitTarget to give enough links (different ones...) a sit-target.
• Your object is actually a linkset of multiple components, not a one-piece mesh chair.
• You're still getting "No room to sit here."

Below, I've linked together two prims which are placed in the exact same position, one of them is just twice as big:

state_entry()
{
    llLinkSitTarget(1, <0,0,1>, ZERO_ROTATION);
    llLinkSitTarget(2, <0,0,1>, ZERO_ROTATION);
}

You can see that even though my linkset is completely encased by another (solid) physics shape and both seats are inside of each other and both sit-targets are in the same place, I am able to sit onto the seats with both of my avatars. This would never be possible without sit-targets. So, if you're using llLinkSitTarget and still getting "no room to sit" errors, you are not setting them correctly. There is no problem with the sitting system, sit-targets have always worked like this.

 

29 minutes ago, VirtualKitten said:

I also wonders what Wulfie will say as it seems he is on the back foot already as it is clear it was possible to Multi Sit on a prim from WIKI

"Back foot?" Do you think I'm trying to defend some opinion here? I've spent five hours today with @Profaitchikenz Haiku, trying to figure things out and explain them to help you.

I'm glad I at least wrote the above before I noticed this part, so others can benefit. I'm done, good luck figuring out your own mess.

What an absolute waste of effort. I have no words.

Edited July 11, 2020 by Wulfie Reanimator

[Profaitchikenz Haiku]

33 minutes ago, VirtualKitten said:

message stating "No Room to sit , try another spot" is generated

As already mentioned, this is due to other factors, you can have a prim with a perfectly valid sit target but if there is another prim in an  unfortunate proximity to it you may get this message. One way to investigate this is to move the prim containing the sit target to different positions and see if the message goes away. It is harder to do in something like a vehicle but a possible way to investigate it would be to move the child prim with the sit target up a metre and see if that clears the problem.

[VirtualKitten]

Well I have also spent  five hours trying to get an answer as to how SL determines  its criteria before a seat occurs .  I have not  been told that as yet. 

My example at the start of this  page was not questioned as to its programming  by you Wulfie so how is it not applied properly you stated rudely !  PRIM possible furniture didn't work  as you avatar became larger or at least that is what I understood  from what you said or was that  a cheep jibe too.  Back Foot yes Wulfie this was also published working on wiki working on a single prim please read what is written above. http://wiki.secondlife.com/wiki/Json_multi_sit_array or are you now suggesting wiki has it wrong too that something has changed when clearly it has  to prevent this working by your own admission. This said can we please stay open minded and try to figure out what SL is doing now and why its has been changed? As more great software will fail if we don't get a spin on this as to why and how it can be got working? I feel the same Wulfie but from the other side of the pond. You didnt even seem shocked about  PRIMPossible .

[VirtualKitten]

1 minute ago, Profaitchikenz Haiku said:

As already mentioned, this is due to other factors, you can have a prim with a perfectly valid sit target but if there is another prim in an  unfortunate proximity to it you may get this message. One way to investigate this is to move the prim containing the sit target to different positions and see if the message goes away. It is harder to do in something like a vehicle but a possible way to investigate it would be to move the child prim with the sit target up a metre and see if that clears the problem.

I think i already said I tried Inula's prim which tests to see if there is a bounding box in proximity . I think i have already said it doesn't work any were  as a mesh passenger seat despite the code working to great affect it never reaches it as the system message cuts in "No Room to sit , try another spot"  we need to focus and ask why is this message generated when there is no interference from a bounding box! 

[Profaitchikenz Haiku]

1 hour ago, Wulfie Reanimator said:

But any avatar after the first will not be placed on the sit-target, but rather gets placed "normally"

In fact my experience is that the second avatar, if in close proximity to the first, is usually rotated 90 degrees on the Z axis, which allowed a cheat to get somebody apparently sitting on somebody else's lap when I first began playing around with multi-sits.

Thanks for the exposition on the physics shape, it's an area I've not paid much attention to previously but it's now making more sense.

[Profaitchikenz Haiku]

1 minute ago, VirtualKitten said:

why is this message generated when there is no interference from a bounding box! 

If I understand what Wolfie has been showing, it is the physics shape, and this is not the same as the bounding box.

[VirtualKitten]

Just now, Profaitchikenz Haiku said:

If I understand what Wolfie has been showing, it is the physics shape, and this is not the same as the bounding box.

If I understand Wulfie what he posted said he was using LlCastRay to find a bounding box  now this projects a single light ray to find a collision with another. I am not sure how this applies to physics shapes he showed us and how he determined this to blue and red box approximations in his later model . I expected him to show some insight in this and how he reached that point.

As I stated there are some problems with  seats but some can be got around but this message is not scripting related and instead is a system message  which wulfie said happened when the first seat had been used up. He said the system defaulted to a previous seating method the one that doesn't work and was re written adding new functions. This seems utterly bizarre that this would be the seating objects method to go back to something that didn't work or had been improved to determine a seat and clearly needs work.. I can however see some idea that this was an attempt to ensure older  models built with previous seating model still worked. Sadly PRIM possible shows this has not worked!

Now it seems we need a new fix!

 

[Qie Niangao]

43 minutes ago, VirtualKitten said:

If I understand Wulfie what he posted said he was using LlCastRay to find a bounding box  now this projects a single light ray to find a collision with another. I am not sure how this applies to physics shapes he showed us and how he determined this to blue and red box approximations in his later model . I expected him to show some insight in this and how he reached that point.

"expected" ???

Anyway, I've used llCastRay to rez tiny prims at the point where the ray intersects with an avatar, which done enough times will form a shape. That's the avatar's actual physics shape because llCastRay uses Havok to find those intersection points. (llCastRay will also return the normal at the point of intersection, so that might help form a shape faster than just sticking little spheres to the intersections.)

Yes, there are two different mechanisms of determining seating. They serve different purposes. The original, non-sit-target approach is handy so avatars can sit on surroundings that aren't specifically intended as seats. It works everywhere, not only scripted objects. (Well, ground sitting is a whole different thing, with a whole different history.) It can be used in scripted objects, too, to do animation and move avatars around (as that wiki "JSON" seating example demonstrates).

The other approach uses sit targets, but only one per link. That's not a bug, that's just how it works. In theory you could ask for a new feature that allows a single link (mesh or otherwise) to have more than one sit target, but it would break a huge number of scripts that rely on llAvatarOn[Link]SitTarget() to return a well defined value.

[Wulfie Reanimator]

Holy ****. I just read the wiki page since it was finally linked and I have context.

5 hours ago, VirtualKitten said:

Back Foot yes Wulfie this was also published working on wiki working on a single prim please read what is written above. http://wiki.secondlife.com/wiki/Json_multi_sit_array or are you now suggesting wiki has it wrong too

Yes.

It has nothing to do with sit-targets. None. It doesn't even use them. It doesn't even try to fix the issue of "no room to sit."

It's literally just a more complex way of keeping track of which avatar is where in the world. [uuid, position, rotation, uuid, position, rotation, ...]

That page and script was written by a regular user just like you and me. You don't even understand the description of the intention of the code.

5 hours ago, VirtualKitten said:

Well I have also spent  five hours trying to get an answer as to how SL determines  its criteria before a seat occurs .  I have not  been told that as yet. 

Not a single thing I've said in this thread is inaccurate, not even my very first post when I didn't yet know exactly how sit-targets work. My explanations apply 100% to the problem you're having. You don't even understand why "I wasn't shocked by PrimPossible." You haven't understood one word of what has been said by anyone in this entire thread.

6 hours ago, VirtualKitten said:

it is clear it was possible to Multi Sit on a prim from WIKI

You are helplessly clueless. You read something on the wiki, misinterpreted it, and believe it as gospel. You remind me of Steph Arnott.

Edited July 11, 2020 by Wulfie Reanimator

[Profaitchikenz Haiku]

2 hours ago, VirtualKitten said:

I expected him to show some insight in this and how he reached that point.

Actually, I was able to see the physics shapes for myself by going into the advanced menu then render info, render types, and found the option in there to show the world as physics shapes. It gave me a real insight into my own 1-prim four chairs around a table - the physics shape was a strange distorted rhomboid that stretched from the centre of the table out and down to the seat of each chair but didn't go out as far as the chair backs, or bridge from seat to seat. It was quite different from the bounding boxes of the mesh, which were far more complex but as we realised, had no real impact on where the avatar could or couldn't sit.

I suspect ray-tracing gives a far more accurate view of the avatar's physics shape, or anything else for that matter, but the viewer's own advanced info is quite adequate for making sense of what is going on in the world.

Edited July 11, 2020 by Profaitchikenz Haiku

[VirtualKitten]

Thanks for sharing this wisdom @Profaitchikenz I think I may have found them in Firestorm on the Developer Menu >> Rendering Meta Data > Bounding Box  I did not have the option 'render info' you had on Action Menu . It had no Physics's shape as I presume you has in second life browser as I am using firestorm: I also found Physics Shape Here:  Developer Menu >> Rendering Meta Data > Physics Shape.

This was most helpful as it did not show any obstruction that would case the passenger seat to fail. The Physics is attached in blue and the bounding boxes are attached in green below.

This said I am still not any clearer what is obstructing the passenger sit. Secondly if we have a command like SetSeatTarget or SetLinkSeatTarget should wiki not define them as one setting on the prim . If that is the case we are expected to understand as it is not listed like this in the functions caveats.

D

 

 

 

 

 

 

[VirtualKitten]

Am still trying to find an answer for this as it appears there is no physics affecting the sit . I haven't seen my avatar enlarge either .As the wiki page gives no criteria why llLinkSeatTarget cannot be used twice i fail to see why it cannot be used in this manner:)

[Profaitchikenz Haiku]

I'm curious to know what you are trying to achieve. Do you want to seat somebody else on the piano stool beside the player, or do you want then perched on the frame of the piano?

[VirtualKitten]

@Profaitchikenz, hi again, well just to get them seated somewhere while i am seated  this used to work on single prim, it  would be a help as nothing i have tried  gets them seated on the stool or piano  near me as a passenger , The box above my head is a dance machine I took it of when i tried other passengers  seating  It doesn't matter where I set this new seat with LLSetLinkSeatTarget there is no seat available to anyone  "No Room to sit , try another spot" until i get up and relinquish seat. This is an LSL Message my script does not get triggered after i have set by a passenger as LSL system  puts up message "No Room to sit , try another spot"  Wulfie seems to have conflicted views on this  which i cannot understand . 

[Love Zhaoying]

39 minutes ago, VirtualKitten said:

@Profaitchikenz, hi again, well just to get them seated somewhere while i am seated  this used to work on single prim, it  would be a help as nothing i have tried  gets them seated on the stool or piano  near me as a passenger , The box above my head is a dance machine I took it of when i tried other passengers  seating  It doesn't matter where I set this new seat with LLSetLinkSeatTarget there is no seat available to anyone  "No Room to sit , try another spot" until i get up and relinquish seat. This is an LSL Message my script does not get triggered after i have set by a passenger as LSL system  puts up message "No Room to sit , try another spot"  Wulfie seems to have conflicted views on this  which i cannot understand . 

I believe that I see your underlying problem. There is no room to sit, try another spot. @Wulfie Reanimator did a great job, too bad you focus on the wiki LIBRARY (not article) script - those Wiki library scripts have no guarantees. 
 

The misunderstandings in this thread are both epic, and entertaining.

[Mollymews]

42 minutes ago, VirtualKitten said:

It doesn't matter where I set this new seat with LLSetLinkSeatTarget there is no seat available to anyone ... until i get up and relinquish seat

this is expected behaviour

changing a sit target while an avatar is sitting on it doesn't free the sit target (llAvatarOnSitTarget)

can test this:

default
{
    state_entry()
    {
        llSitTarget(<0.0, 0.0, 1.0>, ZERO_ROTATION);
    }

    // sit on the object then Touch

    touch_start(integer total_number)
    {
        
        key sit1 = llAvatarOnSitTarget();  // sit1 will be us
        
        llSleep(1.0);

        // remove the sit target
        llSitTarget(<0.0, 0.0, 0.0>, ZERO_ROTATION);
        key sit2 = llAvatarOnSitTarget(); // sit2 will be us
        
        llSleep(1.0);        
        
        // reset the sit target
        llSitTarget(<0.0, 0.0, 2.0>, ZERO_ROTATION);
        key sit3 = llAvatarOnSitTarget(); // sit3 will be us
               
        llOwnerSay(llDumpList2String([sit1, sit2, sit3], " | ")) ;
        
    }
}

 

 

[VirtualKitten]

Hi Prof If you take my script at top and obtain the script on the links here http://wiki.secondlife.com/wiki/Json_multi_sit_array an merge them you will have a multi sitter . You will see from it it moves  the avatar from a JSON array  position after they are seated  . You wont have quite what I have as I added animation to mine . But the principle is the same. This was written  multi sit prim using Json Arrays (expects 6 seats)  written by To-mos Codewarrior(tomos.halsey) 25 May 2015. I believe it no longer functions as the LSL updates have done something.If I understand what Wulfie told us he said his Prim Possible table and chairs had a similar problem?

I have already said at length that this is not a script issue as the message is generated by the Browser or Linden Server or both . I think Wulfie said it was reverting to the old way of locating a seat which was problematic and updated. The script never gets hold of the touch  from the seat.

As I told you the fox told me to add second Target and wulfie suggested it was a link target as i had been linked. I understand it only seats one this is the problem none of the old scripts now work on WIKI

Edited July 12, 2020 by VirtualKitten

[Profaitchikenz Haiku]

1 hour ago, VirtualKitten said:

it  would be a help as nothing i have tried  gets them seated on the stool or piano  near me as a passenger 

Try this:

Link a 0.2x0.2x0.2 cube to the piano stool, position it at least 1 metre to the left and behind the piano player. Give it a link sit target. Try to sit on it. If necessary move it further left, back and up until you can get a second avatar sitting on it reliably. Then begin moving it closer to where you want, until the "no room to sit" message occurs again. This will at least establish the boundary of where the conflict occurs.

I also suggest you try not referring to them as "passengers" as this is leading people's minds along the route of vehicles, which have slightly different issues. You want to add sitters to your build, not passengers.

 

Edited July 12, 2020 by Profaitchikenz Haiku
typsees

[Profaitchikenz Haiku]

10 minutes ago, VirtualKitten said:

I have already said at length that this is not a script issue as the message is generated by the Browser or Linden Server or both . I think Wulfie said it was reverting to the old way of locating a seat which was problematic and updated. The script never gets hold of the touch  from the seat.

Correct, this is what most of us have been reiterating, in fact you could assign sit targets to various children in a link set and once happy with the result, remove the scripts. The prim retains any sit target as a prim property, like particles.

 

Thanks for the offer of the script but as you say, it isn't a scripting error, and I have a (reasonable) working multi-sit script of my own that works so long as I make the build such that the bounding boxes or physics allow several sitters to join the party.

ETA a moment of doubt, do child prims retain prim properties in the same way that unlinked prims do? Once I've finished crawling under the car and getting facefuls of petrol I'll dash inworld and have a fiddle. Unless some of you sensation seekers out there gleefully lapping up this thread care to do some experimenting?

Edited July 12, 2020 by Profaitchikenz Haiku