FL# scripts
FL# (FluxSharp) is how a world comes alive: doors, mirrors, portals, synced objects, games. You write C# much like a Unity MonoBehaviour, but the scripts are not compiled by Unity: the SDK compiles them with fluxc into one WebAssembly module per world, the same for every platform. The module runs in the FL# interpreter, a sandbox, on every player's device and on the server, so a world cannot touch the player's computer or the game outside its own scene.
There is nothing to install: fluxc comes with the SDK and runs on the .NET runtime of the Unity Editor.
Start here
- Your first FL# script: a door that opens for everyone, from the scripts folder to publishing.
- Write FL# in your IDE: completion and the compiler's errors in Visual Studio or Rider.
- Scripts, callbacks and fields: what a script is, when its methods run, where it runs.
- The example world: eight scripts for what a world often needs (a mirror, a television, a portal, synced objects…), to read and copy.
Where the scripts go
- In the Project window, right-click a folder of your world, then Create, NodeWorld, FL# Scripts Folder: the SDK makes a
Fluxfolder with an assembly definition (.asmdef) whose Define Constraints are never true (NODEWORLD_FLUX_SOURCES_NEVER_DEFINED). Put the world's.csscripts in it. Unity sees the files but does not compile them: they are written against the FL# API, not againstUnityEngine. - In the world's NW World Config, list the scripts in Flux Sharp Sources.
- On an object of the scene, add the FL# Script component (Add Component, NodeWorld, FL# Script): the class of the script (
Namespace.Class), the network ID of the object if it is synchronized, and the values of its public fields.
The basics
| To… | Read |
|---|---|
| find, move, show and hide objects | Objects and components |
| show the same thing to every player | Synced objects and values |
| tell every player something happened, or ask the server | Network events |
| read and move the players, seat them, change how they hear each other | Players |
| make objects players use or grab, read keys and buttons | Interaction and input |
| push bodies, cast rays, react to collisions | Physics |
| play sounds | Sound |
| play videos from the internet | Video players |
| drive panels, buttons, sliders and text fields | Interfaces (UI) |
| change materials, render cameras, drive lights, particles and animators | Cameras, materials and effects |
| wait, repeat, and draw random numbers | Time, coroutines and random numbers |
| remember a player's choices between visits | Player data |
| find what your scripts wrote, and why one stopped | Logs of your scripts |
| know how far you can go, on the server and in Play mode | Limits and performance |
Going further
- Web, WebSocket and images: call web APIs and load pictures.
- Threads and async: spread heavy work over several threads.
- Meshes made by scripts, object batches and drawing by instances: thousands of objects and vertices a frame.
- Objects spawned for the room: copies every player sees.
- Portals made by scripts: open portals to other worlds.
What keeps players safe
- What a script cannot block: the menu, respawning and leaving stay the player's.
- The FL# sandbox: how a world's scripts run on players' devices and servers.
The API
The names follow Unity's where they do the same thing: GameObject, Transform, Rigidbody, Physics.Raycast, Vector3, Quaternion, Mathf, Time, Debug.Log… plus what is NodeWorld's own: Player and Players, Networking, Interaction, Portals. Every type and member is in the FL# API reference, generated from the code.
When something does not work: troubleshooting.