The FL# sandbox

Your FL# scripts compile to one WebAssembly module, scripts/client.wasm in your published world, the same for every platform. Players' games and servers never turn it into machine code: they run it in their FL# interpreter, which comes with NodeWorld. No code a world brings runs directly on a player's processor, whoever published it.

What the interpreter guarantees#

• A script reaches only the world's own memory: the interpreter checks every read and write, and a script cannot make up a pointer outside it.
• A call through a computed pointer (a C# delegate, a virtual or interface call, a switch) lands on one of the world's own functions, with the right parameters: the interpreter checks it at each call.
• A script calls nothing of the system: it reaches the game only through the FL# API, and the internet through the network gate.
• The same module runs the same way on Windows, Linux, the Quest and every server, x86-64 or ARM64.

There is nothing to check before a world runs and nothing to turn off: whatever a world's files contain, the interpreter runs nothing outside the sandbox.

Speed#

An interpreter runs code more slowly than the processor does. The game's own work stays native: drawing, physics, sound, voice and the video player. Only your scripts' code is interpreted, and a call of a script to the game costs little. Keep heavy work out of Update: spread it over several frames with a coroutine, or move it to a thread.

What it does not do#

The sandbox keeps a world's code away from the player's device. It does not limit what your scripts do inside the world: all the C#, threads, as much memory as the 32-bit format allows, no per-frame compute budget. The limits on what a world reaches, the internet (the network gate), the menu and leaving (what a script cannot block), are on their own pages.