Jump to content

How to get object selectors?


Quistess Alpha
 Share

You are about to reply to a thread that has been inactive for 827 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

That's a pretty new parameter, so I haven't had occasion to use it yet myself, but it looks like it is only designed to return the count as an integer. I'm a little surprised that accessing media is interpreted as "selecting" the object rather than touching it, which would trigger a touch* event.  If you had actually touched the object, of course, you would have llDetectedKey to answer your question, though.  It's a puzzle.

  • Like 1
Link to comment
Share on other sites

3 minutes ago, Rolig Loon said:

I'm a little surprised that accessing media is interpreted as "selecting" the object

My theory is that the 'select count' is mostly useful server-side for knowing when ~not to delete an object if it's set to temporary.

Being in edit mode on an object also counts, and presumably(I didn't think to test) sitting on it does too.

Link to comment
Share on other sites

That makes sense, but you aren't selecting the MOAP prim to access the media stream.  You are touching it.  I don't see why (1) that doesn't trigger a touch_start event or (2) why it does increase the OBJECT_SELECT_COUNT.  That's two puzzles, not just one.

  • Like 1
Link to comment
Share on other sites

The dev that implemented OBJECT_SELECT_COUNT told me objects keep a list of user keys selecting them which is what that feature counts so you'd have to file a feature request for access to the key list.

I've even wanted access for feedback with physics, omega and animesh apps which can't function correctly while selected .

"Maybe" also to allow an alert system for my attachments when someone is being nosey. 😆

  • Like 3
Link to comment
Share on other sites

Before I comment on the jira, a sanity check may be in order. Usually I'm the very last to pose "privacy" concerns about anything strictly in-world, but this does seem like a real change in the nature of what's known to whom about the actions of avatars, and I wonder if there's any reason to hesitate about that. The question comes to: would some folks enjoy their time in SL less if they knew

  1. anybody in the region could identify their avatar interacting with any specific object(s) in that region?
  2. their avatar could be directly associated with MoaP interactions?

Now, #2 isn't entirely new, but it makes the identity association almost as simple and direct for MoaP as PARCEL_MEDIA_COMMAND_AGENT (of RedZone infamy) is for Parcel Media. There's potentially more at stake on a MoaP surface because it's often web-interactive, but security risks are there anyway, this merely streamlines the association of avatar identity with the media clickstream.

But #1 seems remarkably different from what folks can assume about how their virtual world interactions can be surveilled by all and sundry. Not only could the owner of Scary Embarrassing Object know who's merely selected it (without even clicking it), but so can any voyeur script in the region. [but see EDIT below]

Incidentally, #1 might lead to third party viewer features* that allow a "private pre-selection" inspection of (non-MoaP?) objects in the scene. (This would also usually be possible with a cam-tracking script, but a viewer could do it with more consistent precision, triggered with a more specific gesture.) I'm not sure this would defeat the intended functionality of the feature, but I don't fully understand that intent.

But am I just being a Nervous Nelly?

[EDIT: The jira doesn't propose to add functionality to llGetObjectDetails() for arbitrary objects, but rather proposes functions that do not take object UUID as an argument, so presumably apply only to the object itself. That would limit the info to the object owner, which is still an expansion in what behavior can be surveilled, but not as big a leak as if it were an extension to llGetObjectDetails.] 

___________________
*Speaking of TPVs, at least Catznip currently provides an "Object Profile" option to the viewer "objectim" URI text in chat that does increment the selection count of that object in the region without the object itself ever needing to be moused by—nor even shown in—the viewer doing this remote "selection". This may be viewer specific, and anyway is probably close enough to "selection" to fit the intended semantics.

Edited by Qie Niangao
Link to comment
Share on other sites

2 hours ago, Qie Niangao said:

(without even clicking it),

AFAIK all "selection" operations require a click (except arguably sitting if that counts), and "camming onto" an object does not count as selection.

2 hours ago, Qie Niangao said:

[but see EDIT below]

Yeah, privacy wise, even OBJECT_SELECT_COUNT being accessible from other objects seems a little bit of a reach, but it's also a little hard to think up use cases as is (maybe have a script poll and keep track of "most popular objects" on the sim from a list of candidates?)

ETA: look-at targets and selection beams are already in-place to "make it obvious" who is interacting with what. Little reason not to let a script see what avatars in-world can see "with the naked eye". . . note to self: Test whether accessing MoaP on firestorm induces its eye-burning very colorful selection effect.

Edited by Quistess Alpha
Link to comment
Share on other sites

4 hours ago, Quistess Alpha said:

AFAIK all "selection" operations require a click (except arguably sitting if that counts), and "camming onto" an object does not count as selection.

Again, I think some of this may be Catznip-specific, but the standard objectim URI text, something like
secondlife:///app/objectim/5398dd90-fac2-19ae-b29f-50cd1c2c0572?name=MoaP%20streams&owner=72435d55-873c-4617-b6ea-9a707d1f6800&slurl=Myron/203.644000/114.767900/2003.364000
appears in chat history with the mousable "MoaP streams" text here:
image.png.70234055db8ae7ff70fa5a9d0d23f4cc.png
if "Object Profile" is selected, a dialog with pulldown menu like this appears:
image.png.a1fc9b0659f9fd08457089b19b256212.png
and while that dialog is present the selection count for that "MoaP streams" object is incremented, even though the viewer with the objectim dialog hasn't even rezzed the object. (This is actually extremely handy, particularly for telling your alt how to easily find stuff.) Again, I don't think this works the same way in the Linden viewer, and I have no idea about other TPVs.

To be clear, I'm not suggesting this bit is any kind of privacy concern, and it's pretty specialized anyway, but it is one way the "selected" count may not mean exactly what one expects.

I realize, too, that personally I'm only a little concerned about the prospect of some owner knowing that I selected their stuff, but that's because I'd only think about the drama a privacy-focused object owner may concoct if they don't like me mousing on their sex toys to learn creator, land impact, etc. Or, god forbid, their attachments. 

Note also that "selection" is different from a "look at" target which the privacy-minded can defeat with viewer settings anyway, as well as hide selection beams and suppress the editing animation. I have no idea if that selection information may nonetheless leak to other viewers, but even so it is a bit different for all those selection events to be collected by the object owner 24x7.

  • Confused 1
Link to comment
Share on other sites

3 hours ago, Qie Niangao said:

URI text

I don't see how URI text has anything to do with selection. Perhaps we have some basic terms misuderstood?

By "Selection" I mean whatever actions cause OBJECT_SELECT_COUNT to increase:

integer gSelected;
default
{
    state_entry()
    {   llSetTimerEvent(0.5);
        llSetPrimMediaParams(0,[PRIM_MEDIA_HOME_URL,"https://community.secondlife.com/forums/topic/488486-how-to-get-object-selectors/#comment-2474449"]);

    }
    touch_start(integer total_number)
    {   llSay(0, "Touch start");
    }
    touch_end(integer n)
    {   llSay(0,"Touch end");
    }
    timer()
    {   integer selected =!!(llList2Integer(llGetObjectDetails(llGetKey(),[OBJECT_SELECT_COUNT]),0));
        if(gSelected!=selected)
        {   gSelected=selected;
            if(selected)
            {   llSay(0,"Selection start");
            }else
            {   llSay(0,"Selection end");
            }
        }
    }
}

I was under the impression "touching" an object counted as selecting it; the above example shows it does not.

By "MoaP" I mean a webpage displayed on the face of a prim, in the above example, face 0. The floater you get when interacting with specific SLURLS has nothing to do with MoaP.

A little bit of accidental experimentation revealed that holding 'ctrl' while touching registers touch events through a media face, 'regular' touch on a media face begins selection, as does right-clicking and/or editing, but ~Not sitting.

Perhaps I should have done a bit more experimentation earlier, but as far as I can tell now, the things which count as selection are:

  1. The right-click on a prim to show its context menu (Does clicking on that gear in Catznip cause an object scripted with the above to say "Selection start?")
  2. Having (any link of) the object selected in edit mode.
  3. Having any media-face of the object selected.
  4. ETA: object highlighted with "Inspect object" window.

Notable things that are NOT selection (which I incorrectly assumed would be):

  1. Highlighting the object with about-land ->objects ->show or similar.
  2. Sitting on the object
  3. Moving a physical object by click-dragging it.
Edited by Quistess Alpha
Link to comment
Share on other sites

1 hour ago, Quistess Alpha said:
  1. The right-click on a prim to show its context menu (Does clicking on that gear in Catznip cause an object scripted with the above to say "Selection start?")

Yes. That's what I've been trying to say. (More precisely, the selection starts sooner, when you click on the viewer URI text itself, causing the initial pop-up dialog.) If the avatar is in the immediate vicinity of the object, it does get a selection beam and highlighted perimeter just as if it were selected directly by mouse, so the process overlaps a great deal with such regular object selection. That's why I said it's "probably close enough to 'selection' to fit the intended semantics" although I'm not entirely sure of the scope of that intent. I mean, if we're really only interested in situations where an avatar points their mouse directly at the object to select it, then selection count isn't always measuring that, at least not in Catznip.

  • Thanks 1
Link to comment
Share on other sites

9 minutes ago, Qie Niangao said:

I mean, if we're really only interested in situations where an avatar points their mouse directly at the object to select it, then selection count isn't always measuring that, at least not in Catznip.

If you want avatars who are pointing 'directly at' an object, I think touch events are close enough to that. "selection" seems to me to be an odd combination of different interactions, (context-menu, edit, object-inspect, media) Maybe the only connection is "Things that cause highlight and selection beam but are not touch"?

Personally I'm most interested in using the information to "encourage" a single selector. e.g. for a MoaP board game, tell everyone who's selecting the object but it's not their turn to select something else. Or say, have an object with 'anyone can move' enabled, but only allow movement on one axis or restrict to a specific area if the selector is not the owner.

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 827 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...