FiveM unterstützt offiziell Lua, JavaScript und C#. Wähle die Laufzeitumgebung, die zu deinem Framework, den Fähigkeiten deines Teams und den benötigten Bibliotheken passt – nicht eine vermeintliche universelle Leistungsrangliste. Alle drei können FiveM-Natives aufrufen, Ereignisse verarbeiten und Ressourcen-APIs bereitstellen. Die praktischen Unterschiede liegen in der Laufzeitgrenze, dem Paket-Ökosystem, dem Build-Workflow und dem Code, der bereits von deinen Abhängigkeiten verwendet wird.
Die hier gezeigten Konfigurations- und Codebeispiele beziehen sich auf FiveM für GTA V Legacy. Enhanced hat andere Laufzeit- und Kompatibilitätsregeln; überprüfe die Legacy-zu-Enhanced-Änderungen von Cfx.re bevor du sie auf einen Enhanced-Server anwendest.
FiveM Sprachvergleich
| Laufzeitumgebung | Geeignet für | Wichtige Grenze | Typischer Arbeitsablauf |
|---|---|---|---|
| Lua | Bestehende Lua-Frameworks, kompakte Ressourcen und direkte FiveM-Beispiele | CfxLua ist eine modifizierte Lua 5.4-Laufzeitumgebung, keine beliebige System-Lua-Installation | Bearbeite Quelldateien und lade sie über das Ressourcen-Manifest |
| JavaScript | Teams, die JavaScript/TypeScript und npm-Tools verwenden | Client-Skripte erhalten keine Browser- oder Node.js-APIs; Server-Skripte verwenden FiveMs Node-Laufzeitumgebung | Führe Quellcode direkt aus oder kompiliere beziehungsweise bündele TypeScript zu JavaScript, das im Manifest aufgeführt ist |
| C# | .NET-Teams, typisierter Domänencode und kompilierte Projekte | Die Ressource muss die von der Cfx.re-Laufzeitumgebung erwarteten Assemblies und Dateien liefern | Erstelle aus einer Cfx.re-Vorlage und stelle dann die Build-Ausgabe bereit |
Lua: der direkte Framework-Pfad
Cfx.re dokumentiert CfxLua als modifizierte Lua 5.4 Laufzeit. Das ist wichtig, wenn du FiveM-Code mit älteren Lua-Tutorials vergleichst: Sprachfunktionen und Laufzeitverhalten sollten gegen CfxLua geprüft werden, nicht aus dem Betriebssystempaket eines Servers abgeleitet werden.
Lua ist normalerweise die am wenigsten störende Wahl, wenn das Framework und benachbarte Ressourcen bereits in Lua geschrieben sind. Du kannst Ereignisse, Exporte und gemeinsame Konfiguration in derselben Sprache beibehalten und vermeiden, einen Build-Schritt nur für den Stil hinzuzufügen. Ein kleines Manifest kann separate Client-, Server- und gemeinsame Skripte auflisten. Halte serverseitige Geheimnisse und Berechtigungsprüfungen aus Client-Dateien heraus, auch wenn beide Seiten Lua verwenden.
Die kurze Syntax erleichtert das Scannen von Event-Handlern, ersetzt aber nicht das Interface-Design. Dokumentiere jede Event-Payload, validiere Werte auf dem Server und behandle ein Client-Event nicht als Beweis dafür, dass Geld, Inventar oder Berechtigungen gültig sind.
JavaScript und TypeScript: Beachte, auf welcher Seite der Code läuft
Die offizielle Anleitung zur JavaScript-Laufzeit beschreibt die ES2017-Unterstützung und eine wichtige Trennung zwischen Client und Server. Client-Skripte laufen in der FiveM-Client-Laufzeit und haben weder Browser-APIs noch Node.js-APIs. Server-Skripte nutzen eine angepasste Node.js-Laufzeit. Für die Legacy-Laufzeit ist Node.js 16 als Serverstandard dokumentiert; eine Ressource kann mit node_version '22' in fxmanifest.lua Node.js 22 auswählen.
Gehe nicht davon aus, dass ein Paket, das in einem gewöhnlichen Node-Projekt funktioniert, auch in einem FiveM-Client-Skript funktioniert. Platziere Dateisystem-, Datenbank- und serverseitige npm-Abhängigkeiten an der Servergrenze. Für Editor- und TypeScript-Definitionen veröffentlicht Cfx.re die @citizenfx/client und @citizenfx/server Pakete. Diese verbessern die Typüberprüfung, gewähren aber keine APIs, die der ausgewählten Laufzeit fehlen.
FiveM dokumentiert auch Thread-Affinitätsbeschränkungen für einige serverseitige native Aufrufe. Wenn asynchroner Node-Code zum Haupt-Game-Thread zurückkehren muss, befolge die Laufzeitanleitung und verwende setImmediate wo erforderlich. Teste das erstellte JavaScript, das du tatsächlich bereitstellst, einschließlich Source Maps und Startreihenfolge, anstatt nur die TypeScript-Quelle.
C#: Verwende die unterstützte Projektform
Die C#-Laufzeitdokumentation bietet aktuelle Projektvorlagen und Build-Anleitungen. Beginne dort, statt eine alte Assembly-Struktur aus einer anderen .NET-Anwendung zu kopieren. Eine C#-Ressource enthält normalerweise ein Projekt, das die unterstützten CitizenFX-Assemblies referenziert, seinen Code kompiliert und die erzeugten Dateien dort ablegt, wo das Manifest sie laden kann.
C# kann gut passen, wenn das Team bereits .NET-Typen, Werkzeuge und Testverfahren nutzt. Dafür müssen Mitwirkende und CI über das passende SDK und den richtigen Buildbefehl verfügen; das bereitgestellte Artefakt muss zum Quellstand passen. Dokumentiere Vorlage, Zielframework und Release-Prozess im Repository, damit Serverupdates reproduzierbar bleiben.
Das gemeinsame Modell: Manifeste, Natives, Events und Exports
Die Sprachwahl ändert die technischen Vorgaben für Ressourcen nicht. Jede Ressource benötigt ein Manifest namens fxmanifest.lua , das Metadaten und die zu ladenden Dateien deklariert. Client-Code läuft für verbundene Spieler; Server-Code läuft unter FXServer. Geteilte Dateien werden an beide Seiten geliefert, daher dürfen sie keine Anmeldeinformationen oder nur serverseitige Vertrauensentscheidungen enthalten.
- Natives stellen Spiel- und Plattformfunktionen bereit. Prüfe die aktuelle Native-Referenz und ob ein Native auf dem Client oder Server ausgeführt wird.
- Events übertragen Nachrichten innerhalb eines Kontexts oder zwischen Client und Server. Behandle Netzwerkeingaben als nicht vertrauenswürdig und validiere sie serverseitig.
- Exporte stellen Funktionen für andere Ressourcen bereit. Dokumentiere Namen, Parameter, Rückgabewerte und Startabhängigkeiten.
- Abhängigkeiten Gehören in das Manifest oder die Serverstartreihenfolge, wenn eine andere Ressource zuerst verfügbar sein muss.
Ein gemischtsprachiger Server ist normal. Die stabile Grenze ist das dokumentierte Ereignis oder der Export, nicht die Implementierungssprache dahinter. Das ermöglicht es, eine Ressource zu ersetzen, ohne den gesamten Stack neu schreiben zu müssen.
Wie du für ein echtes Projekt wählst
- Beginne mit dem Framework. Wenn der Server von einem etablierten ESX, QBCore, Qbox oder einer eigenständigen Ressource abhängt, verwende deren unterstützte Erweiterungspunkte und Sprachkonventionen.
- Liste benötigte Bibliotheken auf. Prüfe, ob jeder Datenbanktreiber, jede UI-Bridge und jedes Paket mit der Client- oder Server-Laufzeit kompatibel ist, in der es ausgeführt wird.
- Richte dich nach dem Team. Bevorzuge die Sprache, die Mitwirkende überprüfen, testen und pflegen können, nachdem der ursprüngliche Autor gegangen ist.
- Definiere den Build. Lua kann direkt ausgeliefert werden; TypeScript und C# benötigen normalerweise eine reproduzierbare Kompilierung und ein klares Ausgabeverzeichnis.
- Erstelle einen Prototyp der Grenze. Beweise einen nativen Aufruf, ein servervalidiertes Netzwerkereignis, einen Export und einen Abhängigkeitsneustart, bevor du die vollständige Funktion erstellst.
Minimale Überprüfungs-Checkliste
- Starte die Ressource auf einem Staging-Server und überprüfe sowohl die Server- als auch die F8-Client-Protokolle.
- Verbinde einen sauberen Client erneut und starte die Ressource neu, um fehlende Dateien oder Annahmen zur Reihenfolge aufzudecken.
- Sende ungültige und nicht autorisierte Event-Payloads und bestätige, dass der Server sie ablehnt.
- Überprüfe die dokumentierte Node-Version oder die .NET-Build-Ausgabe auf dem tatsächlichen Deployment-Host.
- Pinne Abhängigkeitsversionen und bewahre eine Rollback-Kopie der letzten funktionierenden Ressource auf.
Es gibt keinen evidenzbasierten Grund, eine der drei FiveM-Programmiersprachen als universell schnellste oder beliebteste für jede Ressource zu krönen. Wähle Lua, JavaScript/TypeScript oder C# aus den unterstützten Laufzeitfaktoren, dem umgebenden Framework und den Wartungskosten, die dein Team tatsächlich tragen kann.
Laufzeitunterschiede bei Enhanced
Enhanced ändert die JavaScript- und C#-Laufzeitumgebung sowie einige Plattformverhaltensweisen. Verwende die Dokumentation für die genaue Client-/Server-Edition, anstatt Legacy Node- oder Mono-Annahmen darauf anzuwenden. Erstelle und teste Abhängigkeiten gegen diese Umgebung neu.