A Function to Detect Right click.
tracked
Emmy Bloobury
We have many ways to Detect if an object is (left) clicked on, but no way to Detect if someone rights clicks on that same object, Why?
This would be a very useful feature for the SL Racing Community and vehicle enjoyers as a whole, and I'm sure this could have many other uses for scripters in general. The reason for this request is because of the ability of a resident to effect the movement of a car (or any physical object) even if the object doesn't belong to them by right clicking on the object. I am not talking about a resident that has the person's edit rights, or estate manager of the sim they are on. But someone who has no rights to an object can still effect that object by right clicking on it, (often spamming right clicks) it will either make the object micro stutter slowing it down or out right stopping the object in place for a brief moment.
Having a function that can detect a right click, much like you can with a left click, so that a script can tell you who is editing it would be very very helpful!
And / Or some kind of tag that would stop physical objects from stopping when right clicked / edited would be really cool too.
Log In
Chaser Zaks
-1
We already have issues with people complaining about having look at targets on them, and the paranoid bunch already have "touch detectors" on their avatars.
All this will do is make it impossible to right click people's avatars because people will cry and cry and cry whenever someone right clicks them to choose "View Profile", and they will insist "NO YOU WERE DERENDERING MY UNDERWEAR!!!!11". This will just add to the drama that already exists on SL, and worsen the platform's social aspect more than look at targets are.
We already have to work around look at target drama, PLEASE do not make us paranoid of right clicking people to view their profile.
I can understand why you want the feature
, but the reason you want it for is will represent maybe 5% of actual use cases, where a good 80% of the actual use case is people using it for drama purposes.Instead of detecting right clicks, what if LL fixes the issue at hand where it causes object jitter instead?
Maestro Linden
Emmy Bloobury after re-reading your post, I think what you're actually after is a bug report. The behavior you describe here should not occur:
I am not talking about a resident that has the person's edit rights, or estate manager of the sim they are on. But someone who has no rights to an object can still effect that object by right clicking on it, (often spamming right clicks) it will either make the object micro stutter slowing it down or out right stopping the object in place for a brief moment.
When a physical object is selected by an agent, the object's velocity should only be impacted if the agent has the ability to return the object (i.e. is the object owner, parcel owner, etc.), in which case the velocity is set to zero until selection is cleared. If the only agent selecting the object does not have this ability, then object movement should not be impacted.
That said, I'm having trouble reproducing your claim about velocity being impacted when an unprivileged user selects it. Here's what I tried:
- Rez a platform and scale it to <10,10,0.5>
- Rez a default box and create the script in my child comment in it
- Edit 'resetPos' so that the box will fall exactly 10m before hitting the center of the platform
- With no avatars selecting the object, say 'reset 'a few times and note the time and collision velocity each time
- Reset the script to clear the statistics
- Repeat the trials in step (4), but this time have a 2nd agent (who has no object return ability) select the object and maintain the selection.
- Reset the script to clear the statistics
- Repeat the trials in step (4), but this time have a 2nd agent (who has no object return ability) select and deselect the object rapidly
Maestro Linden
/* Report time for obeject to freefall a certain distance onto a platform, along with
the velocity and impact at impact time.
Say 'reset' in chat to make the object move to the position to reset itself before falling.
Position to reset to for dropping.
In this example the object is falling onto a <10,10,0.5> box platform located at <215, 105, 20.75>,
Such that a 50cm box should be at position <215, 105, 21> when it hits
*/
vector resetPos = <215, 105, 31>;
list drop_times = [];
list drop_vel_z = [];
default
{
state_entry()
{
llOwnerSay("After positioning the drop-platform properly, say 'drop' to run a trial");
llSetStatus(STATUS_PHYSICS, FALSE);
llListen(0, "", llGetOwner(), "drop");
}
listen(integer channel, string name, key id, string msg)
{
float delay = 2.0;
llOwnerSay("Resetting position to " + (string)resetPos + " and becoming physical after "
+ (string)delay + " seconds..");
llSetRegionPos(resetPos);
llSetRot(ZERO_ROTATION);
llSleep(delay);
llResetTime();
llSetStatus(STATUS_PHYSICS, TRUE);
}
collision_start(integer d)
{
float time = llGetTime();
vector vel = llGetVel();
llOwnerSay("Collided with " + llDetectedName(0) + " after " + (string)time
+ " seconds. vel=" + (string)vel
);
llSetStatus(STATUS_PHYSICS, FALSE);
drop_times += time;
drop_vel_z += vel.z;
llOwnerSay("After " + (string)llGetListLength(drop_times) + " trials, drop time has mean "
+ (string)llListStatistics(LIST_STAT_MEAN, drop_times) + " and std. dev. "
+ (string)llListStatistics(LIST_STAT_STD_DEV, drop_times));
llOwnerSay("Vertical velocity has mean " + (string)llListStatistics(LIST_STAT_MEAN, drop_vel_z)
+ " and std. dev. " + (string)llListStatistics(LIST_STAT_STD_DEV, drop_vel_z));
}
}
Maestro Linden
With no avatars selecting the object (step 4), I saw:
After 5 trials, drop time has mean 1.422209 and std. dev. 0.003139
Vertical velocity has mean -13.631900 and std. dev. 0.119273
With 1 avatar selecting the object the whole time (step 6), I saw:
After 5 trials, drop time has mean 1.423544 and std. dev. 0.000369
Vertical velocity has mean -13.588350 and std. dev. 0.194772
With 1 avatar selecting and deselecting the object a few times during the fall (step 8), I saw:
After 5 trials, drop time has mean 1.423567 and std. dev. 0.000258
Vertical velocity has mean -13.675450 and std. dev. 0.097386
I'm not seeing any significant difference in the physical object movement between the different trials. The tests in the last case were actually a bit faster, though well within the statistical noise floor.
What I _did_ observe is an apparent stutter of the object on the viewer of the avatar selecting the object. This appears to be some sort of rendering stall as the viewer renders the highlight on the object, loads the build tool UI for the object, etc. This stutter did not appear on other viewers.
Emmy Bloobury
Maestro Linden Hi Maestro! First, Thank you for taking the time to look into this as much as you have already! I'll admit I'm far from a master scripter, so some of what you've posted might be a bit lost on me. But I can share with you a video being able to do this. ( https://gyazo.com/7b65bd5382cc464d4406638b31e5fbb8 ) As you can see, it doesn't work every time, and I understand the gitterning being viewer based but I'm still able to completely stop the car sometimes. We've tested this with many different cars, not all of them do this.. but many do. It seems to happen most easily when the Driver is off the gas, and the car is coasting under it's own physics and no script force is being applied to the car in that moment. Maybe this is more likely to happen with heavier objects (a full mesh car with scripts) vs just a single prim.
But just to be clear, I'm not trying to report a bug, I am still asking for this feature to be added Please! <3 (Right Click Detection)
Alistar Snook
Maestro Linden Greetings Maestro, I am having different behavior following your instructions, std. dev. is totally different and I see the object blocked in world (I am currently on Beta Grid):
Test with 1 avatar selecting the object few times:
After 4 trials, drop time has mean 1.478061 and std. dev. 0.333817
Vertical velocity has mean -12.085790 and std. dev. 0.677050
Or in worst case, 1 avatar selecting the object whole time:
After 5 trials, drop time has mean 2.747472 and std. dev. 2.853173
Vertical velocity has mean -10.060600 and std. dev. 4.566257
I am seeing a std. dev > 0.5, quite suspicious.
Edit: I forgot to mention, I am on SLV.
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
chew Resident
Would a griefer enjoy knowing who's right-clicking objects to report or inspect them, or might they do anything to interfere when the right-click is detected? Could anything special be done to avoid this misuse of the feature?
Also, if this works on attachments, will this cause unwanted social interactions? For example, user Alice right-clicks user Bob to mute him because Bob makes Alice personally uncomfortable. Bob has a right-click detection utility, and is now encouraged to interact with Alice. Could anything be done to make this less likely?
Toothless Draegonne
chew Resident
Education. Using the Nearby List instead of right-clicking someone directly.
Or implementing /commands in the stock viewer. /mute [person]. /block [person].
Chaser Zaks
Toothless Draegonne That's not a solution. As someone who studies UX, if the instinctive way isn't the right way, it is wrong. You are basically asking people to jump through hoops to do it the "correct" way.
Toothless Draegonne
Chaser Zaks If Bob has a right click detection utility, then that's a Bob problem. Griffers gonna griff. If you're scared of doing anything because of the griff potential, then you might as well shut the platform down right now and turn the computer off because it's all one giant griff vector. Nobody's asking for a "crash their computer please" button.
This is on the same level as people wearing clickies and getting all huffy because people click them. If you don't want someone booping your snoot then it's within your power to make it unboopable.
Personally I would
really really like
to have some proper right-click functionality, for the same reason I would like proper 6dof controls and game controller functions. It is something the platform has been sorely lacking since its inception, and prevents a whole lot of fun being had, because... a few people might shout that their entirely removable pixeldong that is 5 seconds and an outfit change away, might get exposed by derendering?Education is very much a solution.
Alistar Snook
I'm not sure what happens to a running vehicle when it is edited by an external user, would be cool see it.
As mentioned by Lucia, with llGetObjectDetails() you are able to know when someone click/edit an object, but for vehicle stuff, I am wondering, as this is a trouble for racers, if VEHICLE_FLAG_BLOCK_INTERFERENCE might be extended also for click/edit to the object from an external users and not only by pushes with attachments.
Lucia Nightfire
Have you looked into llGetObjectDetails() and OBJECT_SELECT_COUNT?
Granted, this doesn't report when people are grabbing/moving, but does when left/right selecting.
This also doesn't report the UUID of the selector, but the server has that data.
Also, there is PRIM_CLICK_ACTION & CLICK_ACTION_IGNORE for SLPP*, but this only stops left/right clicks when the edit menu is closed.
Emmy Bloobury
Lucia Nightfire Thank you! this is helpful info! Though as you say both options are not quite what I am looking for. :\ But it's nice to know that something close already available and would (maybe..?) not be much work to do what I am requesting!
Bavid Dailey
if you ask for rigth click, it also makes sense to ask for middle click.
SpectralVR Resident
A secondary click detector could also help prevent users from rendering clothing on other avatars, thereby enhancing each user's privacy, but if not, just to physical objects like cars would be cool and enough