Click on object: Modifiers possible?

[Domitan Redenblack]

For in-world objects, click, and <combinations of shift, alt and ctrl> + click are all "taken" and not detectble inside LSL scripts, right?

At touch_start (etc) are there any modifiers that can be detected when user clicks on it? Any key-down detection? What other user actions can be detected.

 

 

 

[Freecilla Kuhn]

People usually add a menu so when something is clicked many other options come up in the menu to do many other functions. Also there are all kinds of cars and such that use a great variety of keys, walking keys to move and steer, page up/down for gears, arrows for turbo but one has to sit on it to use all of those controls. I really don't remember ever using shift or alt to use on an object though other than in the building tools of course.

[Void Singer]

no modifier keys, but you can detect double clicks and held clicks by checking and comparing  with llResetTime and llGetTime.

I use held click for many infrequent use menus, on top of regular clicks for other actions, search for the "ghost prim utility" in the LSL Library forum for an example (i'd link but my net is flaky right now and I'm trying to open as few pages as possible, stupid ISP)

[Domitan Redenblack]

---

Void Singer wrote:

no modifier keys, but you can detect double clicks and held clicks by checking and comparing  with llResetTime and llGetTime.

I use held click for many infrequent use menus, on top of regular clicks for other actions, search for the "ghost prim utility" in the LSL Library forum for an example (i'd link but my net is flaky right now and I'm trying to open as few pages as possible, stupid ISP)

---

Ah yes, held clicks sounds good. I assume this would involve the use of the events start_touch followed by touch ?

This fails if more than one person touches the prim though? I would need to ignore multiple touchers...

And double-click, etc, may fail in laggy sims?

LSL Library forum?

 

 

 

[Void Singer]

touch_start and touch_end, reset the time in the first, check it in the second, if it's over your limit, it's a held click, otherwise, treat it as a normal click.

I don't recommend using double click logic because the viewer intercepts double click if the user has "double click to: [Teleport | Navigate to]" set in their preferences

[Domitan Redenblack]

---

Void Singer wrote: touch_start and touch_end, reset the time in the first, check it in the second, if it's over your limit, it's a held click, otherwise, treat it as a normal click.

---



I would need to check to see if touch_end is by same person as touch_start ?

    touch_start( integer vIntTch ){        llResetTime();    } //-- touch-hold trigger setup        touch_end( integer vIntTch ){ //-- only take touches from same group        if (llGetOwner() == llDetectedKey( 0 ) || llDetectedGroup( 0 )){            if (llGetTime() > 1.0){ //-- check if theis is a held touch and die                llDie(); //-- provided in case a person has deed power but not return/mod for group items or something somehow fails            }else{ //-- otherwise it a normal touch and we run detection                uDetectGhosts();            }        }    }

 

[Void Singer]

you can, but to do it that way you'd need to save the toucher and the time (rather than reset it), and then compare current time to that touchers saved time. unless the item is likely to be under heavy use by people other than the person calling the held touch, it's not likely to be interrupted. I most often use it for configuration type menus, for instance door locks, where a normal touch opens or closes it, and the held touch locks it gives options to a limited access group... the other use case that I often implement it for is to prevent accidental clicks doing things that a use might not intend (such as killing the object, or opening a menu they don't care about)

[Domitan Redenblack]

---

Void Singer wrote:     you can, but to do it that way you'd need to save the toucher and the time (rather than reset it), and then compare current time to that touchers saved time. unless the item is likely to be under heavy use by people other than the person calling the held touch, it's not likely to be interrupted. I most often use it for configuration type menus, for instance door locks, where a normal touch opens or closes it, and the held touch locks it gives options to a limited access group... the other use case that I often implement it for is to prevent accidental clicks doing things that a use might not intend (such as killing the object, or opening a menu they don't care about)

---

Excellent, Void, thanks!