Here's what T'coz is refering to:
From: someone
Originally posted by Cory Linden
2. On state change, events do not clear, they suspend, even though the manual says otherwise.
Events do clear on state change, but there are still some bugs around the internal state of collisions, listens (and perhaps a few others). This will be fixed for 1.3.
Gah, Ive been confusing people!
Let me fully explain my position here.
Ill use this script as refrence:
integer ourListen;
default {
state_entry() {
ourListen = llListen(0, "", "", "");
}
touch_start(integer n) {
llCode();
llMoreCode();
llEvenMoreCode();
state foo;
}
listen(integer c, string n, key id, string m) {
llEmail();
llChangeSelf();
llFeedObject();
}
}
state foo {
state_entry() {
llCode();
llConfusingFunction();
llWierdNamedThing();
}
listen(integer c, string n, key id, string m) {
llDoSomethingWith(c);
llFeedObject();
}
}
There are three pieces of data which are handled during all this event flinging.
1. The event's functionality. This is the code you declare within the method you specify. For example, the functionality for default's touch_start() event is:
{
llCode();
llMoreCode();
llEvenMoreCode();
}
2. The event's queue identifyer. This is the special piece of data that is inserted in the event queue of a state. Ill refer to them like this: touch_start() event queue identifyer is: "Q
touch_start"
According to Cory, each state machiene has its own event queue.
3. The event's callback. This is also called the event's handler. What this piece does, is tell the server that the state machiene wants to be notifyed if the event occurs.
All event callbacks, except the listen, email and timer events', are implicit. This means, declaring an event within a state automaticly registers it with the server.
You dont need to put in llMakeObjectTouchable() in your script, you just put in a touch_start() event in your object, and that automaticly registers the object.
Now, the listen event's callback is explicit. You need to actually make a call to llListen() for the server to register your script to recieve listen events.
There are a few problems with two of the three pieces of events, the callbacks and the queue identifyers.
Ill run through the daily life of the script I declared above.
When our script is compiled, it immediately loads up its default state machiene. As it loads, it tells the server:
1."Hey! I have a state_entry() event in here! Notify me if I enter into my state!"
2. "Hey! I have a touch_start() event in here! Notify me if anyone touches me!"
The server goes "OK." And registeres the state_entry and touch_start callbacks.
Then the state finishes loading up. The server then tells the state machiene "Hey! You finished loading up! Ill put this event in your queue."
The server puts "Q
state_entry" in the default state machiene's queue.
The state machiene realises that its event queue was changed. Since it was previously empty, "Q
state_entry" is the first entry. It sees this, and sends its state_entry functionality down to the VM (where it is executed).
The VM sees that the script wants to register a listen event. The server acknowledges the script's request, and registeres a callback for its listen events.
Then, the state machiene checks to see if it has any more events in its queue, sees none, and relaxes for awhile.
A few minutes later, Joe User strolls up and touches the object containing our script. He expects the object to do something miraculous, like dance the electric slide, but when it sits there, he keeps on touching it. He gets frustrated, and yells "die!".
Right when Joe touched the object, the server goes, "oh! I see that something registered was touched!"
The server puts "Q:touch_start" in default's queue.
default sees this, and sends touch_start's functionality to the VM.
Because Joe user was in range of the object, and the script had a listener registered, it adds "Q:listen" to default's event queue.
Now, Joe user is touching this object like mad, he wants it to do something, anything! Little does he know, that llCode takes a very long time to process.
Every time Joe touches the object, the server adds "Q:touch_start" to default's queue.
default trys to execute the events in its queue as fast as it can, but can only execute an event after the VM is finished processing its previous event. Since llCode takes long, the events start to build in default's queue.
Suddenly, the VM freezes default. It has come to the state foo; statement in the first touch_start that default sent to it. The VM then tells foo to start up, and (is supposed to) clear default's event queue. It also is supposed to clear default's non-explicit callbacks, so foo can load new callbacks.
foo starts up, and goes through basicly the same steps default used to set itself up. Joe is still touching the object, but having no effect, since foo has no touch_start callback registered. However, when Joe suddenly yells "Gahhh!!" The server, seeing that the script still has the listen callback set up, and still has a listen event functionality in state foo, puts "Q:listen" on foo's event queue.
foo sees this, and sends its listen event's functionality to the VM.
The VM executes the listen functionality's code, until it gets to the 'state default' statement. It then freezes foo.
It tells default to begin starting up, and (supposedly) clear's foo's event queue and non-explicit callback queue.
Now, because of the bug Tcoz describes, the VM accidentally leaves default's event queue full when starting up state foo. When default is entered again, the machiene executes that stale event queue. This is where the bug is, the state is supposed to have been cleaned out when it was exited.
The change in v1.3, was that the VM clears out the explicit *and* non-explicit callbacks of a state. I for one, have been coding since day 1 expecting the explicit callbacks (namely listen's) to stay intact.
Cory mentions that there are a few bugs concerning the internal state of collisions, listens, and perhaps a few other events in his post. This is where the ambiguity of his statement comes into play. We/I dont know if he meant to change the VM so that it cleared explicit callbacks or not. Keep in mind, the callbacks are not the same thing as the queue. "Events do not clear, they suspend" referrs to the event queue for a state. It is not cleared on exit, rather suspended.
Gah sorry about the length of this. There's still alot of unsolved mysteries about how everything works behind the scenes of LSL. Im just making my best guesses here. And forgive my ignorance of grammer, I think I actually mush around verb tenses/plural nouns/first-second-third person pov alot.
We need Cory to respond to this really. No one knows if the 'internal state' bugs he mentioned in his post, supposedly fixed in this version, were connected with the clearing of explicit callbacks.
==Chris
EDIT: Attempt at correcting grammer.
.