An overview of the key enhancements is provided below. For full details please see the Release Notes and the Product Documentation.

Enhanced LSL Code Editor

The built-in LSL Code Editor has been significantly improved with the addition of several features which improve the readability of entered code, provide for easy access to descriptions of variables, functions and constants within the code and perform more extensive checking of the code for errors. For full details see Using the Code Editor.

Color Syntax Highlighting

The first thing you will notice when opening the new code editor is that it now provides color highlighting of all the LSL syntax elements. This dramatically improves the readability of code.

In addition, you can place the cursor to the right of a starting or ending bracket including (), {}, and <> to highlight both brackets which is really helpful to ensure that a complex LSL expression has been formulated properly or simply to find the other end of a code block of interest.

If desired, you can disable Syntax Highlighting by de-selecting Show syntax highlighting in the Code Editor panel of the Options dialog.

Type Checking

All LSL code is now fully type-checked, capturing errors that were previously only reported when the code was saved in the Second Life Code Editor. In particular, errors will be flagged whenever incompatible data is assigned to a variable or passed as an argument to an LSL function or user-defined state function.

Aside from type checking, the enhanced syntax checker will also flag non-critical Warnings. Warnings are generated for local variables that are declared but never used, or used but not previously initialized. As well, obvious cases of unreachable code will be flagged. You can disable the detection and display of warnings by de-selecting Show Warnings in the Code Generation panel of the Options menu.

Code Completion

Several improvements have been made to the Code Completion feature. All variables and functions within scope are now included in the Code Completion popup, including Custom Globals, State Variables & Functions, Local Declarations as well as LSL System Functions and Constants. Also the type signature is now shown for any selected item in the Code Completion popup.

Hover ToolTips

Whenever the mouse cursor hovers over a variable, constant or function, a pop-up help tooltip will now be displayed showing the data type and description (if any) of the element. This is really helpful when reviewing your code, reminding you of the type and description of variables and functions that you have defined as well as for LSL system functions and constants.

These hover tips are enabled by default, but can be disabled by de-selecting Show coding hover tips in the Code Editor panel of the Options menu.

Selected Text Highlighting

Whenever text is selected, other instances of that same text will also be highlighted. You can also Tab (or Enter key) forward or backward (using the Shift key) between highlighted items. This is a great and easy way to do a quick search on an item to see where else it has been used in the code segment!

This feature can be disabled by de-selecting Show extended selection highlighting in the Code Editor panel of the Options dialog.

Find/Replace Dialog

You can now search longer segments of code using the new Find/Replace feature. From within the Code Editor, open the dialog by pressing CTRL-F to find some text or CTRL-H to both find and replace some text. In the dialog box you can select various options for the search (match case, whole word, etc.) and click the appropriate button to either find the next occurrence of the text, replace the found text with the text in the Replace with: field, or replace all occurrences of the text with the replacement text.

There is a single Find/Replace dialog box for all open LSL Code Editors, however the dialog box is linked to only a single code editor at a time. This link is shown in the title bar of the dialog. You can switch the Find/Replace dialog box to another Code Editor by simply clicking within the desired editor or pressing CTRL-F or CTRL-H from it.

New LSL Actions

With this release many new LSL Actions have been provided, including those that can be used to transfer money, move an object within a region, and override a default animation. Of particular interest are the set of new actions that have been provided to support the great new SL Pathfinding feature!

In addition to the new LSL Actions, three new library components have been included; GetInput: Provides for textbox input to your script, SendHTTP: Sends an http request to the specified URL, and ReadNotecard: Reads the lines from a notecard into your script.

User Interface Improvements

Several user interface improvements have also been made, including some suggestions provided by MOAB users! In particular, the capping of state notation is now configurable. In the previous release, properties shown on a state component had each line capped to a fixed number of characters. Now there is a new configuration item, Cap Notation within the States panel of the Options menu. By default, this option is enabled. However when disabled, as much text as the state's width allows will be displayed for each line of property information.

The Show Comment button in the State Editor toolbar has been renamed to Show Info. After selecting Show Info and hovering over a state, the resulting pop-up will show the complete Entry & Exit Action code for the state. In this way a model's code can be more easily scanned without having to repeatedly open and close state Property Editors.

Another handy improvement is that the script version of a MiceOnABeam model is now shown in the title bar of the top level State Editor. Additionally, the Major Version number can now be set to 0;

