So I decided I wanted to see how quickly phlox could manage rezzing a 40 meter maze if I pulled the llRezObject delays. This is the result. The awesome thing is that with bytecode sharing each new script that is started for each maze wall is just another reference to the same bytecode and the only work the engine needs to do is create new runtime state and add the script to the run queue.
PhysX is here, presently in the beta grid and by the end of November it will be in the main grid, starting in the sandbox regions, oceans, straits, and a few selected private regions. The first phase roll-out makes it possible to make most objects physical. Physical objects fall; they collide with other objects, roll …View full post
In April 2012, InWorldz began full time work on integrating the PhysX physics SDK into our virtual world platform. Over the course of the 4 – 5 months that followed, we have made tremendous progress and are finally ready to begin beta testing. We are scheduling the first limited beta for August 25th, 2012 at 12:00 …View full post
Whether it is dedicated servers, virtual servers/Virtual Machines, or a cloud computing host, there is no escaping that as a business grows on the internet they will need to utilize more and more resources toward supporting the core of their operations. These core services need to stay up and running at all costs, and need …View full post
My intention for this blog is not only to display some of the work that InWorldz has done to our grid, but also to share some of what we’ve learned and hopefully get aspiring geeks, junior geeks, and certified geeks excited about virtual worlds and all the possibilities they bring. These articles will be long …View full post
The lauk’s Larrow running on Phlox
This morning I worked out a few of the last bugs in the script engine that I’m finishing up before we run the beta test. I imported the sparrow I created in another place and left the scripts and objects exactly how they were. No script modifications were required to get this 800 lines of script running with timings that work exactly how they do on the other grid.
Very exciting and happy to see the Larrow will have a home he will work just perfectly on.
Added another video
Over the course of the last 3 months the InWorldz team has been working on a brand new script engine to help power the past, present, and future scripts running on our grid. We wanted to make sure we designed something that met all the needs we had set forth for an engine that would take us well beyond what we currently have.
Our core goals were as follows
- Offer 99% source compatibility with the original SL/LSL implementation
- Be extensible for future additions to the language and also allow us to plug in brand new language implementations in the future.
- Must have a minimal memory overhead
- Must be fast
- Retain as much backwards compatibility as possible for existing scripts
- Enable state saves on inventory items, attachments, and rezzed items
- Allow a fair sharing of processor power with all other scripts
- Have proper scheduling that allows for pause, resume, sleep states etc
- Store compiled scripts and state data in a compact format for efficient disk storage and wire transmission
- Store compiled scripts and state data in an easily parsable format for low overhead during loads
- As much as possible, should not interfere with the main simulation loop, even under high load
- Should provide the coder with good feedback when there are compilation errors
- Must have proper semantic checks for event definitions, function calls, etc
I am happy to announce the new script engine has met all the goals put forth. InWorldz residents will have a script engine they can build their futures on and not have to worry about it lagging or taking down their regions.
Phlox is written from the ground up by InWorldz, LLC. From the grammar up to the scheduler and VM we’ve put blood, sweat and tears into this project. The core consists of a bytecode compiler and a specialized virtual machine. This type of architecture takes your LSL scripts, parses them, checks them for validity, and then generates special instructions that a virtual machine can quickly execute. It provides for optimal sharing of resources between scripts and allows for using all the language constructs without having to worry about runtime performance as a first concern.
We will be making an announcement this week for beginning the beta testing and proving of the engine. We hope to have most of the InWorldz scripters there during the couple weeks the tests will run to prove out our engine and make sure their scripts are working properly. After the beta test we will do a limited rollout of the new engine, followed by a full rollout a week later if there are no significant problems.
I will post more articles on the workings of this script engine in the next few weeks starting with the parser and lexer including semantic checks. I’ll follow that up with a discussion of the bytecode compiler and assembly language, and finish up with a discussion of the VM and runtime scheduler.
We hope by taking these very time consuming and difficult steps we prove to our residents our technical competency as well as reinforce our continued commitment to making InWorldz a leader in virtual worlds technology.