Talk:Touch start

On second sample...

I have two question about the comment in it:

• What is the meaning of "(discounting resets, deletions, taking to inventory etc.)" ? When the three cases, what will happen?

• "The average click will have you catapult through this state with nothing but a chatted message to remember it by." Can anyone tell me what it mean in easier English?

The touch_ chain will remain intact until either touch_end is triggered or a new touch_start. If however the script is reset (although there is some doubt as far as this is concerned (see the jira for more details)) the chain will be cleared. If the script is taken into inventory or deleted etc the touch_chain is cleared too. To be honest the caveat is quite complex since it is making reference to a long standing "bug". I quote since it is not certain whether the behavior is truly a bug or expected.

"The average click" means a normal click (not long or super rapid).

"catapult through this state" means you will be slung through. Fired through. Rapidly in and then rapidly out again.

"with nothing but a chatted message to remember it by" means that the only indication that you were ever in that state will be the chatted message in you communication history (since the script passes through that state so fast). -- Fred Gandt ^{(talk|contribs)} 23:57, 21 May 2010 (UTC)

Thank you for explanation. I moved the first block into "Notes" section, executed the example and rewrote the example section. As usual, I didn't care about the grammar lol - check and fix it! -- Mako 01:55, 22 May 2010 (UTC)

Dropped Touches

The touch_start article, (and also touch and touch_end) all claim that when a script returns to a state that has a touch, touch_start, or touch_end event, the first touch is dropped (not detected by any of these three events). My own observations differ. In fact, I have often heard this matter discussed on a number of scripting groups in-world, and the advice given has always been to use touch_end rather than touch_start in multi-state scripts in order to avoid this problem. I have always followed that advice myself, and have never been aware of a missed touch, and I often write multi-state scripts.

Today (Christmas Day, LOL) I decided to do some further tests, and my findings were that the "problem" is easily avoided by any of the following:-

1) Include an llSleep() within touch-start before changing state. llSleep(0.5) seemed adequate (probably needs enough time for mouse to be released).

2) Include a touch event in addition to the touch_start, and do the state change from the touch event.

3) Include a touch_end event either instead of, or in addition to the touch_start, and do the state change from within the touch_end event. This is the preferred solution.

Omei Qunhua 04:25, 25 December 2012 (PST)

The touch_start page includes a note :- ""Important: LSL has a problem with switching states so if you rely on high performance scripts, don't change states but use an integer to change your "mode" or something the like.""

I believe that to be out-of-date information. There was at one time a significant delay on changing states, but that has long been addressed. Either that, or the comment is based on mis-information surrounding the "dropped touches" issue. I plan to remove that misleading comment unless anyone can say why I shouldn't. :)

But in any case, I can't imaging why anyone would want to change states at a time-critical stage of proceedings :))

Omei Qunhua 11:24, 25 December 2012 (PST)