Finally, the Code Generation Errors List will now flag non-critical Warnings separate from Errors. In addition you can sort any column by clicking the column header. Clicking the same column header again will reverse the sort.

Secondly, the Second Life LSL code editor has a limit of approximately 64KB of characters. This includes all code together with all comments. The editor will not accept any characters beyond this limit preventing you from even compiling a large script!

Fortunately there are several things you can try to address these limits.

Selecting the optimized version of Generate LSL in MiceOnABeam significantly reduces the amount of LSL code generated which helps the script live within both character & memory limits.

Further, the most expensive modeling features in terms of script size are Composite States, Deep or Shallow History Points and Group Transitions. Each use of these can add considerable length to the generated code. Judicious use of these features can significantly help.

With respect to actual coding and memory requirements for variable manipulations, these memory guidelines are worth reviewing.

Additionally for un-optimized generated code, you can try to get a script that exceeds the editor's character limit to compile within SL (so that you can use the built-in MOAB tracing features), by de-selecting Include Section Comments & Include User Comments within the code generation options panel. This reduces the source code by eliminating comments.

Following the last release of MiceOnABeam Visual Scripting Tool, I had developed and released for sale a couple of building components that I thought people would find useful, namely the MOAB Universal Rotator and the MOAB Universal Slider.

The Rotator is a simple door-like script which will swing any prim on any side or edge! The Slider is similar except it slides in any direction (up to 27!). While there are many swing door scripts available, it's hard to find one that actually works like a real door which swings on the hinged-edge rather than the center of the selected side.

Best of all it works at any rotation, linked or unlinked and no path cuts are required so it works with sculpts and mesh designs without cumbersome work-arounds! Fully configurable via notecard with no scripting required, it features automatic close, lock/unlock, optional sounds/messages and a chat command interface. Supports multiple synchronized doors too! This review by a happy customer says it best. These neat low-overhead scripts provide an easy way to add swinging or sliding motions to any of your creations in Second Life.

MOAB Universal All-In-One Door

I've taken these simple rotator and slider components considerably further with the release recently of a comprehensive solution for doors which includes scripts for a fully featured door, an add-on for Role Play features and a HUD door server to control all the doors on a single sim.

