MiceOnABeam Release v1.0.4

Version 1.0.4 of the MiceOnABeam Visual Scripting Tool for the Second Life® World has been released. All existing users can download it here. This new version features a much improved LSL code editor which I'm sure you'll all love. It also has been fully updated with the latest LSL system functions and constants so that you can take advantage of the newest capabilities in SL.

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.

Compiling Large Scripts Generated from MiceOnABeam

There are two key limits that govern the compilation and execution of LSL scripts generated by MiceOnABeam. Firstly, the memory allocated in SL to the running script cannot be larger than 64KB. This memory includes the compiled code together with any dynamic memory required by variables and related calculations. If this limit is exceeded, the script will abort with a "Stack-Heap Collision" error.

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.

Finally, there is also a way to increase the number of characters that the Second Life & Firestorm LSL editors support.

The workaround involves editing an XML configuration file in the installation directory for SL or Firestorm respectively. The file to edit is called panel_script_ed.xml. It can be found within the appropriate skins subdirectory depending on the preferences set for your viewer.

For example, using the default skin with the English language for the Second Life viewer, the path would be:
C:\Program Files (x86)\SecondLifeViewer\skins\default\xui\en

For Firestorm, using the Firestorm skin with the English language, the path would be:
C:\Program Files (x86)\Firestorm-Release\skins\firestorm\xui\en

Then change the attribute max_length within the tag text_editor from "65536" to "1000000" as shown here.

Note you will require administrator privileges to edit the file and that you should use an XML-aware editor (such as Notepad++) to make the change.

Please remember however, that increasing this limit only allows you to enter more LSL source code (including comments) into the SL/Firestorm editor. It does NOT increase the amount of run-time memory available for the script which remains at 64KB.

Using MiceOnABeam to Create the MOAB Universal All-In-One Door

MOAB Universal Rotator and Slider

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.

Accessing Event Arguments in MiceOnABeam v1.0.3

Over the next while I want to illustrate some of the new features available in MiceOnABeam v1.0.3.

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.

MiceOnABeam Release v1.0.3

I'm proud to have (finally!) released version 1.0.3 of the MiceOnABeam Visual Scripting Tool, for the Second Life® World!. All users should download this latest release. It's chock-full of improvements including some new features that I'm sure you'll love.

An overview of what's new is provided below. For full details please see the Release Notes and the Product Documentation.

If you're an existing user you can just download the new release and run the installer over the existing installation. For those of you who have purchased the Professional version (thanks!), your existing license file will continue to work with the new release.

(NOTE: For those of you who participated in the beta of v1.0.3, you must first manually uninstall the beta release via Add/Remove programs or equivalent, before running the installer for v1.0.3)

New Error List Window for Code Generation Errors
A new error reporting system has been put in place that makes it easier to find and correct LSL syntax and variable/function declaration errors directly from within MiceOnABeam and before exporting the generated code to your virtual world.

While LSL errors continue to be flagged inline whenever a Properties Editor is saved, the entire model is now re-checked upon generating the LSL code and a summary of outstanding LSL errors are listed in a new Code Generation Errors window.

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