|
|
|
I am unsure about how big a change to the VM this would require. I'm pretty sure it would entail adding a new register to the LSL2 header. This would be a change large enough that it would not happen until after the release of Mono.
I'm seeing something similar with queue flushing where I have a "ready state" with a touch event. I switch to "input state" during the touch event. the "input state" does not have touch events. I switch back to "input state" and find that the next person needs to touch the object twice before the script can capture the touch event. To top it all of, the default state does not have touch events either. Once I added touch_start events in a few of the states, the script worked fine with the event queue. I'm guessing swapping between states doesn't make the LSL virtual machine rewire events until they are used.
Must say I was greatly surprised when I discovered that the event queue was cleared on a state transition. Christopher is absolutely right in that the whole point of designing programs using a state machine formalism is to be able to proscribe different behavior to the same event, depending on the state that you're in.
I simply can't understand how SL could define LSL as a state-machine language only to undermine it by clearing event queues, thereby discouraging people from ever using more than one state! The fact that this does not seem to be a big issue underscores the point that most users are clearly using single-state code. State machines are an excellent way to model real-time event-driven systems like SL, and in the real world, they are used almost exclusively to develop these types of systems. SL, how did you get it so wrong? In LSL-LSO events are only put in the queue if the current state can handle them. It would increase the memory requirements to change this. I'm not sure how the LSL-Mono event handler works.
I previously referred to LSL-LSO as LSL2 which is incorrect (at the time it wasn't). I do agree with you Biff, I avoid states for this reason... unless I want the event queue to be nuked. But Strife, avoiding multiple states should not be the solution here. You're giving up on an incredibly expressive way of describing event-driven behavior. It makes the scripts written by SL users monolithic and complex, with many global variables and "if" statements, that would simply not be required otherwise.
Clearly Linden Labs used a state-machine formalism because they thought it was the best way of expressing program logic for event-driven systems like SL; and they were right! I've not been here long enough to know how they got off track by designing their scripting run-time system to purge the event queue on state transitions. Has anyone from LL commented on this issue? I'd be very interested in hearing what they have to say. If they want RL companies to take SL more seriously and develop products for the virtual world, their development environment has to be up to snuff. Perhaps their long-term strategy to replace LSL with standard standard programming languages makes this issue moot. But I bet you if or when that day comes, they won't be dropping messages from event queues! LOL, LSL was "designed" and coded in a weekend.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Add LSL function llRetainEvents(integer flag) to prevent flushing the event queue on state transitions
This will make state transitions a tool to express what I think they were meant to express: they dictate what code runs when an event is handled by the script, regardless of whether the event was put on the queue in the current state or the previous one.