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 just including a touch_end event in the state caused the touch_start to also be triggered appropriately. Without a touch_end, the touch_start was consistently missed on returning to that state (not missed the very first time the script was executed).

Further tests suggest that the problem is timing related, and only occurs if a state change is issued within a touch_start() event. The following all appeared to avoid the issue:-

1) Include an llSleep() within touch-start before changing state. llSleep(0.5) seemed adequate.

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 in addition to the touch_start, and do the state change from the touch_end event

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