Quistess Alpha Posted June 30, 2022 Share Posted June 30, 2022 Is there a method of getting the avatars that count towards an object's OBJECT_SELECT_COUNT? I'm specifically interested in avatars who are accessing media on the object (basic testing shows interacting with media does increase the count) Link to comment Share on other sites More sharing options...
Rolig Loon Posted June 30, 2022 Share Posted June 30, 2022 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. 1 Link to comment Share on other sites More sharing options...
Quistess Alpha Posted June 30, 2022 Author Share Posted June 30, 2022 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 More sharing options...
Rolig Loon Posted June 30, 2022 Share Posted June 30, 2022 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. 1 Link to comment Share on other sites More sharing options...
Lucia Nightfire Posted June 30, 2022 Share Posted June 30, 2022 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. 😆 3 Link to comment Share on other sites More sharing options...
Quistess Alpha Posted June 30, 2022 Author Share Posted June 30, 2022 36 minutes ago, Lucia Nightfire said: you'd have to file a feature request for access to the key list. Filed: https://jira.secondlife.com/browse/BUG-232321 I mostly wanted to make sure I wasn't missing something obvious or new before putting in a jira for it. 1 Link to comment Share on other sites More sharing options...
Qie Niangao Posted July 1, 2022 Share Posted July 1, 2022 (edited) 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 anybody in the region could identify their avatar interacting with any specific object(s) in that region? 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 July 1, 2022 by Qie Niangao Link to comment Share on other sites More sharing options...
Quistess Alpha Posted July 1, 2022 Author Share Posted July 1, 2022 (edited) 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 July 1, 2022 by Quistess Alpha Link to comment Share on other sites More sharing options...
Qie Niangao Posted July 1, 2022 Share Posted July 1, 2022 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 likesecondlife:///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: if "Object Profile" is selected, a dialog with pulldown menu like this appears: 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. 1 Link to comment Share on other sites More sharing options...
Quistess Alpha Posted July 1, 2022 Author Share Posted July 1, 2022 (edited) 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: 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?") Having (any link of) the object selected in edit mode. Having any media-face of the object selected. ETA: object highlighted with "Inspect object" window. Notable things that are NOT selection (which I incorrectly assumed would be): Highlighting the object with about-land ->objects ->show or similar. Sitting on the object Moving a physical object by click-dragging it. Edited July 1, 2022 by Quistess Alpha Link to comment Share on other sites More sharing options...
Quinn Elara Posted July 1, 2022 Share Posted July 1, 2022 24 minutes ago, Quistess Alpha said: 3. Moving a physical object by click-dragging it. That seems like a really weird omission, I would have expected that to be included! 🙃 1 Link to comment Share on other sites More sharing options...
Qie Niangao Posted July 1, 2022 Share Posted July 1, 2022 1 hour ago, Quistess Alpha said: 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. 1 Link to comment Share on other sites More sharing options...
Quistess Alpha Posted July 1, 2022 Author Share Posted July 1, 2022 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. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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