Les scripts des mondes tournent dans l'interpréteur du serveur, depuis le module WebAssembly du monde, le même sur toutes les plateformes : un serveur sous Linux ARM64 n'a plus besoin d'un dossier à lui, et plus aucun contrôle du code d'un monde ne peut le refuser.
Les mondes ne sont plus signés : au démarrage, le serveur vérifie le format du manifeste d'un monde (4) et la taille et le SHA-256 de chaque fichier ; un monde qui échoue est refusé comme abîmé (problème damaged, qui remplace badSignature et codeRefused).
Les mondes publiés avec un SDK antérieur à 0.3.0 (format de manifeste 3) sont refusés comme trop anciens : leurs créateurs doivent les republier.
Protocole 5 : les joueurs ont besoin de NodeWorld 0.3.0.
Les scripts d'un monde sur le serveur ne sont arrêtés que quand leur propre code tourne plus longtemps que FluxWatchdogSeconds dans un appel : le travail du serveur lui-même pendant l'appel ne compte plus. Un appel d'un script au serveur qui prend une seconde ou plus est nommé dans le journal.
Le serveur dit à NodeWorld quels mondes il refuse et pourquoi : son propriétaire et ses copropriétaires reçoivent une notification et les voient sur la page de leur serveur.
Un serveur sous Linux ARM64 fait tourner les scripts que chaque monde publie pour lui, dans le dossier LinuxArm64 du monde, au lieu de ceux du Quest.
Les scripts d'un monde sur le serveur qui tournent plus de 10 secondes dans un appel sont arrêtés, et l'instance continue sans eux ; FluxWatchdogSeconds dans server-config.yaml règle une autre limite, 0 la coupe.
Le serveur vérifie le code machine du module FL# de chaque monde au démarrage et avant de lancer ses scripts, le même contrôle que lancent le SDK et les appareils des joueurs ; un monde dont le code est refusé n'est pas servi, le journal nomme la fonction et la règle, et son propriétaire et ses copropriétaires sont prévenus.
Les scripts des mondes qui tournent sur le serveur peuvent faire des requêtes web et ouvrir des WebSockets vers n'importe quelle adresse ; les pages des hébergeurs disent comment les tenir à l'écart de la machine et de son réseau local avec le pare-feu.
Au premier lancement, le serveur demande son ID et son jeton dans la console, trouve son adresse publique, ouvre son port sur ta box (UPnP), le fait tester par NodeWorld depuis internet et propose de s'installer en service ; chaque étape peut être sautée ou forcée, aussi sans console.
Le serveur peut tourner en service, systemd sur Linux ou service Windows : il démarre avec la machine et de nouveau après chaque mise à jour.
Le serveur se met à jour tout seul : il cherche une nouvelle version toutes les heures, vérifie sa signature et l'installe dès que personne n'est dessus ; AutoUpdate: false dans server-config.yaml coupe ça.
Les joueurs voient les uns des autres l'absence (AFK), la VR ou le bureau, la phrase de statut et Ne pas déranger.
Entre deux joueurs qui ont un blocage, dans un sens ou dans l'autre, le serveur ne transmet plus leur voix, leur avatar ni leurs mouvements de l'un à l'autre.
Les propriétaires d'instance peuvent renvoyer des joueurs chez eux ; toi et tes copropriétaires pouvez bannir des joueurs depuis le jeu, et les joueurs bannis sur le site sont renvoyés chez eux en moins de 30 secondes.
Le serveur refuse lui-même les mineurs dans les instances 18+, et chaque joueur refusé sait pourquoi : banni, réservé aux adultes ou compte suspendu.
Le serveur donne à NodeWorld sa version et son protocole, pour qu'un serveur dépassé apparaisse comme pas à jour, et lesquels de ses mondes sont 18+.
Les joueurs voient sur le nametag des autres quand un micro est coupé, aussi ceux qui arrivent après.
Chaque monde est vérifié au démarrage, toujours : la signature de manifest.json par son créateur, son format et la taille et le SHA-256 de chaque fichier ; un monde qui échoue n'est pas servi et le journal dit pourquoi.
Les objets que les scripts d'un monde font apparaître ont leur propre identifiant dans la salle, sont montrés à chaque joueur et à ceux qui arrivent plus tard, et restent au maître quand leur propriétaire part.
Les scripts d'un monde sur le serveur reçoivent les événements réseau que les joueurs leur envoient, et peuvent leur ouvrir des portails.
Le server-config.yaml créé au premier lancement a maintenant les valeurs que le serveur prend quand une ligne manque : 100 joueurs et 40 tours de logique par seconde au lieu de 50 et 30, et un monde sans GraceSeconds prend DefaultRoomGraceSeconds ; un serveur installé avant garde son fichier (mets-y TickRate: 40).
