WTF with that test script

[TrybALSpiriT Manga]

Hello, i don't understand why, when you stay cliked on, you can move the prim. Don't know if it's normal or not. thx for replies

 

default{
    on_rez(integer pParams){
        llResetScript();
    }
    state_entry() {
        llSetTimerEvent(0);
    }
    touch_start(integer total_number) {
        llSay(0, "Touched.");
        state test;
    }
}

state test{
    on_rez(integer pParams){
        llResetScript();
    }
    state_entry() {
        llSetTimerEvent(120);
        llSay(0, "In test.");
    }
    timer(){
        state default;
    }
}

 

[Dora Gustafson]

Move the prim? In what way?

A piece of advise: Never change state in touch_start event! Replace it by a touch_end event handler

:smileysurprised::smileyvery-happy:

[revochen Mayne]

I only know such a prim behaviour if the prim/object has physics enabled and has nothing to do with scripting.

[steph Arnott]

You have either set the object to physical in the objects edit check box or another script has set it to physical. The mouse icon instead of being an arrow will be a hand.

Running timers persist on state changes. So you need to zero the 120s at state change. Getting into the habit of using different states unless absolutely necessary is not good. Best to struggle now getting this into one state rarther than later,

default{	on_rez(integer Params)	{		llResetScript();	}	state_entry()	{	}	touch_start(integer total_number)	{		llOwnerSay("Touched.");//i changed to ownersay becouse i see no		//reason to spam others with this message		llSetTimerEvent(120.0);		llOwnerSay("In test.");	}	timer()	{		llSetTimerEvent(0.0);		llOwnerSay("test finished");		state default;//EDITED: This script does not need this, but in some circumstances it would.	}}

 Only want one toucher at a time,

integer touched = TRUE;default{	on_rez(integer Params)	{		llResetScript();	}	state_entry()	{			}	touch_start(integer total_number)	{		if(touched)//have not been triggered allready, so do code.		{			llOwnerSay("Touched. Timer running.");//i changed to ownersay becouse i see no			//reason to spam others with this message			llSetTimerEvent(120.0);			touched = FALSE;		}	}	timer()	{		llSetTimerEvent(0.0);		llOwnerSay("Timer count finished");		touched = TRUE;	}}

 

[TrybALSpiriT Manga]

Sorry for my bad english, just i want to say with that script, if you stay cliked on prim when it is on default state it goes on test but if mouse stay cliked, it have a small bug (you can move the prim) without any tool.

---

Dora Gustafson wrote:

Move the prim? In what way?

A piece of advise: Never

change state in touch_start

event! Replace it by a touch_end event handler

:smileysurprised:

:smileyvery-happy:

---

That's the cause. But strange bug result.

Thx for replies

[steph Arnott]

That script could not possibly move the prim unless it was already physical, also you still have the timer in an infinite loop.

Struck as incorrect. I forgot about prim drag on state changes and touch event handlers not being cleared.

[TrybALSpiriT Manga]

Please, test that script, click one time ... you see "touched" then stay mouse clicked until the script say "on test" then move your mouse and see you can move that prim without any tool build just with the mouse !

 

I never said i want that script move my prim but Dora stipulate never change state on touch_start event, so it appear a small (knowed) bug but that bug is very strange and allow prim to move with mouse (if stay clicked).

 

thx for your participation

[steph Arnott]

What you are referring to is not a bug, it is because there is no clearing of the touch event when it changes states. The known bug Dora refers to is something else entirely. I did say that there is no need to switch states but if you have to you should clear the event handler. If you just use the touch_end the script can lock.

default{	on_rez(integer pParams)	{		llResetScript();	}	state_entry()	{		llSetTimerEvent(0);	}	touch_start(integer total_number)	{		llSay(0, "Touched.");	}	touch_end(integer total_number)	{		state test;	}}state test{	on_rez(integer pParams){		llResetScript();	}	state_entry()	{		llSetTimerEvent(120);		llSay(0, "In test.");	}	timer(){		state default;	}}

 

 

[TrybALSpiriT Manga]

That's explain my mystake. But accord me that's strange to move that prim.

 

Thx for reply

[Dora Gustafson]

When you touch an object you trigger three events: touch_start, touch and touch_end in a row

All three of them 'belong' to one state no matter if the state has event handlers for all events

When you change state in a touch_start or touch event handler, the touch_end event becomes 'homeless', it has nowhere to go

That's why it is only safe to change state on the last occurring event: the touch_end event

:smileysurprised::smileyvery-happy:

This of course is not the full story but its good enough to paint a picture

[LepreKhaun]

---

Dora Gustafson wrote:

When you touch an object you trigger three events:

touch_start

,

touch

and

touch_end

in a row

All three of them 'belong' to one state no matter if the state has event handlers for all events

When you change state in a

touch_start

or

touch

event handler, the

touch_end

event becomes 'homeless', it has nowhere to go

That's why it is only safe to change state on the last occurring event: the

touch_end

event

:smileysurprised:

:smileyvery-happy:

This of course is not the full story but its good enough to paint a picture

---

That is incorrect.

 

When a state change is executed, the event handlers specific for that state are registered. This registration is what determines which event messages are entered into the (newly cleared) event queue. The three stages of touch are independent of each other and have no bearing on each other.

 

The following illustrates this, a touch of short duration results in the touch_end event handler in state test not being registered before it happens, so it is ignored. If the touch is held long enough for the state to fully transition, touch_end will trigger.

// Short touch will go from default to test,//   touch_end event is lost// Long touch will result in default -> test -> default,//   touch_end event is triggered.default{    state_entry(){         llOwnerSay("In default.");    }    touch_start(integer total_number){         llOwnerSay("touch_start.");        state test;    }}state test{    state_entry(){         llOwnerSay("In test.");    }    touch_end(integer total_number){        llOwnerSay("Touch_end.");        state default;    }}

 

[LepreKhaun]

---

TrybALSpiriT Manga wrote:

Hello, i don't understand why, when you stay cliked on, you can move the prim. Don't know if it's normal or not. thx for replies

 

default{    on_rez(integer pParams){        llResetScript();    }    state_entry() {

llSetTimerEvent(0); } touch_start(integer total_number) { llSay(0, "Touched."); state test; }}state test{ on_rez(integer pParams){ llResetScript(); } state_entry() { llSetTimerEvent(120); llSay(0, "In test."); } timer(){ state default; }}

 

---

It's normal behavior, as explained in the second and third Notes at http://lslwiki.net/lslwiki/wakka.php?wakka=touch_start .

[arton Rotaru]

I still would consider this as a bug, rather than normal behavior. Even if the Jira is from 2008 already. :matte-motes-silly:

https://jira.secondlife.com/browse/VWR-4158

[LepreKhaun]

---

arton Rotaru wrote:

I still would consider this as a bug, rather than normal behavior. Even if the Jira is from 2008 already. :matte-motes-silly:

https://jira.secondlife.com/browse/VWR-4158

---

Though I agree that the behavior is unexpected, it certainly is not a viewer bug, this happens server side, the prim actually changes position.

 

To fully understand the behavior, one has to take into account the "grab-able" object parameter. If one added the statement llSetStatus(STATUS_BLOCK_GRAB, TRUE); to the OP's default state_entry event handler, one overrides this.

 

As it is, one can question the need for the "grab-able" parameter and it's flawed implementation. However, at this point, it can only be seen as expected behavior since it would be doubtful the Lindens would correct it (or any of the other anomalies within touch for that matter) in fear of breaking existing content that may rely on such.

[arton Rotaru]

It's still a bug though. They broke existing content with the changed behavior to touch_start already.

[LepreKhaun]

---

arton Rotaru wrote:

It's still a bug though. They broke existing content with the changed behavior to touch_start already.

---

Sorry for my limited knowledge. Perhaps if you could supply a few links to this changed behavior breaking existing content at the time would enlighten me...

[Rolig Loon]

OK......  For what it's worth, I just had a scripting client report exactly this same odd behavior.  A one-prim object that I had scripted for him was behaving as if it was physical, even though the edit window clearly said that is was not.  If he left-clicked on it, he got the hand cursor icon and could drag the thing .  It killed that behavior by adding two lines to the script:

llSetStatus(STATUS_PHYSICS, FALSE);llSetStatus(STATUS_BLOCK_GRAB_OBJECT, TRUE);

 

The second line should not be necesssary if the first one is there, but I was not taking any chances.  That addition stopped the wierd behavior.  I'm wondering if we don't have an undocumented server bug here.

[arton Rotaru]

Well, the reason why it's a bug is simple. It has been aknowleged as a bug by Linden Lab, and it's not marked as expected behavior. Only because of there are easy workarounds, doesn't mean that It's not a bug. Seriously, the behavior would be the most stupid intentional behavior I have ever seen.

About changed behavior to touch_start can be read here. https://jira.secondlife.com/browse/SVC-3017

[LepreKhaun]

---

Rolig Loon wrote:

OK......  For what it's worth, I just had a scripting client report exactly this same odd behavior.  A one-prim object that I had scripted for him was behaving as if it was physical, even though the edit window clearly said that is was not.  If he left-clicked on it, he got the hand cursor icon and could drag the thing .  It killed that behavior by adding two lines to the script:

llSetStatus(STATUS_PHYSICS, FALSE);llSetStatus(STATUS_BLOCK_GRAB_OBJECT, TRUE);

 

The second line should not be necesssary if the first one is there, but I was not taking any chances.  That addition stopped the wierd behavior.  I'm wondering if we don't have an undocumented server bug here.

---

Correct, it does seem to be odd behavior until one looks at what constitutes a "touch" as opposed to a simple "click" on an object. Though all touches are clicks, not all clicks are touches.

 

The difference in what constitutes a click as opposed to what may be interpreted as a touch is contextual, entirely dependent on the initiation of the mouse_down event within the viewer, to which the server will respond. The following is Windows specific, though there are parallels within other OS.

 

1. Right Click on any object will result in a menu of choices, drop down or pie menu, same difference.
2. Left Click on an object with no scripts or a script w/o a touch* event handler is simply a click, do it twice and your avatar will want to walk towards that point.
3. ANY Left Click on an object with an active touch* event handler and the click is processed as a touch, according to whatever is coded within the event handler that is triggered.
4. Left Click + CNTL on an object with no scripts or a script w/o a touch* event handler is a "grab and move".
5. Left Click + CNTL + SHIFT on an object with no scripts or a script w/o a touch* event handler is a "grab and rotate".
6. CNTL + 2 brings up the "Grab Menu", which is also available from the Edit Menu by choosing the Grab Icon. Within the Grab Menu, one has three options on controlling the prim, which differ considerably from the Edit Menu
7. One can also enter the Grab Mode as the OP script does, which is the main caveat regarding making a state change within the touch_start() event handler, as this behavior may be unexpected.

 

Dora almost had it right, in that once a click is initiated, it is either a click or a touch. The unexpected behavior arises when transitioning states within touch_start() (when a click is being interpreted as a touch) to a state that has no touch* event handler at all. In that state, it must either be reinterpreted as merely a click or, as it happens, remain a touch and, as it happens, it's taken to be a  touch grab and move, since no other behavior has been defined. In other words, you're simply observing the default prim behavior to be expected under those conditions, all of which can be overridden within LSL

 

And, as I stated before, the grab touch does leave a bit to be desired in its implementation. However, that is the default touch event behavior, for whatever that's worth.

[Rolig Loon]

That makes sense.  I had not understood that before. :smileywink:

[Dora Gustafson]

It makes sense but is nothing more than a claim or hypotheses that have not been confirmed
Neither are reliable references given
Only with access to LL's server code a proof could be given of what actually happens
Unless we have an undercover Linden contributing in this thread I think that nobody here has this access

:smileysurprised::smileyvery-happy:

[LepreKhaun]

---

Dora Gustafson wrote:

It makes sense but is nothing more than a claim or hypotheses that have not been confirmed

Neither are reliable references given

Only with access to LL's server code a proof could be given of what actually happens

Unless we have an undercover Linden contributing in this thread I think that nobody here has this access

:smileysurprised:

:smileyvery-happy:

---

Oh, but I can prove my theory. Observe the touch being transfered over the state change on a long mouseDown:

default{    state_entry(){        llOwnerSay("In default.");        llMinEventDelay(0.25);        llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT, 

<0.0, 1.0, 0.0>, 0.0, ZERO_VECTOR, ZERO_VECTOR, ZERO_VECTOR]); } touch_start(integer total_number){ llOwnerSay("default touch_start."); state test; }}state test{ state_entry(){ llOwnerSay("In test."); } touch_start(integer total_number){ llOwnerSay("test touch_start."); state test; } touch(integer total_number){

llOwnerSay("touched!"); llLookAt(llGetPos() + llDetectedGrab(0), 1.0, 1.0); } touch_end(integer total_number){ llOwnerSay("Touch_end."); state default; }}

 But, if I transit from a default which has no touch* event handler to begin with, observe what happens to a long click as it makes the transition.

default{    state_entry(){        llOwnerSay("In default."); // Click and hold at this point        llMinEventDelay(0.25);        llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT, 

<0.0, 1.0, 0.0>, 0.0, ZERO_VECTOR, ZERO_VECTOR, ZERO_VECTOR]); llSetTimerEvent(5.0); } timer(){ llOwnerSay("default timer."); state test; }}state test{ state_entry(){ llOwnerSay("In test."); // Prepare to get sea sick! } touch_start(integer total_number){ llOwnerSay("test touch_start."); state test; } touch(integer total_number){ llOwnerSay("touched!"); llLookAt(llGetPos() + llDetectedGrab(0), 1.0, 1.0); } touch_end(integer total_number){ llOwnerSay("Touch_end."); state default; }}

 And, no, one doesn't have to be a Linden to figure this out, just me.

 

[Dora Gustafson]

Well done! I'm impressed.
You have demonstrated that a touch in a state without handler makes a prim sick when a new state is entered during the touch.

You even don't need any touch event handlers to do it

Default{    state_entry(){        llOwnerSay("In default."); // Click and hold at this point        llMinEventDelay(0.25);        llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT, <0.0, 1.0, 0.0>, 0.0, ZERO_VECTOR, ZERO_VECTOR, ZERO_VECTOR]);        llSetTimerEvent(5.0);    }    timer(){        llOwnerSay("default timer.");        state test;    }}state test{    state_entry(){        llOwnerSay("In test."); // Prepare to get sea sick!    }}

 

That is valuable knowledge

The explanation about why and what goes on is still guesswork and hypothetical

Obviously something not intended is happening to the prim property because the non physical prim can still be grabbed and moved, even after the script is deleted

:smileysurprised::smileyvery-happy:

Edit: My last comment is not valid: A prim can be grabbed and moved as default

[LepreKhaun]

---

Dora Gustafson wrote:

Well done

!

I'm impressed

.

You have

demonstrated

that a

touch

in a state

without handler

makes a prim

sick when a new state is entered during the touch.

You even don't need any touch event handlers to do it

Default{    state_entry(){        llOwnerSay("In default."); // Click and hold at this point        llMinEventDelay(0.25);        llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT, <0.0, 1.0, 0.0>, 0.0, ZERO_VECTOR, ZERO_VECTOR, ZERO_VECTOR]);        llSetTimerEvent(5.0);    }    timer(){        llOwnerSay("default timer.");        state test;    }}state test{    state_entry(){        llOwnerSay("In test."); // Prepare to get sea sick!    }}

 

That is valuable knowledge

The explanation about why and what goes on is still guesswork and hypothetical

Obviously something not intended is happening to the

prim

property

because the non physical prim

can still be grabbed and moved

, even

after the script is deleted

:smileysurprised:

:smileyvery-happy:

Edit: My last comment is not valid: A prim can be grabbed and moved as default

---

Mmmm, without the touch* events within state test, I wouldn't have proved that what originated as a click in default, stayed a click after the state transition. However, in my first script what originates as a touch, remains a touch through the transit.

 

In other words, whether a touch or a click is happening in the second state, is determined solely by how the sustained mouseDown was perceived in default.

 

Perhaps this shows it better, using a timer to transition from default both times, just uncomment the three lines in the default state to see what is happening...

default{    state_entry(){        llOwnerSay("In default."); // start touching and hold now        llSetTimerEvent(5.0);        llMinEventDelay(0.25);        llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT, <0.0, 1.0, 0.0>, 0.0, ZERO_VECTOR, ZERO_VECTOR, ZERO_VECTOR]);    }    // Uncomment this event handler to see difference between    // Click and Touch being transferred between states.//    touch_end(integer total_number){//        llOwnerSay("default touch_end.");//    }        timer(){         state test;    }}state test{    state_entry(){        llOwnerSay("In test.");        // Still holding mouseDown, move your mouse after this    }        touch_start(integer total_number){        llOwnerSay("test touch_start.");        state test;    }    touch(integer total_number){        llOwnerSay("touched!");        llLookAt(llGetPos() + llDetectedGrab(0), 1.0, 1.0);    }        touch_end(integer total_number){        llOwnerSay("test touch_end.");        state default;    }}

 

[Dora Gustafson]

Yes! You were right all the time.
I just had to rediscover the behavior of a default, unscripted, just rezzed prim
It has been years since I last new it, I never move prims like that

:smileysurprised::smileyvery-happy: