Inhalt dieses Guides
FiveM OneSync technisch verstehen: serverseitige Synchronisation, Slotgrenzen, Routing Buckets, State Bags, Entity-Verhalten und Performanceplanung.
Server-Arbeitsmodus
Arbeite den Guide kontrolliert ab und ändere immer nur eine Variable. Dein Fortschritt bleibt nur in diesem Browser gespeichert.
Wo hängt dein Server gerade?
Netzwerkdiagnose bringt nichts, solange der Server lokal nicht sauber startet oder lauscht.
Wenn localhost/LAN funktioniert, liegt der nächste Prüfbereich bei Host-Firewall, Router, öffentlicher Adresse und NAT.
Bei Lag, Abstürzen oder Update-Problemen sind Logs, Ressourcen, Mods und ein sauberer Rollbackpfad wichtiger als weitere Portregeln.
OneSync wird häufig nur als Voraussetzung für größere Spielerzahlen beschrieben. Technisch ist es aber wichtiger: Das System erweitert die serverseitige Zustands- und Entity-Synchronisation der Cfx-Plattform und beeinflusst damit, wie moderne Resources entwickelt und betrieben werden.
State Awareness statt nur „mehr Slots“
Das offizielle Vanilla-Beispiel aktiviert OneSync mit set onesync on. Resources können im Manifest explizit State Awareness verlangen. Wer OneSync deaktiviert oder alte Scripte übernimmt, sollte deshalb Abhängigkeiten und Annahmen prüfen.
Slotzahl und Lizenz
Cfx dokumentiert OneSync derzeit bis 48 Slots ohne zusätzliche Element-Club-Stufe; für höhere Grenzen gelten Portal-/Tierbedingungen. Diese Grenze ist aber keine Hardwareempfehlung. 48 schlecht geschriebene Script-Clients können problematischer sein als eine größere, effizientere Konfiguration.
Routing Buckets
Routing Buckets ermöglichen getrennte Instanzen bzw. „Dimensionen“. Spieler und Entities in unterschiedlichen Buckets sehen einander nicht. Das ist nützlich für Sessions, Charakterauswahl oder getrennte Spielmodi. Cfx weist allerdings darauf hin, dass Buckets kein Universalersatz für Interior-Mechaniken sind.
Entity Lockdown und Sicherheit
OneSync stellt Lockdown-Modi bereit, mit denen clientseitige Entity-Erstellung eingeschränkt werden kann. Welche Einstellung sinnvoll ist, hängt von deinen Resources ab. Zu aggressive Regeln können alte Scripts brechen; zu lockere Regeln können unnötige Angriffsfläche schaffen.
State Bags und serverseitige Logik
State Bags transportieren synchronisierte Metadaten. Moderne Server sollten möglichst viel autoritative Logik serverseitig halten und nicht davon ausgehen, dass ein Client vertrauenswürdig ist. Das gilt besonders bei Inventar, Geld, Berechtigungen und Entity-Erstellung.
Performance messen statt Slots raten
Plane CPU, Datenbank, Scriptlast und Netzwerk anhand realer Telemetrie. Beobachte Server-Hitches, Ressourcentimings, Datenbanklatenz und Spieler-Ping. Ein Upgrade auf mehr vCPU bringt wenig, wenn eine einzelne Resource den Main Thread blockiert.
Mehr zur Basis unter server.cfg und zum Monitoring unter Gameserver Monitoring.
Skalierung in Laststufen testen
Teste neue Scriptstände nicht nur mit einem einzelnen Admin auf leerem Server. Für größere Communities lohnt ein gestufter Lasttest mit typischen Spielerzahlen und realistischen Gameplay-Aktionen. Beobachte dabei nicht nur CPU, sondern auch Datenbanklatenz, Netzwerk, Hitches und die teuersten Resources.
Wenn ein Problem erst ab einer bestimmten Spielerzahl auftritt, ist die Ursache häufig eine O(n)-Logik, zu häufige Datenbankabfragen oder unnötige Entity-/State-Updates. Mehr Hardware kann Symptome verschieben, ersetzt aber nicht die Analyse der Resource selbst.