Is there a way to get a list of nearby sit targets?

[primerib1]

As the title asks.

 

[Fenix Eldritch]

For a list within the current linkset, you can use llGetLinkPrimitaveParams and PRIM_SIT_TARGET.

For a list of external objects or linksets, you're more limited. llGetObjectDetails does not have an equivalent constant for sit targets. It does, however, have OBJECT_CLICK_ACTION and CLICK_ACTION_SIT... which you could use to infer that a sit target has been potentially set on the prim. But that is not guaranteed to always be the case.

[primerib1]

12 hours ago, Fenix Eldritch said:

For a list within the current linkset, you can use llGetLinkPrimitaveParams and PRIM_SIT_TARGET.

For a list of external objects or linksets, you're more limited. llGetObjectDetails does not have an equivalent constant for sit targets. It does, however, have OBJECT_CLICK_ACTION and CLICK_ACTION_SIT... which you could use to infer that a sit target has been potentially set on the prim. But that is not guaranteed to always be the case.

Thanks

So I guess I'll just have to try sitting the agent on the object and deal with failures manually?

Now related to this, is there a way to get a list of nearby objects, say within X meters of the agent?

[Ron Khondji]

llSensor( string name, key id, integer type, float radius, float arc );

[Profaitchikenz Haiku]

The sensor method will work to an extent in that it can detect objects, also objects with scripts, but it's then a guessing game as a script in an object isn't necessarily setting a sit target, and an unscripted object might have a sit target left by a now deleted script as a prim property. Also, some prims will have a default sit position but might also be impossible to sit on (see a post by Wulfie some time ago about this problem with some mesh items, I believe Virtual Kitten asked the question).

I'd suggest having a look at how RLVa manages to get a list of possible sit targets for the forced-sit/unsit controls. @Coffee Pancake might be able to point you in the right direction.

Edited February 19, 2023 by Profaitchikenz Haiku

[Wulfie Reanimator]

1 hour ago, Profaitchikenz Haiku said:

Also, some prims will have a default sit position but might also be impossible to sit on (see a post by Wulfie some time ago about this problem with some mesh items, I believe Virtual Kitten asked the question).

I'm upset just thinking about that thread again. 😣

TLDR:

• An object can always be sat on if it has a free sit target.
• If the object has no (unoccupied) sit targets, the sim will do a bounding-box check before giving the avatar a nearby surface to sit on.
  • If another bounding box overlaps with where the avatar would sit, a "no room to sit" error will be given.

Edited February 19, 2023 by Wulfie Reanimator

[Fenix Eldritch]

3 hours ago, primerib1 said:

Now related to this, is there a way to get a list of nearby objects, say within X meters of the agent?

Like Ron and Profaitchikenz says, llSensor and its accompanying sensor event are typically used to detect objects/agents within a radius around the scanning object. But it has some staunch limitations... A sensor will only detect a maximum of 16 objects at a time, and the filtering you can apply to it beforehand is rather limited. You can filter by target name, but it has to be an exact match. Same for the target's key. Type is unintuitive, but I recently took a stab at mapping it out in this thread.

The general theory is that you would perform a sensor sweep and then process each result, inspecting them as best you can with the available functions that allow you to specify a remote object.

Is this device you're making intended to work within a controlled environment of your own design? If so, you can leverage that by giving objects with sit targets a unique name that a sensor filter can pick up. Otherwise you're going to have a rough time sifting through a mountain of results in 16-entry chunks at a time  - and even then there are no guarantees.

[primerib1]

1 hour ago, Profaitchikenz Haiku said:

The sensor method will work to an extent in that it can detect objects, also objects with scripts, but it's then a guessing game as a script in an object isn't necessarily setting a sit target, and an unscripted object might have a sit target left by a now deleted script as a prim property. Also, some prims will have a default sit position but might also be impossible to sit on (see a post by Wulfie some time ago about this problem with some mesh items, I believe Virtual Kitten asked the question).

I'd suggest having a look at how RLVa manages to get a list of possible sit targets for the forced-sit/unsit controls. @Coffee Pancake might be able to point you in the right direction.

I checked the protocol at https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI#Sitting , there doesn't seem to be a way via RLV to get a list of nearby "sittable" objects.

And even if RLVa has such a feature, I'm not going to code something that's RLVa-specific.

Oh well, I'll let the command issuer handle any failure then 🙂

[primerib1]

7 minutes ago, Fenix Eldritch said:

Otherwise you're going to have a rough time sifting through a mountain of results in 16-entry chunks at a time

Gonna limit scan to, say, 2m from agent. And if there are too many, I'll just discard the rest 🙂

 

[Qie Niangao]

Why is sit target of interest? If it's to find all places avatars might sit, the "sit target" isn't particularly helpful. An object with a sit target will (usually) accommodate (at least) one sitting avatar, but the same is very likely true of the much more numerous objects that lack sit targets.

Is RLVa really able to divine which objects that lack sit targets are nonetheless sit-accommodating? I've always understood that the sim does some inscrutable Havoc magic to decide whether it wants to let an avatar sit on an object lacking a sit target.

[Love Zhaoying]

3 minutes ago, Qie Niangao said:

