Touch events

I'm curious... Perhaps someone knows the answer to this.

LSL has events for touch_start, touch, and touch_end. Yet, when I create a script with all 3 events, it seems that a "touch" event has no duration. I either left-click the object, or right-click/Touch it, and the object is instantaneously touched, and the 3 events all trigger in succession.

Is there a reason for all 3 events?

- Ace

Hold down the mouse when you click, touch_end() should only fire after you release. Use just touch_start() for a basic click detect. Use touch_start() / touch_end() for complex controls that time how long you held down the mouse button.

basically because there are in fact three states to a mouse button, but that has already been mentioned. I have written code that exploits the multi-stage touch to detect when multiple AVs are touching an object...And no, I've never seen any of the touch params be other than 1 :-/

THe annoying thing is that touch sequencing is brittle. I've run quite a few tests and found that sometimes it works like a champ and sometimes not. I suspect that there are prop-delay/client issues that come into play here. It was very disappointing when my gift suddenly didn't work for a different AV pair. I'm planning to re-write the thing based on a timer, but that would mean revisiting a bitter memory...

With a little experimentation, I'm as confused as ever.

It seems that touch_end() sometimes waits for the mouse to be released, and sometimes doesn't.

It seems that the touch() event is always only triggered once, no matter how long the mouse is depressed.

I only played around with this in one sim (Hooper), so it may vary by sim and sim-load. But I don't see how one could possibly script for variable length left-clicks on an object.

- Ace

On a related issue, i've been having trouble with taking the left mouse button as a control. Alot of the time the client doesn't get the mouse up event so the client things my mouse button is being held down. (I use this with my hacked motorcycle to get unstuck from sim crossings; resulting in my bike (and me) flying up into the air 10 meters at a time).

I'll be bug repping this after I play with it a bit more but I just set up a quick test on this. I was planning to use all three touch events together in a piece of a project I'm working on now but from what I've seen in this thread and from my own tests, I guess it's not possible at this point. The code I used (very very quick)

default
{
    state_entry(){
        llSay(0, "Script Ready");  }

    touch_start(integer total_number)  {
        llSay(0, "Touch_Start Triggered.");  }
    
    touch(integer total_number)  {
        llSay(0, "Touch Triggered.");  }
    
    touch_end(integer total_number)  {
        llSay(0, "Touch_End Triggered.");  }
}

This will usually produce the following output
However, at times, it does somewhat work. I'll get one message that touch_start was triggered and then only 3-5 messages from the touch event (regardless of how long I hold the mouse button down) followed by one that touch_end was triggered . Once or twice it has worked as expected but that was by far not the norm of the results.

I tried a few different shapes/sizes for the prim the script was in just on the off chance that it mattered but it doesn't. Have these events ever worked right? My guess is the results for these events vary a lot from client to client. :-/

Anyway, just thought I'd throw my results out there. HTH somehow.

-Meiyo

Sorry for the back to back posts but after experimenting a bit more, I came across a perfectly reliable (for me at least) way to use both the touch_start and touch_end event. I wouldn't be suprised if this is old news to some people tho. Anyway, I just put the touch_end in a different state from the touch_start.

default
{
   touch_start(integer total_number) {
        llSay(0, "Touch_Start Triggered.");
        state look_for_end;   }
}


state look_for_end
{
    touch_end(integer total_number)    {
        llSay(0, "Touch_End Triggered.");
        state default;    }
}

-Meiyo

Hmmmm...

State conditions shouldn't mean squat. An event is an event is an event, and if there is an event handler when your script is in a given state, LSL shouldn't care.

I'm gonna play around with this some more, given Kelly's comments about how subsequent "detected" events from the same source won't result in multiple events to a script. Thank goodness for multiple computers and at least one alt account.

- Ace