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.