Why is sit target of interest? If it's to find all places avatars might sit, the "sit target" isn't particularly helpful. An object with a sit target will (usually) accommodate (at least) one sitting avatar, but the same is very likely true of the much more numerous objects that lack sit targets.

Is RLVa really able to divine which objects that lack sit targets are nonetheless sit-accommodating? I've always understood that the sim does some inscrutable Havoc magic to decide whether it wants to let an avatar sit on an object lacking a sit target.

Iz not, "if I fits, I sits"?!

[primerib1]

55 minutes ago, Love Zhaoying said:

Iz not, "if I fits, I sits"?!

Iz a poney, not a cat  

[primerib1]

1 hour ago, Qie Niangao said:

Why is sit target of interest? If it's to find all places avatars might sit, the "sit target" isn't particularly helpful. An object with a sit target will (usually) accommodate (at least) one sitting avatar, but the same is very likely true of the much more numerous objects that lack sit targets.

Okay so basically some restraints for bleh reasons prevent the someone wearing it from sitting on their own.

So their "handler" needs to force them to sit on something.

The only way I can think of -- barring a uniform API for all objects to tell the agent that they are sit-able -- is to scan for nearby object finding which ones can be sat upon.

Which, apparently, is kinda hopeless sisyphean task with available facilities...

So I have to fallback to just grabbing a list of nearby objects, present the list to the "handler", and let the "handler" deal with the fall out of failing to force-sit the victim to the object.

[Love Zhaoying]

12 minutes ago, primerib1 said:

So their "handler" needs to force them to sit on something.

Why not just force them to "sit" as in, sit animation?

Is there an actual need to sit "on" something, since RLV can control what they do?

(Sorry, sometimes the easy and so-called "obvious" answers come to mind.)

[primerib1]

3 minutes ago, Love Zhaoying said:

Why not just force them to "sit" as in, sit animation?

Is there an actual need to sit "on" something, since RLV can control what they do?

(Sorry, sometimes the easy and so-called "obvious" answers come to mind.)

Because the item they will be forced to sit onto, has its own animation / poses.

So the 'victim' will need to actually do the "sit action" onto the item.

This is done by remotely invoking the @sit:<UUID>=force RLV command.

Edited February 19, 2023 by primerib1

[Love Zhaoying]

5 minutes ago, primerib1 said:

Because the item they will be forced to sit onto, has its own animation / poses.

So the 'victim' will need to actually do the "sit action" onto the item.

This is done by remotely invoking the @sit:<UUID>=force RLV command.

Ok, so you may have 2 problems to solve:

1) Identifying if an item has a "sit target".

2) If you care, identifying if the item has an animation or not.  Any old item can have a sit target with no special animation.

If you script all the items yourself, then you can ask an item via it's UUID, "Do you have a sit target and animation?" and proceed with its response / non-response.

 

[primerib1]

7 minutes ago, Love Zhaoying said:

Ok, so you may have 2 problems to solve:

1) Identifying if an item has a "sit target".

2) If you care, identifying if the item has an animation or not.  Any old item can have a sit target with no special animation.

If you script all the items yourself, then you can ask an item via it's UUID, "Do you have a sit target and animation?" and proceed with its response / non-response.

 

I wish I scripted those myself ...

Those items were 3rd party items available from MP/shops, so no documented API if any.

I don't think trying to identify items having a sit target is worth the effort tho.

So I'm just dumping a list of things nearby the victim to the handler, letting the handler choose one that seems to be the right one ...

If not, try again

 

[Qie Niangao]

In a very quick and dirty test, and without reading any code at all, an RLV collar menu seems to offer "Force Sit" on a list of scripted items in near proximity to the collar-wearer (not the location of the agent operating the menu). It failed to seat the collar-wearer on a scripted item that was not scripted for sitting although the avatar was able to sit on it manually if they were really close and there was a clear path between the avatar and the object.

I suppose this all works by the collar telling the collar-wearer's RLV viewer to do "Sit here" on the object, and the list of candidate objects produced by the collar doing a sensor scan for scripted items. That'll miss some, and have some false alarms, but apparently it's good enough for RLV.

[Love Zhaoying]

44 minutes ago, primerib1 said:

So I'm just dumping a list of things nearby the victim to the handler, letting the handler choose one that seems to be the right one ...

If not, try again

If the area is a "static" RP area, then you could always maintain your own list since you know what is in the area ahead of time!

[primerib1]

1 hour ago, Love Zhaoying said:

If the area is a "static" RP area, then you could always maintain your own list since you know what is in the area ahead of time!

Well, one of the area's managers like to do bursts of relandscaping / moving things around... so it's kinda hard 😆

[primerib1]

1 hour ago, Qie Niangao said:

the list of candidate objects produced by the collar doing a sensor scan for scripted items.

Based on the table that @Fenix Eldritch had kindly shared, I just had to search for ACTIVE|PASSIVE ... getting a buncha objects.

Which I then sort based on distance.

So the RP would be for the "handler" to ask the "victim" to come as near as possible to the target item, hopefully making the item appears first in the list so no hunting around...

[Profaitchikenz Haiku]

On 2/19/2023 at 12:27 PM, Wulfie Reanimator said:

I'm upset just thinking about that thread again. 😣

I apologise for causing such pain, but it's probably worth it just to get the TLDR summary.

Edited February 20, 2023 by Profaitchikenz Haiku