The MOAB Universal All-In-One Door scripts build upon all the Rotator features, including the same accurate hinge operation for the swing movement, but also can be configured for most any other door type including swing, pivot (swing at offset from edge), slide, curtain, iris (opens/closes like an eye's iris), clock (opens/closes via a prim cut up to 360 degrees) and transparent. Access control is provided via a Whitelist, Blacklist or SL Group for security management.

The MOAB Door Role Play Add-On scripts add Lock Picking, Key Passing and Door Bashing/Repairing features to the All-In-One Door. You can also get the role play features along with the door scripts with the MOAB Universal All-In-One Role Play Door. Lock picking is straightforward: After pre-configured delays, subsequent touches increase the chance of success to unlock the door. Door Bashing permits multiple avatars to simultaneously bash or repair the door, keeping track of each one to ensure only a single strike/repair from each avatar within the configured time interval. Damage calculations are based on door size and material together with the momentum of the collision. Other features include timed automatic repair, enforced maximum distance and configurable sounds and more. All of this, together with bash sounds and smoke provide for realistic role play.

All doors on a single sim can be centrally controlled with the secure MOAB HUD Door Server. In addition to a centralized Whitelist/Blacklist that can be sent to any or all doors, you can open/close, lock/unlock or reset any individual door or all doors. What's really awesome is that you can attach the server as a HUD and use it to teleport to any door and thereby visit every door on the sim in turn! As an added bonus, purchase of the server includes free updates for the server and MOAB Universal Door and Role Play scripts!

A Peek into the Implementation

I often get asked, "How large and complex a design can be developed with MiceOnABeam?". Well the answer is that you can capture a fairly large amount of functionality within a single MOAB model using the graphical notation and detailed actions with LSL code or using the LSL Action Wizard. However all large designs require proper partitioning into multiple modules for increased clarity and flexibility and the same applies to MiceOnABeam. Further, LSL memory limitations (max 64K per Mono script) also play an important role in deciding how to partition a large set of functional requirements into multiple communicating MOAB models (and resulting LSL scripts).

So I thought I'd give you all a peek into how I partitioned the implementation of the above products into their respective MOAB models and further provide some insight into several MOAB design techniques.

While a simple open and close door is an easy design exercise, once you start adding features, things can start to get large and complicated really quickly. One classic software technique is to separate out UI (User Interface) requirements from the core functionality. A number of classic software patterns exist for this (including MVC).

I partially followed this separation of concerns when developing the door model, by splitting off the functionality which handles the configuration of the door, the chat command interface and the communication with the Door Server into one MOAB model, MOABDoorConfig, and the core functionality for the door (i.e., open/close, lock/unlock) into another model, MOABDoor. This separation also facilitates a deployment optimization whereby the MOABDoorConfig script can be omitted in all but one of identically configured doors in a synchronized multi-door scenario thereby helping to reduce memory requirements.

MOABDoorConfig

The MOABDoorConfig model (shown above) has three main functional areas that are clearly evident using MiceOnABeam's graphical notation. The ReadNotecard state and associated Choice Points, C and C1 handle the reading and processing of the two notecards, DoorOptions and AccessList.

Note that ReadNotecard is a Composite State, containing the details of it's implementation inside. Composite States are not only useful in applying common event handling to a subset of states but also hide additional details so that only the right amount of information is shown at every level of the model thereby increasing visual clarity.

Each notecard is processed in turn and when done, the Init transition is taken which completes initialization based on the options and moves the model into the Idle state.

From Idle, the Cmd and ServerCmd transitions each listen for chat messages from the user and Door Server respectively. The Guard Condition of each transition tests to see if the current listen event is on the channel of interest and if so, that transition path is taken. In each case the message data is parsed and the Guard Condition of each transition outgoing from the CmdTest and Server Choice Points respectively tests for it's command and the appropriate action is then carried out. Both Reset commands are connected to the state's border which the directs the program flow back to the Initial Point (large black dot at the top left) to re-initialize the model. Note also the use of the Junction Points J and J1 to join together curved transitions to help keep the diagram clean.

MOABDoor

The MOABDoor model (shown above) is pretty straightforward. Two states, Opened and Closed represent the state of the door and the transitions between them, Open, Close and timer, are triggered by the touch-end event and the timer event respectively. Note the exact same event, namely touch_end, is handled in a different manner depending on which state the model was in when the event was received; one of the hallmarks of a state-oriented design.

The MOABDoor model also responds to internal link_message events from the MOABDoorConfig model to open/close or lock/unlock the door. MOABDoorConfig sends these events in response to chat commands from the user or directed chat from the Door Server (using llRegionSayTo()). Recall that link messages can be sent to any one or all of the prims in a linkset. In this case the MOABDoorConfig script sends the message to the same prim that it is in. This illustrates how models can take advantage of the inherent message broadcast capability of the LSL run-time system. There is additional processing overhead associated with this technique, but it's benefit in loosely coupling design components offers a compelling advantage in many circumstances.

As well MOABDoor responds to chat from other doors arranged as multi-doors. These commands are then parsed and processed in the same way as described earlier for the MOABDoorConfig model. The Resume Choice Point is then used to direct the model to the correct state after processing the command.

►Advanced Note: A more conceptually correct approach would have been to have the OpenCmd and CloseCmd transition transition directly to the Open and Closed states respectively with the remaining commands routed to a ShallowHistory node (to return to whatever state the model was in last). The current approach was taken as an optimization to reduce the amount of code generated. Such compromises sometimes just have to be made.

MOABRolePlay

The Role Play feature is structured as an add-on to the basic door and so has two separate MOAB models for it's implemention. The division in functionality follows that of the door, a MOABRolePlayConfig model to handle the chat command interface and configuration, and the MOABRolePlay model to handle the Lock Picking and Door Bashing features. Taking a look at MOABRolePlay (shown above), you can see the three areas of functionality, for Lock Picking, Door Bashing and Command Processing for handling messages from the MOABRolePlayConfig script and other multi-doors.

Door Bashing is triggered by a collision as captured in the collision_start transition which initializes the bash response. Note that the transition originates on the top state's border and so operates as a Group Transition which means the event can occur within any of the (sub)states of the outer state (in this case, the top state). Further collision_start events are handled from the DoorBash state via the self-transition for it. Choice Point C1 receives touch_end and timer events to repair the damaged door and if repaired, directs the model to the Idle state.

The LockPick state is entered upon receiving an internal AccessDenied link_message event which is issued by the MOABDoor script whenever someone is denied access. LockPick is a Composite State whose contents contain the detailed steps for the lock picking sequence (shown above). Here the model steps through the transitions representing the lock pick sequence triggered by touch_end and timer events. Of interest is the no_sensor transition which operates as a Group Transition to end the lock picking if the user moves away from the door.

DoorServerMenu

Finally, the MOAB HUD Door Server is divided into two models, DoorServerMenu which handles the user menu system and DoorServer which handles the core server functionality and communication with the doors. The model for the user interface is fairly complex (shown above) and shows how MiceOnABeam can accomodate the design for the three system menus and how they interconnect via Next and Prev button selections on the menu dialog.

So there you have it, a brief look into how some of the major features of the MOAB Universal Door and related products were designed using the MiceOnABeam Visual Scripting Tool. While it's great to help get users started with LSL scripting, MiceOnABeam can also be used to implement some pretty sophisticated functionality.

Next Up

Next up for MiceOnABeam will be a new release in the Fall that updates the program with some bug fixes together with the latest functions added to LSL over the past months.

In v1.0.3 event arguments can now be directly accessed from the outgoing transitions of a Choice Point, instead of having to first save them in a state variable within the action code of the transition incoming to the Choice Point. This is true as long as there is only a single incoming transition and it has an event assigned.

Applying this to the model developed in the MiceOnABeam Basics video tutorial, we no longer have to save the data argument in the Line state variable in the dataserver transition. We can now access data directly in the GetNextLine and Done transitions.

Additionally as v1.0.3 now allows multiple bends within a transition, we added an additional curved bend to the Done transition to pretty up the diagram.

You can download an updated version of the Secure Door model from the video tutorial here.

From here you can select an error and go to the modeling component of interest. As well you can open up the corresponding Properties Editor which will display the error message right at the point in the LSL code where the error was found. You can then fix the error and quickly regenerate the code by selecting the Refresh button on the Code Generation Errors window to update the error list.

Undeclared LSL Variables & Functions are now flagged
References to undeclared LSL variables and functions are now detected and flagged as errors both when the Properties Editor is saved and again upon generation of the LSL code for the model (in conjunction with the new Code Generation Errors window as shown above).

Local variables that are multiply declared within the same local scope of an LSL code segment will also be flagged as errors.

Multi-Segment Straight or Curved Transitions with Auto-Align
You are now able to create multiple straight or curved segments for a transition! In previous releases there was only a single Selection Handle for a transition which you could then click and drag to create a curved bend in the transition.

To create an additional Selection Handle press and hold the Control key and click on the desired location on a selected transition. Then click and drag the new Selection Handle to create the new bend. To delete a Selection Handle, just Control-click it.

In addition if you would prefer straight line segments instead of curves for a particular transition, de-select Smooth Transition from it's context menu.

To align a particular line or curved segment of a transition to either a horizontal or vertical position, just hold down the Shift key when clicking and dragging a Selection Handle to the nearest horizontal or vertical plane. Note that alignment is always done one segment at a time, from the selected Selection Handle to the adjacent handle (towards the starting point of the transition).

Finally you can move the display of the transition's label to another Selection Handle by holding down both the Control & Shift keys and then clicking on the desired Selection Handle.

Those graphic designers among you can now really let your artistic side flourish! Me- not so much :-(

New State Explorer
In a more complex model consisting of several Composite States, it can be tedious to traverse the nested state hierarchy to get to the particular state of interest.

The new State Explorer feature addresses this by providing a tree-like view of the model's state hierarchy so that you can easily zero-in on the exact part of your model that you wish to examine.

Aside from just viewing the state hierarchy, you can also open up a State, Properties, Comment or State Variable/Functions editor from the context menu for a selected state in the State Explorer.




New Junction Point Modeling Component
A new toolbar component called a Junction Point is now available to help build your script models.

Similarly to an Entry/Exit Point the Junction Point can be used to merge several input transitions into a single output transition.  However a Junction Point is not limited to a state's border and can be created anywhere within a State Editor. It can really help de-clutter model diagrams by reducing the extent of transition lines.

And More...
Release v1.0.3 has lots more, including:

• New Icon Displayed for State with State Variables or State Functions
• State Variables & Functions Can Now be Moved or Copied Between States
• Direct Access to Event Arguments Now Provided in Choice Point Outgoing Transitions
• Wildcard characters Now Accepted Within Search Strings
• Larger Area Now Provided for State Variables in editor
• UI enhancements.

Upcoming
Next up I'll be focusing on enhancing the built-in library of LSL Actions and re-usable MiceOnABeam model components to help people get started. I'll also be developing a training class for new users and additional How-To videos to illustrate the use of specific features.

As a reminder of support options, for starters there's the MiceOnABeam group in Second Life. I encourage you all to use it for Q&A with other group members as well as myself. For more detailed Q&A you can always post in the forums on the MiceOnABeam website or contact MiceOnABeam Support. To report a product-related problem, please send an email to support@miceonabeam.com, or click Send Problem Report for a convenient form.

Merry Xmas!

Antonius

As promised with the earlier Sneek Peek for v1.0.3. here's a quick review of the latest features to have been completed.

Flagging of Undeclared LSL Variables/Functions

Long-awaited by most MOAB users I'm sure, v1.0.3. will now flag all undeclared LSL variables and functions as errors. This will reduce the occurence of generating the LSL from MOAB and then going into SL only to get a syntax error reported in the code editor there. See: http://screencast.com/t/qnJ8Y15vg.

Junction Point

The Junction Point is a new modeling feature that allows you to merge multiple incoming transitions into a single outgoing one. It will be great to help declutter model diagrams. See: http://screencast.com/t/3FanYhnmFxGh.

State Variables/Functions Icon

With this new feature a special icon will show on those states which have State Variables or State Functions defined. Now you can quickly look over a model and see where your variables and functions are defined. Further the icon will display at the bottom of a State Editor that is opened on a Composite State if that state has state variables/functions defined. See: http://screencast.com/t/2X5gg0ef2t.

Extended Comments

http://screencast.com/t/2X5gg0ef2t also shows how modeling component comments can be extended to display additional design information for states and transitions. By using the Show Comments toolbar button , you'll be able to see a list of handled events, state variables & functions, simply by moving the mouse over the component of interest.

This will also work for the State Variables/Functions Icon shown at the bottom of the State Editor for composite states as shown in http://screencast.com/t/ssoYPBBRHB.

Multi-Segment Transitions

In previous releases, there was only a single Selection Handle for a transition which you could then click and drag to create a curved bend in the transition. Now you'll be able to create multiple straight or curved segments for a transition!

In addition if you would prefer straight line segments instead of curves you can select that option from the transition's menu.

Additional new capabilities include being able to align a particular line or curved segment of a transition to either a horizontal or vertical position, and to move the display of the transition's label to a different point on the transition.  

See: http://screencast.com/t/8fi2XxhSX  for examples of these. You can even let your artistic side flourish when drawing your models. See: http://screencast.com/t/4bBSIPtiy6N.

Still a fair bit of cleanup and testing to be done. I anticipate a release early November.  If anyone is interested in beta-trialling the new release, please drop me a note at support@miceonabeam.com and let's chat.

Antonius

State Explorer

Here's the new State Explorer: http://screencast.com/t/ldGOojlyDQ

You will be able to open a State Explorer on any State Editor and it will show a tree of all the nested states. You can hide/display each level and open up a menu for each item. See: http://screencast.com/t/cUtMS7sN

From there you can open up various editors relating to the State.

Error Reporting

For the next feature I put in a new error reporting system for the code generation which will now check all LSL code in the model at code generation time for syntax errors, undeclared variables (new!) and validate LSL Actions. See: http://screencast.com/t/0IN2Uc8hVuy

This should save being surprised in SL with a syntax error after copying the generated code. From the error dialog you can open up the containing State Editor for the component as well as the actual properties editor.

This shows the modified code windows and how errors will be shown after being selected from the error list dialog. See: http://screencast.com/t/gx7PN2OSQy

Note that code lines are now numbered!

Direct Access to Event Arguments

Lastly (for now) is the feature that will allow you to directly access event arguments from the transitions leaving a Choice Point (if that Choice Point only has a single transition into it). See: http://screencast.com/t/mKtcPk4iN4c5

The graphic is from the door script from one of the tutorial videos. Note that in the Done transition you can now directly reference the data argument of the dataserver event of the transition leading into the Choice Point. I think that will remove alot of confusion for new users to MOAB who would naturally expect to access the arguments in this situation directly.

I'll post more info on additional features as they continue to be developed for v1.0.3.

Antonius

Using just the three modeling components of States, Transitions and Choice Points, you can build the model along with the tutorial and create a useful script for yourself in Second Life.

Check it out here.