Understanding Scripted Region Crossings
Over on Inara Pey’s blog posting on region crossings by vehicles, Pussycat Catnip added a comment that asked the question:
I started to post a reply there, but after seeing the length, I did not want to hijack that blog posting in any way. So here is my answer here:
No, to the best of my knowledge, all OpenSim grids have lacked this ability until now, unless you include InWorldz. It’s a very significant thing, and was in also a big accomplishment by Linden Lab when they provided this for MONO scripts in Second Life. But it’s not really anything to do with physics, or vehicles. It’s about transitioning a running script (in anything) from one region to another. The explanation is a bit long; my apologies.
The Script Continuation Problem
When SL went with the .NET/MONO runtime environment, they forego the ability to control scripts very closely, since the runtime environment was developed by a third party. But during a region hand-off, they need complete control. They need to be able to stop scripts running in one virtual runtime, transmit them to another region, and load them in an object on that region, and not restart the scripts, but rather continue them from where they left off. So it’s just not a matter of re-rezzing a new copy of the same thing on another region; it must restore a copy of that object with the scripts running in the same context as they were when the object hit the region border. All the active data, the current state of the script’s execution contents, must be restore and continued from where it left off. For example, before this, in OpenSim, scripts were restarted (from their beginning, losing their current context) after a TP or region crossing. InWorldz achieved this continuation of scripts with the introduction of the Phlox script engine last summer, but it was not possible in OpenSim until now.
Linden Lab’s Solution
When Linden Lab implemented this before any of the alternative grids, there was no ability to get this execution context from the third-party runtime environment (MONO). So Linden Lab developers effectively had to become MONO developers, and provide significant hacks, er, I mean extensions, to the MONO project. Which then effectively meant they were running their own variant of MONO. (I’m not aware of how extensive or localized the changes were from the standard tree.) It was a lot of hard work, but they eventually provided the hooks in MONO that they needed to pause running code (MONO scripts compile to native code), and to serialize the data into a stream that could them be fed to the next region, deserialized, and reapplied to a copy of the object on the other region. That was a lot of work and I’m sure when they started, they probably weren’t really sure to what degree their success would be.
InWorldz’ Solution
When InWorldz chose to attack this problem about a year ago, they chose a completely different path. They chose to create their own Phlox Script Engine runtime environment as a virtual machine, providing whatever hooks were needed as an inherent part of the design of that virtual machine. Then compile LSL (or any language desired) into the intermediate p-code that their own virtual machine understood. Not only does this keep control of the runtime environment for scripts within the InWorldz development project, but it allows much easier extensions in the future, much MUCH better processor consumption and memory management, and complete control of scripts.
One of the planned side-effects of this Phlox design is direct control of hand-offs between regions. These can be done *so* efficiently that some naysayers actually complain that videos of crossings (here and here) must have been doctored, or faked in some way. It’s that good. Vehicles are just one example of script crossings. Physics really doesn’t play into this much. If you can walk across regions, you’ve performed complex crossings of physical objects. The tricky part is having the scripts continue where they left off, uninterrupted, and this includes vehicle scripts (and a lot more).
Avination and OpenSim Milestone
This is why I give credit to Avination for their recent success in the major work item of script state persistence across region crossings. The vehicle part of it isn’t really the big deal here. Having true continuation of active scripts on the other side is a Big Deal. This is also a key part of why I found the “first” claim by Avination to be so outrageous; InWorldz has had vehicle crossings since the Phlox runtime environment came online last summer. Even in terms of physical vehicle crossings, InWorldz has had ODE physics (same as other OpenSim grids) since before InWorldz was founded. However due to its ability to cause region crashes, it has been disabled for about a year (out of InWorldz’ 3 year history). If InWorldz simply turned physical objects back on, physical vehicle crossings would have been possible since the introduction of Phlox; the hard part, and the part Avination just completed, was the persistence of the scripts across the crossings, and that was fully functional and available grid-wide in InWorldz last summer.
However, since the Linden Lab proprietary implementation, another third party developer has provided an implementation of continuations in MONO, which has been available since MONO 2.6. This provides the context save/restore needed, and Avination has successfully applied that to the OpenSim runtime. That’s great news for MONO-based script engines in OpenSim.
Thinking Ahead
In the long run, I see moving away from MONO as the best (and perhaps the only) way to tame processor and memory use and provide complete control of the runtime environment. Phlox will provide that total control, which means more features. Things like much easier support for new languages, an LSL debugger that can be built-in to the viewers to allow single-stepping through LSL code and examination of variables at each stage, easier control over scripts CPU and memory usage, and many other secondary benefits, such as no need to try to limit script cost artificially and blame script authors for hurting sim performance.
But the bottom line here is that continuing a script in a new region, running on a completely different machine (IP address) is a Big Deal. Physical objects, a vehicles, not so much, but persisting those scripts, hell yes. It’s a major accomplishment, and now OpenSim has it too.
