[#SVC-1039] llResetScript() from a state without a touch_start handler does not re-enable touch in default state

2. Second Life Service - SVC

llResetScript() from a state without a touch_start handler does not re-enable touch in default state

Created: 18/Jul/07 08:20 PM Updated: 25/Aug/09 02:57 PM

Component/s:

Scripts

Affects Version/s:

1.25 Server, 1.27 Server

Fix Version/s:

None

Issue Links:

Duplicate

This issue is original of duplicate:

~~SVC-1485~~ Script reset while in a script state without a touch event breaks touch events until recompile.

Relates

This issue Relates to:

VWR-4158 The prim is draggable like Ctrl-Drag when state changing in touch/touch_start event and next state do not have touch_start/touch/touch_end event.

This issue is related to by:

SVC-3017 Server drops first touch event when a script returns to a state with a touch_start handler

Linden Lab Issue ID:

DEV-2856

Sub-Tasks:

All

Open

Sub-Task Progress:

~~Script reset while in a script state without a touch event breaks touch events until recompile.~~

Resolved

Unassigned

Description

« Hide

Upon llResetScript(), a touch_start handler in the default state is not restored completely when transitioning from a state without a touch_start handler. In this condition, the touch_start handler can be invoked from the pie menu, but not by touching the prim, and the "touchable" cursor does not appear. The expected behavior does, however, obtain when the script is manually reset. (Related discussion: http://forums.secondlife.com/showthread.php?t=197465.)

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Lex Neva added a comment - 19/Jul/07 09:09 AM

Interesting find. I think I might have run into this in the past without even realizing it.

[ Permlink | « Hide ]

Strife Onizuka added a comment - 19/Jul/07 07:03 PM

I'm pretty sure I have heard of this before and just chalked it up to "screwy things LSL does and that will never get fixed"

This probably requires a one line change in the definition of llResetScript() and llResetOtherScript()

[ Permlink | « Hide ]

McCabe Maxsted added a comment - 21/Jul/07 08:07 PM

Huh. Always nice to know it wasn't my script's fault after all.

[ Permlink | « Hide ]

Rock Vacirca added a comment - 23/Sep/07 06:16 PM

This bug affected my script too. Had to place a blank touch_start handler in the state that called the llResetScript() to get it to work (tip courtesy the scripting tips forum). This is not right folks, it should be fixed.

[ Permlink | « Hide ]

Joshua Linden added a comment - 06/Dec/07 01:41 AM

Should go out with the 1.19.0 server update, late December '07

[ Permlink | « Hide ]

Lex Neva added a comment - 06/Dec/07 01:45 AM

"Should go out with the 1.19.0 server update, late December '07"

Thanks for the estimate! There's been a lot of unrest on JIRA about the use of the "fixed internally" resolution... people have a feeling that LL strands issues in "fixed internally" forever and doesn't get around to actually releasing the fixes. People also tend to reopen issues resolved like this because they see the word "resolved" and "fixed", but they still experience the issue. Estimates of the release fixes would be really helpful – even rough estimates.

[ Permlink | « Hide ]

WarKirby Magojiro added a comment - 22/Dec/07 01:28 PM

This issue has been bulk changed to fix pending.

[ Permlink | « Hide ]

Harleen Gretzky added a comment - 30/Jan/08 05:23 PM

Tested with the below script on a 1.19.0.78817 server, appears to be fixed as the script restores the touch handler.

default
{
touch_start(integer n)

{ state other; }

}

state other {
state_entry()

{ // Do something. llOwnerSay("zzzzzz"); llSleep(5.0); llResetScript(); }

}

[ Permlink | « Hide ]

Harleen Gretzky added a comment - 30/Jan/08 06:27 PM

Changing back to Fix Pending since server 1.19 was rolled back.

[ Permlink | « Hide ]

Strife Onizuka added a comment - 27/May/08 04:21 PM

This issue also effects scripts being reset by client, via menu or button. See ~~SVC-1485~~ for description.

[ Permlink | « Hide ]

Sigma Avro added a comment - 27/Aug/08 03:07 PM

Thank you Harleen; this works perfectly

[ Permlink | « Hide ]

Nava Muni added a comment - 06/Feb/09 08:39 AM

There's been no activity/comments on this problem since mid-2008.
There was a posting by Joshua that a fix would be rolled out in 1.19
We're up to server 1.25 and client 1.21 and this problem continues to exist.
Yes - there's a work-around - include a touch_start() in all states (even if it's empty).
Regardless - a lot of time has passed since 1.19 when this problem was noticed.
That's a lot of user content that's been released with a memory-consuming "work-around" installed.

[ Permlink | « Hide ]

Jord Aeghin added a comment - 20/Mar/09 12:54 PM

see solution how to correctly transition between states related to "touch_start(){;}" and "touch_end {;}" event chains at https://jira.secondlife.com/browse/SVC-3017

[ Permlink | « Hide ]

Qie Niangao added a comment - 25/Aug/09 01:28 AM

Just revisiting this (following some discussion on the linked SVC-3017) and confirming the problem still obtains on 1.27.2.129782. As Strife mentioned in May '08, even manual reset does not restore the touch_start handler, in contrast to my original report which I believe was accurate at the time (about a year earlier); also, the pointer does change to "touchable" now, again different from what I observed two years ago.