Scripts that fail to see touch events?

I have some scripts that work 100% of the time detecting touch events, and others that are intermittently failing. I've tried to isolate the issue in some simplified scripts:

This one works:
=====

// This script always detects the touch event properly.

default
{
state_entry()
{
llSay(0, "Entered default state";
state WaitForTouch;
}

touch_start(integer total_number)
{
llSay(0, "Touched while in default.";
state WaitForTouch;
}
}

state WaitForTouch // ready state
{
touch_start(integer total_number)
{
llSay(0, "Touched 1.";
state Action1;
}
}

state WaitForTouch2 // ready state
{
touch_start(integer total_number)
{
llSay(0, "Touched 2.";
state Action2;
}
}

state Action1 // ready state
{
state_entry()
{
llSay(0, "Does action 1.";
state WaitForTouch2;
}
}

state Action2 // ready state
{
state_entry()
{
llSay(0, "Does action 2.";
state WaitForTouch;
}
}


This one fails intermittently:
=====

// This script fails to detect the touch event intermittently.

default
{
state_entry()
{
llSay(0, "Entered default state";
state WaitForTouch;
}
}

state WaitForTouch // ready state for touch to perform action 1
{
state_entry()
{
llSay(0, "Entered WaitForTouch.";
}
touch_start(integer total_number)
{
llSay(0, "Touched 1.";
state Action1;
}
}

state Action1 // Code to perform action 1, then wait for touch to start action 2
{
state_entry()
{
llSay(0, "Does action 1."; // Code for action 1 would be here
state WaitForTouch2;
}
state_exit()
{
llSay(0, "exit state 1 actions."; //Additional code to be done as state changes
}
}

state WaitForTouch2 // ready state for touch to perform action 2
{
state_entry()
{
llSay(0, "Entered WaitForTouch2.";
}
touch_start(integer total_number)
{
llSay(0, "Touched 2.";
state Action2;
}
}

state Action2 // Code to perform action 2, then wait for touch to start action 1
{
state_entry()
{
llSay(0, "Does action 2."; // Code for action 2 would be here
state WaitForTouch;
}
state_exit()
{
llSay(0, "exit state 2 actions."; //Additional code to be done as state changes
}
}


===

Can anyone explain why the second one fails?

Another one that fails:
===

// This script eliminates the state_exit code, but also fails intermittently

default
{
state_entry()
{
llSay(0, "Entered default state";
state WaitForTouch;
}
}

state WaitForTouch // ready state for touch to perform action 1
{
state_entry()
{
llSay(0, "Entered WaitForTouch.";
}
touch_start(integer total_number)
{
llSay(0, "Touched 1.";
state Action1;
}
}

state Action1 // Code to perform action 1, then wait for touch to start action 2
{
state_entry()
{
llSay(0, "Does action 1."; // Code for action 1 would be here
llSay(0, "Other state 1 actions."; //Additional code to be done as state changes
state WaitForTouch2;
}
}

state WaitForTouch2 // ready state for touch to perform action 2
{
state_entry()
{
llSay(0, "Entered WaitForTouch2.";
}
touch_start(integer total_number)
{
llSay(0, "Touched 2.";
state Action2;
}
}

state Action2 // Code to perform action 2, then wait for touch to start action 1
{
state_entry()
{
llSay(0, "Does action 2."; // Code for action 2 would be here
llSay(0, "Other state 2 actions."; //Additional code to be done as state changes
state WaitForTouch;
}
}

You talking about touches and state changes brings this to mind:
http://jira.secondlife.com/browse/SVC-3017
Though as far as I can see, even your script one should be affected by this.

Nothing jumps out at me..

Are you trying to make these break by touching really fast? Like, could the touch be happening in one of the action states because you click quick?

edit: oooo.. Tali has a much better answer.

So, I just skimmed through the JIRA. Ceera, if you change the touch_start events to touch_end, do the scripts still screw up?

That does appear to be related, and the server code release they cite coincides with when I first saw this behavior. I had noticed recently that torches and some other things that I coded a long time ago, and which used to always work 100% on touch events, were now sometimes taking two clicks to activate. And yet other very similar scripts, toggling a curtain to open or close, were not being affected!

Meade: I tried touching really fast, and I tried counting to 100 between each touch. Still acts just as erratically on the ones that fail, and still perfectly on the ones that work.

Rolig, I'll try the touch_end option... Back soon.

// This script uses touch_end instead of touch_start, and seems stable

default
{
state_entry()
{
llSay(0, "Entered default state";
state WaitForTouch;
}
}

state WaitForTouch // ready state for touch to perform action 1
{
state_entry()
{
llSay(0, "Entered WaitForTouch.";
}
touch_end(integer total_number)
{
llSay(0, "Touched 1.";
state Action1;
}
}

state Action1 // Code to perform action 1, then wait for touch to start action 2
{
state_entry()
{
llSay(0, "Does action 1."; // Code for action 1 would be here
llSay(0, "Other state 1 actions."; //Additional code to be done as state changes
state WaitForTouch2;
}
}

state WaitForTouch2 // ready state for touch to perform action 2
{
state_entry()
{
llSay(0, "Entered WaitForTouch2.";
}
touch_end(integer total_number)
{
llSay(0, "Touched 2.";
state Action2;
}
}

state Action2 // Code to perform action 2, then wait for touch to start action 1
{
state_entry()
{
llSay(0, "Does action 2."; // Code for action 2 would be here
llSay(0, "Other state 2 actions."; //Additional code to be done as state changes
state WaitForTouch;
}
}

// Also uses touch_end instead of touch_start, and seems stable

default
{
state_entry()
{
llSay(0, "Entered default state";
state WaitForTouch;
}
}

state WaitForTouch // ready state for touch to perform action 1
{
state_entry()
{
llSay(0, "Entered WaitForTouch.";
}
touch_end(integer total_number)
{
llSay(0, "Touched 1.";
state Action1;
}
}

state Action1 // Code to perform action 1, then wait for touch to start action 2
{
state_entry()
{
llSay(0, "Does action 1."; // Code for action 1 would be here
state WaitForTouch2;
}
state_exit()
{
llSay(0, "exit state 1 actions."; //Additional code to be done as state changes
}
}

state WaitForTouch2 // ready state for touch to perform action 2
{
state_entry()
{
llSay(0, "Entered WaitForTouch2.";
}
touch_end(integer total_number)
{
llSay(0, "Touched 2.";
state Action2;
}
}

state Action2 // Code to perform action 2, then wait for touch to start action 1
{
state_entry()
{
llSay(0, "Does action 2."; // Code for action 2 would be here
state WaitForTouch;
}
state_exit()
{
llSay(0, "exit state 2 actions."; //Additional code to be done as state changes
}
}

Aha. It seems a shame to have to rescript things with touch_end just to get around whatever this bug is, but if this workaround is successful at least it tells you how to script in the future.

ETA: It's almost as if there's a time delay in a touch event, such that it hangs if you change state before the event is finished. Using touch_end would guarantee that the event is finished, whereas touch_start might not. Maybe?

So, can anyone explain why moving_end() is also screwed up? And please don't tell me that needs a matching "moving_start", when I only want the script to act when the linkset STOPS moving.

// ----- Global Variables ------------------
vector g_PrimPositionDetected; // Last detected prim position
vector g_PrimPositionNow; // Current detected position vector
rotation g_PrimRotDetected; // Last detected prim rotation
rotation g_PrimRotNow; // Current detected rotation vector
float g_PrimAltitude; // Extracted Z-height now

default
{
on_rez(integer param)
{
llResetScript();
state WaitForCommand;
}
state_entry()
{
state WaitForCommand;
}
}

state CheckStatus // Detect Status
{
state_entry()
{
llSay(0, "Checking prim position and rotation.";
g_PrimRotNow = llGetRot();
g_PrimPositionNow = llGetPos();
// llSay(0, (string)g_PrimPositionNow + " is the current prim position";
// llSay(0, (string)g_PrimRotNow + " is the current prim rotation";

if (g_PrimPositionDetected != g_PrimPositionNow | g_PrimRotDetected != g_PrimRotNow) // Prim has changed, update position
{
llSay(0, "This prim was moved or rotated, resetting information";
//llSay(0, (string)g_PrimPositionDetected + " was the previous prim position";
//llSay(0, (string)g_PrimRotDetected + " was the previous prim rotation";
g_PrimRotDetected = g_PrimRotNow;
g_PrimPositionDetected = g_PrimPositionNow;
g_PrimAltitude = g_PrimPositionNow.z;
//llSay(0, "Position updated to " + (string)g_PrimPositionDetected);
//llSay(0, "Altitude is calculated as " + (string)g_PrimAltitude);
//llSay(0, "Rotation updated to " + (string)g_PrimRotDetected);
state WaitForCommand;
}
else // Prim position has not changed
{
llSay(0, "The position and rotation have not changed";
state WaitForCommand;
}
}

}

state WaitForCommand // ready state
{
state_entry()
{
//llSay(0, "Waiting for command";
}
touch_end(integer total_number)
{
llSay(0, "Touch detected, checking information";
state CheckStatus;
}
moving_end()
{
llSay(0, "Movement detected, checking information";
state CheckStatus;
}

}

With the above, the touch event now correctly reports the position, rotation and altitude of the prim the scipt is in, whenever it is touched. But the moving_end event frequently fails to trigger when the linkset is moved. Precisely the same sort of event failure that was happening with touch_start.

Well, not *explain*, but: http://jira.secondlife.com/browse/SVC-1004

Theoretically, move_end shouldn't trigger unless the prim's position has changed. Changing rotation alone shouldn't do it. I assume, though, that you have been testing the script by moving it, right?

With that last script, I've tested it by moving on the X, Y or Z axis, and encountered completely inconsistent results, as noted in JIRA SVC-1004, which apparently had been reported and remains unresolved since 2007???

What I was trying to do with that last one was script an elevator shaft for use in a skybox, so it would know the shaft moved and could recalculate the position and rotation and altitude (parsed from position) so the elevator car could be recalled to the "ground floor" position and aligned properly, and so the scripts in the elevator car could adapt to the new altitude.

At this rate, I will have to use a "Reset elevator" button somewhere, to get it to do that, since the LSL for detecting the prims were moved isn't reliable, and I don't want to poll position for a move that likely will only take place on setup and when the skybox owner re-aranges their parcel layout.

record position after setup, and then check it whenever some other code runs (like the elevator goes up)?

Yeah, I guess. The problem with that is it requires running that check when 99.95% of the time nothing has changed.

The only time it would be necessary to recalibrate the elevator would be if the shaft it was supposed to be in has been moved. Like someone moved the skybox from 700 M to 3000M, leaving the car hovering at 700M. Then it needs to summon the elevator car, directly and non-physical, to the new ground floor location, centered in the shaft, and change the base altitude variable for the elevator car script. Presumably this recalibration would also compensate if the shaft is rotated - to make the car face the right way in the shaft.

Right now I am looking at storing a bunch of other variables when the elevator is configured, so I'll keep working on this.

ya know, I had a thought.... a timeout after a move start event could probably be just as effective.... with a warning to the user of when it'll auto reset some thing (move detected, elevator will reset for new position in x seconds. countdown will reset if moved again before then).... it's ugly, but workable..

then again, a variable check it's a HUGE overhead

though I agree, neither *should* be necessary.