L'Etat, C'est Moi! :-)

I've recently noticed some comments on the net regarding MiceOnABeam concerning the program's use of a single LSL state to encapsulate all of the generated code for event handling. So I thought I would provide some background and comments as to why this route was taken.

I certainly understand the surprise that some users have at the use of only a single state in the generated code. I suppose it's quite ironic, given that MiceOnABeam implements a subset of a formal methodology (UML) that actively encourages the use of multiple states to capture event-driven behavior. So you ask, what gives?

Well it all comes down to tradeoffs. The truth is that the very first (internal) version of MiceOnABeam did in fact generate multiple LSL states; a single LSL state for every state that was defined in the MiceOnABeam model. The problem that arose was that limitations in Second Life's LSL run-time system made it difficult (IMO) to design robust scripts particularly when taking advantage of some of the higher level modeling capabilities that MiceOnABeam offers, such as the Group Transition and History features.  The main culprit? LSL's clearing of the message queue on every state change!

Now I know there are some who will disagree with me that this is a limitation, and I do understand how scripters have naturally learned to work-around this by splitting scripts apart and otherwise kludging their designs. In some cases, they even have come to rely on the automatic clearing of the message queue. But that does not make it a good thing. The bottom line is that it is unheard of in RL for those real-time systems which live in an environment of randomly-generated events to clear the message queue on a state change!

Clearly, losing messages in a such an environment (i.e., Second Life) can compromise developing robust, reliable systems. Using multiple LSL states then makes it difficult to ensure that a critical message will be received and processed. The result is that scripts under load will often malfunction or end-users will have their interactions with scripted objects ignored causing them to repeat their actions. This is not good.

Now having written the above, by no means is the single state solution ideal either. It naturally suffers from potentially long if...else statements (although I would venture that it is only replacing an if...else sequence that must otherwise exist within the LSL run-time system that determines whether to deliver an event to a particular state). Another drawback is the marshalling of event arguments each time an event is delivered, even in the case when the event will be ignored at a particular point in the MiceOnABeam model. The latter wastes cpu cycles and memory.

That's why I said it comes down to tradeoffs. In my judgment, robust system design should not be up for debate. Too much already has been sacrificed by (dedicated & ingenious) scripters in terms of software design in attending to the bugs, LSL idiosyncrasies and bad SL design decisions. If one day SL offers a scripting option to maintain the message queue across state changes, I will happily flip the switch in MiceOnABeam to generate multiple LSL states.

Make no mistake, by no means am I claiming that MiceOnABeam is a panacea. All I'm hoping is that the higher-level modeling approach that MiceOnABeam offers is simply a step in the right direction.

Antonius