Script Engines
Script Engines
Everything you need to know, but were afraid to ask, about script engines! Well, not quite, but hey.
There is not much information out there about the moving parts involved in getting from that "script edit" window in the viewer to the prim actually doing the things it does inworld.
There is the source code, the compiler, and the engine.
Source Code
This is the human-readable text you see in the script edit window in the viewer. As of today, it is either the Linden Scripting Language (aka LSL) or the Luau language (a dialect of the Lua scripting language). A programming language to tell prims to do things, and react to stimuli.
The Compiler
This is a piece of software that takes the Source Code and translates it into another language, closer to the actual silicon. Here, it is something called bytecode, a name you may have heard. Bytecode was a slang term for the machine code for an imaginary CPU, so called because many instructions were one byte long.
Like many slang terms in computer sciency circles, it escaped to the public without its history and meaning.
A language virtual machine (or just VM) emulates this imaginary CPU, executing the bytecode like a machine code program.
In Second Life, a long long time ago, they had a VM with its own bytecode (LSO bytecode) and the viewer could upload bytecode.
Then they introduced "Mono" which used the .NET bytecode (CIL), and the compiler lived in the server.
The Phlox engine in InWorldz (and in NGC Tranquility v1.0.49) is another bytecode. The compiler lives on the server again.
The Engine
This is a part of the server. It takes script bytecode assets, and runs them.
YEngine uses CIL bytecodes, and uses the .NET (aka dotnet) runtime to execute the scripts. It also provides the hooks so a script calling an llWhatever() or osWhatever() function can get whatever it needs.
Phlox uses its own bytecodes, and emulates that imaginary CPU directly. Same as YEngine, hooks are provided to perform the functionality of the LSL/OSSL functions.
