Thanks to Simon Kline’s One-Prim HUD class, a basic but worthwhile introduction to the llDetectedTouchUV() function, I have spent the last couple days experimenting with tracking my position as I touch and drag across the surface of a cube. I employed the heretofore-seldom-used-by-me touch() event. No, not touch_start(). Touch(). This event fires continuously as you hold down the mouse button. Touch_start() fires once upon mouse-down, touch() fires continuously on mouse-hold, and touch_end() fires once upon mouse-up. The sequence does make a certain amount of sense.
During my experiments, I came across a situation where I was holding down the mouse button on an object while another object was moved to interpose itself between my camera view and the object I was supposedly touching.
What happens to the touch events in this situation? Since I am now holding my mouse down over another object, do the events cease? Do new events register on the obscuring object? I decided to find out, and the results surprised me.
Try it for yourself. Rez two cubes. Change their names: I called mine Root and Child. Then place the following script in each:
[lsl]
default {
touch_start (integer numDetected) {
llSay (0, "I have started a touch.");
}
// ——————————————————-
touch (integer numDetected) {
llSay (0, "I am continuing a touch.");
}
// ——————————————————-
touch_end (integer numDetected) {
llSay (0, "I have ended a touch.");
}
}
[/lsl]
Test these by touching and dragging across a surface of each prim. You’ll see one announcement for touch_start(), several announcements for touch(), and one last announcement for touch_end().
Now, move one prim in front of the other, partially obscuring it; I performed this by altering my camera position instead of moving the objects themselves. Mousedown on one prim, drag across to the other, and release your mouse over the other prim.
Notice the announcements in chat. No matter if you move to an obscuring prim, no matter if you move across prims that aren’t even touching, no matter if you release your mouse over land, all touch events (touch_start(), touch(), and touch_end()) occur in the proper sequence and are registered only with the prim where you began the sequence. By calling llDetectedTouchUV(), you can track your mouse’s coordinates on the prim when you can’t even see the object.
I get the same results whether the objects are linked or not, whether I compiled the scripts with the old LSL engine or Mono, or whether I’m using an official SL viewer or the Emerald viewer. Though these results surprised me, at least they’re consistent and repeatable, which I find very consoling.
The next question is, of what value is a touch_end() occurring off the prim? Well, that’s when you might call llDetectedTouchUV(), which will return valid coordinates on the prim, but component values of -1 off of it—again, even when the prim is obscured from view. You can see these coordinates by substituting the following event routine in your touch script:
[lsl]
touch (integer numDetected) {
vector point = llDetectedTouchUV (0);
llSay (0, "I am continuing a touch at U = " +
(string) point.x + ", V = " + (string) point.y);
}
[/lsl]
At least you can now tell when your mouse is off the prim, whether you can see it or not.
I have decided that this phenomenon, though initially unexpected by me, is highly desirable. In this manner I can direct actions to occur depending on my touch position upon the prim, and as long as I don’t let go, I can even obscure my view with other objects.