HEADS UP: Where touch becomes a loop!

This is a heads-up as twice in the last two weeks I've had a strange thing happen with public objects with a touch event in. Basically, both times, somebody touched the object and this sent the touch event into an infinite-firing loop, firing with the same detected avatar each time. Wouldn't be so bad, but this touch event triggers llGiveInventory to give a notecard so obviously the two people who's touch got stuck in a loop were getting notecards sent to them over and over again. Even logging out didn't stop it for them. The only solution I've been told that works is resetting the script.

Both Lindens that have helped deal with these incidents confirmed that this is indeed a known issue and the only part explanation that I've had is that it's believed to be caused by lag between the client and the server which then triggers the server to go into this infinite touch loop. From what they're saying it appears to be fairly rare, so I guess I've just been unlucky that it's happened twice in a couple of weeks.

So, just a heads-up that this can happen and is known about by the Lindens in case you're getting any touch weirdness yourselves.

Thanks Moopf, is this just using touch(..) or is it using touch_start( ... ) ?

or doesn't it matter ?

I never use the touch event I always use touch_start() and I've never experienced this at least not yet anyway.

It sounds similar to what happens in the collision() event, using collision_start instead when you only want a single event seems safer.

LSL is getting scarier by the minute, the recent confirmation that object_rez can fire before the object has rezzed and the problems i'm having with rezzing linden plants and llGiveInventory failing .... oooerrrr

Hmmm, that's a good point you know. I think I'm using touch in this instance, so I'll change this to touch_start and see if it still happens (mind you, it appears to be so rare that it will be difficult to tell if it's made any difference!)

Interestingly, until the last 2 weeks I'd never experienced any problems with touch or touch_start

I was testing a physical elevator script and even though I took out llTarget code the not_on_target code still fired and continued to fire in some sort of loop. I knew it fired because of the llOwnerSay statement in it. I reset the script, nothing stopped, set the script to not running, still kept going, did the "take" thing after renaming, it stopped. Rezzed it again and unclicked the run button, still going. Then deleted the script, still going. Re-edited, renamed, retook, still going. Tried shift splitting the design, renaming, took it again and rezzed each version separately, both still going. Both also using the original name in front of each chat line and ignoring my renames.

Eventually called live help. Ethan Linden turned up, told me to derez with a take, and of course that stopped it. Problem is that I now have a structure that I have to restart from scratch because any modification and copying just produces more sources of chat that have become very annoying.

Even now re-rezzing the linked set brings out the original stream of llOwnerSay chat, still preface with the original name (that object now deleted several generations ago.

Hopefully the server reset with 1.10 will stop this particular bit of code!

The difference between the touch_start and touch events is that the latter continually fires while the toucher is holding down their mouse button. I guess if there is some kind of packet loss at just the wrong moment, and the server never gets the mouse-release notification, maybe the touch event continues to trigger. It'd be a good idea to use touch_start() for stuff like this... cause your giver would give multiple notecards even if someone just holds down the button for a second. I can really only think of a few instances where touch() is useful.

Yes, I completely agree but in this instance I did use touch() (an oversight on my part, admittedly as I do normally use touch_start) however, I wouldn't expect the server to keep triggering the touch even when the user logs out. Either way I'd suggest it's something that LL should add to the bug queue and I posted it here because it's an easy "gotcha".

Completely off-topic, but did you take the thread name from from that Orbital song? I keep hearing it in my head now -

"There is the theory of the mobius - A twist in the fabric of space, where time become a loop.





[LEFT].........................................where time become a loop.[/LEFT]

[LEFT].........................where time become a loop.[/LEFT]

[LEFT]........where time become a loop.[/LEFT]

[LEFT]....where time become a loop.[/LEFT]

[LEFT]where time become a loop.[/LEFT]

[LEFT]....where time become a loop.[/LEFT]

[LEFT]........where time become a loop.[/LEFT]

[LEFT].........................where time become a loop.[/LEFT]

[LEFT].........................................where time become a loop.[/LEFT]

I was inworld with Moopf and witnessed one of these incidents. I'm going to check around and ask for more insights on this...

Fran, that's one of my fave albums. RIP Orbital.

hehe, yes indeed I'd been listening to Orbital II (the brown album) earlier this morning.

I have noticed some weirdness with touch events as well. I made a particle system tester script for a project I was working on the other day. I put the llParticleSystem call with the "on" params into touch_start and an empty "off" llParticleSystem([]); call in touch_end. There were many situations where the touch_end event would never fire on releasing the mouse button, so the particle stream would not stop flowing. My guess is that there is a bug in the reporting of the touch_end event from the client to the server which causes the event to get lost.

Yes, touch_end and collision_end are extremely unreliable, best to avoid using them I've found.

Moopf, did you throw a llSetStatus(STATUS_BLOCK_GRAB, TRUE) in the state_entry() of each state where you experienced this problem? I was having some very strange issues with touch_start() earlier this week and doing that solved it. Looks like an old bug either never got fixed properly or it's back.

I've just experienced a really weird problem with touch_start. Basically, I've got a touch_start in a child prim (it's a button). Was working fine and then, all of a sudden, without changing anything, when the child prim was touched, rather than the touch_start in the child prim script firing, the touch was being passed onto the parent's touch_start event. The other buttons were working fine and were executing the touch_start locally in their scripts.

I recomplied the script, altered the script, pleaded with the script but nope, SL didn't want to recognise that it had a touch_start in.

The only way I could get it to work again was to remove the script and create a new script, copying in the previous contents of my script. And now the touch_start is being picked up again in the child prim!

I can't find any rhyme or reason why this should be (I hadn't de-linked and re-linked the object or changed the script in the child prim before this) but might be something else to look out for.

I hit this exact problem the other day! And like you, I recompiled, edited, recompiled, screamed, the works - nothing.

Funny - it went away when I set the script to running *blush*

Somehow I'd managed to clear the running state in it...

hehe, yes I've been caught out by that before (there used to be a bug I seem to remember that would stop a script from running but not sure if that's still around). Anyway, the script was definitely running and other events were being picked up correctly in the script - just not touch_start for some reason.