Please see VWR-9023

This issue has returned in server version 1.24.7.98039.

The last comment under https://jira.secondlife.com/browse/VWR-9023 states "Fix deploying with 1.24.7". Perhaps the fix for VWR-9023 broke this one.

• There must be at least two state changes:
  1. First change from a state with a touch* event handler to a state with a timer event handler.
  2. Then change from the state with the timer event handler to a state with a touch* event handler. (Could be the same state as earlier, or a new state.)
• The second change must be triggered from within the timer event handler.
• The state with the timer event handler must not have a touch* event handler.

I'm using "touch*" to mean any of touch, touch_start, or touch_end.

I have found 2 work-arounds for this issue:

• Add a touch* event handler to the state with the timer. (The handler doesn't have to do anything.)
• Use touch or touch_end instead of touch_start in the non-timer state.

P.S. Here's my own code to reproduce the problem. It demonstrates that it doesn't have to be the same state again.

-------------

default
{
state_entry()

touch_start( integer n )

}

state B
{
state_entry()

timer()

}

state C
{
state_entry()

touch_start( integer n )

}

Just came across this in the following situation:

state A
touch_start event

state B
timer event

state C
timer event

then back to state A, where the next touch event is not registered

Putting a touch event in state C does not help.
Only putting a touch event in state B gets around it.

The work-around (add an empty touch handler to the other state) does seem to work ... but is cumbersome.

Second Life 1.21.6 (99587) Oct 15 2008 09:48:17 (Second Life Release)

You are at 158482.4, 253350.6, 630.1 in ASI Maupiti located at sim5021.agni.lindenlab.com (8.2.32.22:13001)
Second Life Server 1.24.9.98659

Not sure if it is solely a server issue.

=======

This bug seems fixed on Second Life Beta Server 1.25.0.100573

It also appears to be the same as SVC-3207

The bug is intermittent in Haven Shire 1.24.10.106829
but pretty solid in Kochoomo 1.25.4.108489

On returning via a Timer Event to the Default State, the first touch_start event is lost.

Tested with the following code:
-----------------------------------------

default
{
state_entry()

touch_start(integer total_number)

}

////////////////////////////////////

state state_2
{
state_entry()

timer()

}

Could this regression be related to the fix for VWR-9023 ?

Please, fix it ! : )

You're right, it's back ...

The server drops the first touch after leaving a state without touch-event.

=======

Second Life 1.22.6 (108361) Jan 20 2009 13:28:18 (Second Life Release Candidate)
You are at 251721.2, 246592.9, 406.5 in Neptune located at sim4319.agni.lindenlab.com (63.210.157.223:13000)
Second Life Server 1.25.4.108489

Second Life 1.22.6 (108361) Jan 20 2009 13:28:18 (Second Life Release Candidate)
You are at 147334.3, 236918.0, 984.6 in Ciel located at sim8478.agni.lindenlab.com (8.10.151.37:13000)
Second Life Server 1.25.4.108489

Left-click (with state change and return via timer), loses the subsequent left-click every time.

Left-click (with state change and return via timer) followed by right-click>Touch - loses that right-click>Touch

right-click>Touch (with state change and return via timer) followed by right-click>Touch - no problem

right-click>Touch (with state change and return via timer) followed by left-click - also no problem

Second Life 1.21.6 (99587)
Second Life Server 1.25.5.109327

My doors and window controllers all require 2 touches to act. I am facing the task of replacing scripts in every door and window controller of every house with scripts which have an empty touch_start in other states.

The VM registers a click on touch but it actually has to solve to events, not just one. The second event that will becomes triggered when a touch is applied is "touch_end() {;}".

When you start a state transition from within "touch_start() {;}" the "touch_end() {;}" never comes into place and from this stays unsolved for the VM.

At this point you have to click one time to have "touch_end() {;}" triggered once before the next "touch_start() {;}" can be triggered.

So there is a simple way to solve this by using the correct sequence of events:

default {

state_entry() { llSay(0, "This is the state <default>."); state default; }

touch_start(integer cnt) { //something we want to do when a touch is starting }

touch_end(integer cnt) { llSay(0, "starting state transition"); state another_state; // here we may change state without any risk ! }

}

state another_state {

state_entry() { llSay(0, "This is the state <another_state>."); state default; }

}

This is NOT a workaround, this seems to be intended behaviour from the way the VM solves triggered chains of events!

So was the original way it worked the 'bug'?

I think the majority of people would be quite happy to see the mouse release blackholed as it was before server 1.24.4.95600

Also as someone else stated, this was introduced and breaks in world content, many of them are no mod and can't be fixed without replacement. IDK who downgraded this to "nice to have" but this IS a bug, not a feature request! I'm setting it back to normal.

It seems pretty easy to mix this with observations from making state transitions within the most commonly used touch_start() {;} instead of touch_end() {;}.

Of course one can say that this is not correct as many do believe that preservation of timers when changing states is a bug; but in fact it's not, it's intended for some reason as it seems.

Right now many write scripts in a way where touch_start(){;} is mostly used, because this is what the default script gives you at hand in the first place.
But actually it's a good idea to have this evant chain preserved across states, as it is preserving timers, since one might explicitly want to perform state transition from touch_start(){;} and solve the touch_end(){;} in another state, which is also the only reason to have those two of touch events at all! Without this behaviour it does not even make sense to have both of the two.

If you some people want to make use just of one of them and have state transitions the way they personally expect it to behave, they simply might want to make use of touch_end(){;} instead of touch_start(){;}.

Most touch_start(){;} and some of the llResetScript(){;} bugs listed in here are caused by lack of understanding about the concept of the event chain along with touch_start(){;} and touch_end(){;} and how to make use of it.
It seems many are not even aware of the existence of touch_end(){;} and how and when to make use of each of the two events depending on what behaviour is expected related to event chains and preservation of triggered touch event along with state transitions.

The LSL-Wiki should tell more clearly about this, the concept of event chains and how to make use of it to get the expected results!

Counclusion:

If this is getting fixed the way it is requested by the original poster, one of touch_start(){;} and touch_end(){;} events could also be removed, since to have both of of those events becomes almost pointless then!
In this sense this here actually requests to remove on of the two events.
So, this is NOT a bug as long as we have those two events the way they are working right now and any else would be a bug instead or at least useless overhead in the VM and could be entirely replaced by some "on_touch(){;}" event.
So we can tell, all this is actually a question about if the event queue should be cleared entirely at state transitions or an even more complex scenario where all unused events are consumed when a state is entered that has no event processing defined for certain events within this active state. This would in the first case also change behaviour of scripts expecting timer events preserved across state transitions as long as no llResetScript(){;} has been executed.
Well, this seem to be major changes to the VM and LSL language concept and far beyond bug-fixing.

And hopefully llResetScript(){;} preserving triggered events becomes fixed soon, since this is a bug of course and in many scripts also hard to distinguish from the behaviour of event chains and preserved event triggers for them.

By the way, I was the one who set this to a "nice to have" state and if I did know how to do in this bug-tracker, I would even had closed this. But actually I didn't get that and was too lazy to take a look if I can and how to do so.
In fact there quite many reported so called "bug"-issues in here that could be closed when the llRestScript(){;} issue is solved, since they are caused by lack of understanding about the topic and the correct touch_start(){;} behaviour.

string name;

default
{
state_entry()

collision_start(integer total_number)

}
state check
{
state_entry()

}

I never believed a timer should reset in a state change but this one IS a bug as this was introduced on a server code update and breaks in world content. One more time THIS WAS NOT THE WAY THIS WORKED PRIOR TO SEVER VERSION 1.24.4.956000!! There was no "major changes to the VM and LSL language concept" when this started happening. If the above is a "bug" as you seem to believe, when they "fix" this, that too will break a lot of in-world content!!

As far as using touch_end instead of touch_start, touch_end is triggered when you STOP touching an object, not when you first click it so these are NOT the same action and the object wouldn't behave the same way. If you hold down the mouse key, the touch event would never be triggered with touch_end.

Maybe you could show a useful example of WHY you would want a touch_end event triggered in the next state instead of black holed on state change as it was before this server update? I've tried to think on any valid use for that behavior and can't come up with anything.

I can come up with many valid uses for having both a touch start and touch end event, such as

touch_start(integer n)

touch_end(integer n)

To combine these touch events into a "on_touch()" event as you suggest, would make a simple horn button that blows as long as you hold down the button impossible to make. If you want something to happen in the next state when you release the touch, simply have the state change in the touch_end event and have the action in state_entry of the next state.

The fact the lindens assigned someone to this bug should also show this is not "resolved" and is a bug they introduced.

But we do not have that as it seems and it's not clear for all cases if it would be a good idea. I am not absolutely sure about this, but perhaps this might even cause some issues with slow asynchronous calls that would not allow state transitions any more because of this as long as a HTTP request or XML-RPC is not completed within the same state it has been started?
But maybe this is just for some rare cases and would not a big problem at all?!

I couldn't tell, since as long as it is not part of the VM, there is no way to test that.

And I agree with you, it's of course not a good idea to have just one on_touch(){;}, but not to preserve touch events across states is almost the same thing, apart from still being able to have trivial stuff like blowing horns until the mouse button is released again.
It will make many start coping even more data by hand across states, which will not do any good but creating additional server load and memory consumption on sim servers at runtime.

By the way, that this is assigned to someone at linden does not say this a bug, it just says that someone of linden will take a closer look at this just in case there is some issue and/or missing feature! This does not say or proof anything beyond what it means when someone is delegated to take a closer look.

—

What I really would love to see is a change request that all registered events are preserved across states and perhaps only being registered by an explicit call just for the sake of langauge concept consistency, which would make on_exit(){;} event become a lot more useful and also making people read more about events in the LSL-Wiki, which might be a good thing in my eyes from what I see from many of the scripts around at SL.
But that's just my very personal point of view.

So if the script drops the first touch, then touch_start is not working properly. It's that simple. Whether or not I COULD choose to use touch_end instead is beside the point. That would be a possible work-around for the issue, but does not answer why touch_start couldn't be used in the way desired.

Simply stated: If I use a touch_start, and if the script happens to transfer to another state (as a result of that event or another), and subsequently returns to the state in which touches are detected, then the script should detect a touch when it occurs. The touch_start event is not working properly in that regard, because it fails to be triggered on the first touch. That is a bug.

So, while the new behavior could be argued to be cleaner or more logical, it's not the correct (i.e. established and expected) behavior for LSL. Most likely it was a simple oversight during the transition to Mono, but no one can know for certain without seeing the source or LL's documentation.

[2009/03/20 15:09] Periapse Linden: The problem is that we had never really defined how touch events and scrripts are supposed to interact.
[2009/03/20 15:09] Periapse Linden: So we couldn't really say that there was or wasn't a bug.
[2009/03/20 15:09] Periapse Linden: Scouse Linden compared scripted touch across several server versions
[2009/03/20 15:10] Periapse Linden: and developed a simulator that has predictable, stateable behavior
[2009/03/20 15:10] Periapse Linden: We think that while it may not be ideal, it preserves existing content.
[2009/03/20 15:13] Periapse Linden: So Scouse is now merging the changes into 1.26, which is now much more stable
[2009/03/20 15:15] Periapse Linden: So here's what we came up with for touch behavior:

[2009/03/20 15:17] Periapse Linden: 1. Mouse down on an object creates a touch_start and a touch event.
[2009/03/20 15:18] Periapse Linden: 2. While the mouse is down a touch event will be generated every frame, even if the mouse is dragged so it is no longer over the object.
[2009/03/20 15:18] Periapse Linden: 3. # Releasing the mouse button having previously clicked on an object generates a touch_end event even if the mouse is no longer over the object
[2009/03/20 15:19] Periapse Linden: and lastly 4. Changing state will clear the pending touch* events so no new touch* events will be generated until further user input is received.

I also fail to see how any 'large about of data' would have to be stored as a global if this was reverted back to it's past behavior, which matches collision_start behavior. You didn't supply any code or examples that would back up this claim of data issues across states. What could you possibly save or gather in the next states touch_end? A detected_name or key? My example shows that yes a detected_name or key has to be global but that is ONE variable! I just don't see where this "make many start coping even more data by hand across states" comes from. Especially the "start" part as it never worked like this until recently!

Using touch_end does NOT give the same response as touch_start and they can't be used interchangeably. And sorry if you feel my example is "trivial" but try to remember this is a game!

I applaud LL for making LSL simple enough to understand that normal "players" can write scripts without needing a degree in computer science. If the above isn't how other languages work, it really doesn't matter to me.

I would say that it is [a bug].
If what you suggest - that a touch_start() must be balanced with a touch_end() - were correct, then a single state would not be able to process multiple touch_start() events without balancing touch_end() handling. This is clearly not the case.

default
{
    touch_start ( integer num ) { llOwnerSay( "hello!" ); }
}

... will happily say "hello!" every time its touched.

(Shhh. It's not a game.)

"...since one might explicitly want to perform state transition from touch_start(){;} and solve the touch_end(){;} in another state, which is also the only reason to have those two of touch events at all!"

"If this is getting fixed the way it is requested by the original poster, one of touch_start(){;} and touch_end(){;} events could also be removed, since to have both of of those events becomes almost pointless then!"

"So, this is NOT a bug as long as we have those two events the way they are working right now and any else would be a bug instead or at least useless overhead in the VM and could be entirely replaced by some "on_touch(){;}" event."

I have to disagree. There is good use of all three touch events without having state changes, having all three of them enables us to make for example a switch which can do different things depending on the length of the touch:

touch_start(integer num_detected)
{ do A }

touch(integer num_detected)
{
counter++;
if (counter ==71)
{ do B1 }
}

touch_end(integer num_detected)
{
if (counter <= 70)
{ do B2 }
}

I understand that what you suggest should be the way LSL works would not break this. I wanted to mention it as an example that having all three touch events is not obsolete at all although it could be easily solved without touch_start and an additional "if (counter == 1)" in the touch event as well.

But the reported issue is a change from past behavior everybody was used to. While i see your point that preserving a touch throughout state changes would open new and different ways to accomplish something it would nevertheless not enable us to do anything we haven't been able to do before.

"since one might explicitly want to perform state transition from touch_start(){;} and solve the touch_end(){;} in another state"

That always used to work if touch_start triggers state change and the new state has both a touch and a touch_end event.

I know there would be ways to improve how LSL works but when we begin to change the language to the extent you suggest we will break content and that is a no no.

So the only way to deal with this is to restore the old functionality since it is expected behavior and doesn't break anythign since it has always been working like that.

[edit for spelling]

State machines are an excellent way to model real-time event-driven systems like SL, and in the real world, they are used extensively (in one form or another) to develop these types of systems. Clearing the event queue between states discourages designs from using more than one state, which ironically undermines LSL as a state-based programming language. It really leads script writers down the wrong path, creating monolithic scripts with many global variables and "if" statements, as well as creating kludgy implementations trying to work around inconsistent treatments of events across state changes (e.g., timers).

Of course at this stage backwards compatibility is essential, so some sort of option setting or function call should be available to not clear the event queue. I strongly feel LL should really re-examine this issue going forward.

Also, as far as inconsistent treatment of events across states, collision_start still behaves the same way as touch_start used to. I see no reason to have a script ignore a touch_start event, like is happening, just waiting for a touch_end CALL (that may or may not be there) for the script to respond to the next touch_start. The fact this doesn't happen UNLESS you change states is showing that something is clearly broken. I don't get what purpose that serves other than forcing people to make a useless touch_end call just to work around this new problem. If they wanted to implement that touch_end could respond in the next state, that at least wouldn't break in world content.

BTW Biff, the "problem" you pointed to has 3 votes, this one has 30!

If a touch_start, or a touch_end, or a moving_start, or a moving_end is what you are trying to detect, you should NOT have to add dummy code for the opposing state to make the code work!

default
{
state_entry()

touch_start(integer A)

touch_end(integer A)
{
}
state_exit()

}

state another
{
state_entry()

touch_start(integer A)

touch_end(integer A)
{
}

state_exit()

}

-Create a cube, take it, wear it, and add this script:

default
{
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
    }
    touch_start(integer dummy)
    {
        llDetachFromAvatar();
    }
}

-Touch the cube by left-clicking.
-Re-attach the object from your inventory.
-Touch the cube by left-clicking again.

Observe: The server drops a touch, for the same reason as with state-changes:
The script assumes that the object is still being touched, the end of the previous touch was never handled.

If you left-click very short, this bug does not occur