How can 2 scripts in same prim, both touch activated get out of sync?

I created an armadillo that walks around in a circle, to reduce the number of scripts used, I animated only his legs with Pupetteer scripts and put it on a rotating disk that uses llTargetOmega to rotate. Both Puppeteer and the rotation script use touch as the event to turn them on and off. I have been leaving the scripts running at my store, but frequently return to find that the armadillo has either stopped rotating or the legs are moving or vise versa.

If someone touchs the armadillo it should turn both scripts on and off at the same time. I'm really puzzled how a touch event could be sensed by one script and not the other when they are in the same parent prim.

Here is the target omega script.

//Notes from Wiki on TargetOmega
//llTargetOmega(vector axis, float spinrate, float gain)
//llTargetOmega (<x,y,z>
//spinrate in radians per second
//gain must be none-zero for non-physical objects
// The rotation speed is based on the axis vector multiplied by spinrate

default 
{   
	state_entry()
	{
		llSay(0, "Touch the Armadillo to turn movement on or off");
		//llSay(0, "Say /1 on or /1 off to show/hide the floating text");
	}
	touch_start(integer total_number) 
	{	
	llSay(0, "movement on");
	llTargetOmega(<0,0,1>,0.1,1);
	state off; 
	} 
} 

state off 
{ 
	touch_start(integer total_number) 
	{
		llSay(0, "movement off");
	llTargetOmega(<0,0,0>,0,1); 
	state default; 
	} 
} 

When you come back and find that it's stopped but the legs are still moving, what happens if you right-click on it? Does it start moving again? If so, the problem may be gone later today (or tomorrow)...

http://blog.secondlife.com/2008/02/04/rolling-restart-this-week-wednesay-or-thursday-feb-6-7/

Just a guess, but maybe they two scripts process simultaneous touches differently? Perhaps one counts the number of touches and the other (yours) does not? Then every once in a whle if, say, an even number of people happened to touch the object in the same server frame, the scripts might behave differently. This would likely be exaggerated if the scripts are calling functions that impose a lot of script delay (I suspect "Pupetteer" does), in which case the chance for multiple touchers in a single event goes up dramatically.

Oh. Yeah. Good point Sindy. llTargetOmega() is not (EDIT: NOW! Grr) buggier than ever.

Yes, usually the disk starts rotating, but the legs stop moving, it becomes out of sequence. I touch it again and the disk stops rotating but the legs stop moving. It is clearly out of sequence. I usually have to reset the TargetOmega script to get them back in sequence.

Sometimes after resetting the script, I touch the disk but it does not rotate at all unless I select the object so its highlighted then deselect it, only then will it start rotating.

Good point on the there being a bug in SL with TargetOmega. Its all very peculiar, I realize that targetOmega is a client side phenomena so that may make it even more buggy.

Oddly enough a similar animated spider monkey that I made, which I chose to turn on and off with a chat command, does not seem to go out of sequence like this, or at least I have not seen it do so yet. It may be more immune since other people touching it does not change it.



What you are suggesting is entirely possible, my attempts to make the scripts go out of sequence by repeatedly touching it have not worked. It only seems to happen when I am away for awhile. Maybe TargetOmega is just not visible on my client when I return.

Ahhh this jira item does sound like the same problem, TargetOmega not updating until the avatar interacts with the object.

https://jira.secondlife.com/browse/SVC-54

Not touch - just right-click on it when you think it should be moving but isn't.

edit: doing a right-click on anything triggers a full object update. Things that are interest list problems (like the target omega problem may be) get "fixed" with a right click because the sim resends the entire object to everybody around. Turn on Show Updates and right-click a few things to see this in action..

Scripts will, over time, get out of sync so you may want to build in some sort of periodic auto-sync through link messages.

there is a chance, that given a longer processing time in one script (and a difference in touch handler style) might cause a difference in the queues... fo example if one triggers quiclkly it'll pick up a repeat click by an av, whereas if the other is queued, it'll only queue a single click from an av.

best practice if you want both to trigger together on touch, have only one handle the touch, and message the other with the current action